kostniczka

Hey @anghelemanuel99, I have resolved the problem and also I think that I have found a bug in your plugin.

In Translatepress file: /includes/gettext/class-process-gettext.php

Line no. 254 in version 2.5.0 there is this condition:

if ( ($text != 'Name: %1$s, Username: %2$s' && $text != 'Name: %1$s, Guest' && $domain == 'woocommerce-payments') || $domain != 'woocommerce-payments') 

I have commented out the last part:

if ( ($text != 'Name: %1$s, Username: %2$s' && $text != 'Name: %1$s, Guest' && $domain == 'woocommerce-payments') /*|| $domain != 'woocommerce-payments'*/) 

and my payment gateway works like a charm. I am not exactly sure what you wanted to achieve by this condition, but for me it looks like there should be more braces maybe?

However, now there are some front-end issues but they are only in console and probably slightly decreasing site performance, but for now the most important is that my payment gateway works in all language versions of site.

Could you please look into this?

Hello, thank you for the reply. I have already checked if it’s theme or other plugins. I have put the page to maintenance mode and switched to twenty-twenty one and also disabled all the plugins, leaving only woocommerce, translatepress and tpay (payment module), but the problem persists.

I believe the conflict exists between tpay and translatepress.

I had some success by overriding is_available() function in tpay module – the payment gateway did show, but when I tried to pay i got “Invalid payment method” message.

Hello @rzepsen,

Thank you for your answer.

I forgot to say that using your plugin I have managed to set up a follow up email (2 weeks after order) for user to rate the product. That works fine.

The only problem I have is with these 2 triggers which I mentioned above.

I’ve installed the plugins you recommended, performed an action which should trigger automations that I’ve set and the only suspicious thin I’ve noticed was in WP Crontrol:

Unexpected HTTP response code: 401 or 403
This means an access control restriction such as BasicAuth, a firewall, a security or privacy plugin, some form of password protection, or an .htaccess rule is preventing your server from accessing wp-cron.php.

This is true – right now we have .htacess password rule as the shop is still in construction. I will check if the error persists if I temporarily remove the password.

Hi @rynald0s,

I’ve had it already, but like this:

.storefront-sticky-add-to-cart {
bottom: 0;
top: auto;
}

I moved it to be under .admin-bar .storefront-sticky-add-to-cart–slideInDown but unfortunately, it didn’t do a trick. Sticky bar went to top, because there is this CSS class (from Storefront):

@media (min-width: 768px)
.storefront-sticky-add-to-cart {
    display: block;
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    z-index: 99998;
    transform: translate3d(0, -100%, 0);
    padding: 1em;
    overflow: hidden;
    zoom: 1;
    box-shadow: 0 1px 2px rgb(0 0 0 / 20%);
    animation-duration: .5s;
    animation-fill-mode: both;
}

which I was overriding by the code I had before, which made the bar almost at the bottom

Okay, so:
I added to sticky z-index:0 and now I think it’s more clear 🙂
https://snipboard.io/4uCnBo.jpg

Hi @nawaz0705 and thanks! Meanwhile I’ve tried to fix the issue the other way around so now yeah, it may appear at the bottom even in Chrome, I have the other issue though now 😀

The CSS I have now is:

.storefront-sticky-add-to-cart {
	bottom: 0;
	top: auto;
	max-height: fit-content;
}

.storefront-sticky-add-to-cart--slideInDown{
    animation-name:slideInUp;
}
.storefront-sticky-add-to-cart--slideOutUp{
    animation-name:slideOutDown;
}

Now when I scroll down in stays at the bottom (correct), but when I refresh page or enter the other product it is not at the bottom.
https://snipboard.io/JMNVm6.jpg

I think now the JS is the problem, because on reload sticky shouldn’t appear at all.

• This reply was modified 3 years, 9 months ago by kostniczka.