gerske
Forum Replies Created
-
The new version 6.0.5 (from 3 weeks ago) did not fix it. Maybe good to know: I have also activated the module “check out fees” for this same custom field.
When a customer enters something in the custom field, a small fee will be added to the order. That works very nicely.
Hi David,
PHP version 8.1
WooCommerce version 7.6.0
WordPress version 6.2
Booster version 6.0.4The custom field I made in Booster is visible in the admin order pages, under the shipping address. When a customer puts text in this field when ordering, this text is visible in this field on the admin order page. So it works fine. We use this text as a printed message on our product.
Only problem is when I edit this field on the admin order page, it doesn’t save the field. After saving it show the content like it was before. So empty when the field was empty. Or with the customer text again, with losing the edits I made.
It is not a huge problem, but it would be handy if we could edit the field. Sometimes customers make a spelling mistake, and we would like to fix it.
So, don’t spend too long on it. But if you have a quick fix, it would be great.
Thanks
Gerske
Hi David, yes, it seems to be possible to edit the field from the admin side order page. But after saving, the field is not saved. Very strange.
Forum: Plugins
In reply to: [Review Slider for WooCommerce] Read More option doesn’t workYes, I have the same issue. Will this be fixed?
Forum: Plugins
In reply to: [Fluid Checkout for WooCommerce - Lite] Compatible with Mollie Payments?Great. Thanks!
Forum: Plugins
In reply to: [Fluid Checkout for WooCommerce - Lite] Compatible with Mollie Payments?Thanks! Alan writes “mobile” payments, but I meant the payment provider Mollie (similar to Stripe). We use their plugin https://wordpress.org/plugins/mollie-payments-for-woocommerce/.
If it works with Fluid Checkout that would be great.
I upgraded from 2.4.0 to 2.4.3 and switched on auto translation again. It has only been 1 day, but I didn’t see any strange changed in the main language strings. So far so good.
Yes, it was! Happy that it seems to be good on your site as well. Ciao.
I upgraded from 2.4.0 to 2.4.3 and switched on auto translation again. It has only been 1 day, but I didn’t see any strange changed in the main language strings. So far so good.
Translatepress is asking to get admin credentials to debug the situation and make a fix. Would anyone who is having this problem be able to give that to them? That would be of great help. There support is “TranslatePress Support” <hello@translatepress.com>.
I went back to version 2.4 and switched off autotranslation. This is not a real solution of course, but at the least the problem is not getting bigger than it already is.
Still no reply from Translatepress.
- This reply was modified 3 years, 8 months ago by gerske.
Wondering when TranslatePress wil fix this problem. More and more users are reporting this problem here.
It is a bug in TranslatePress. Several people are complaining about this issue.
Here is the thread I opened:
- https://wordpress.org/support/topic/strange-translations-in-the-main-language/
Still no solution unfortunately from TranslatePress…
Turning off the “cache results” fixed the problem. Thank you!
Hope that TranslatePress will be included as well soon. It is one of the best and fastest translation solutions for WP.
Translatepress is still very buggy at the moment.
Support asked me to drop _trp_gettext_* tables in the database and regenerate these tables. I did, but these strange translation in the main language still happen.
Support say they fixed it in the latest version, but it is clearly not fixed.
Please update Translatepress to a working version. We are losing many orders at the moment because of this behaviour.