jomo

as per discussion on:
https://github.com/hyyan/woo-poly-integration/issues/495
we will remove the offending code.

Noting also:
https://github.com/hyyan/woo-poly-integration/issues/487
It sounds like switching languages does not always switch the text direction properly.
If you can find any particular evidence of when this happens, any trace from the php error logs please reopen on github.

as per other discussions basically new features around WooCommerce blocks are basically untested, may or may not work.

It’s possible but the effort programming probably wouldn’t save you a lot of time.
see also https://github.com/hyyan/woo-poly-integration/issues/493

Hi, this doesn’t reproduce in a test enviroment,
What could happen is that the category or parent category translations are not correctly linked in some way, check through product categories that they right translations are linked up and there are no duplicate slugs.

It is a good question – what do you think?

The emails are sent in the language the user checked out in (regardless of which language the user was using when they started browsing the site).

The shop emails are also sent in this language.
This also allows different shop email recipients for customer service for different languages so it does make some sense.

If there are different requirements they should be logged in detail on github – and someone would have to volunteer to implement them.

Hi, the picture linked is from wp-admin: wp-admin should always be showing the text in the shop base language.

The translations are set in Languages, String Translations, WooCommerce Payment Gateways:
/wp-admin/admin.php?page=mlang_strings&s&group=WooCommerce+Payment+Gateways&paged=1

Then the translated description is seen on the Checkout page when you select each payment method.

tracking on: https://github.com/hyyan/woo-poly-integration/issues/497
please post any updates there

substantially addressed by:
https://docs.ultimatemember.com/article/1490-how-to-remove-css-and-js-on-non-um-pages

reduced a homepage payload from 83 files to 46..

• This reply was modified 4 years, 9 months ago by jomo.

Guys, now a third release to fix PHP 7.4 which still doesn’t fix PHP7.4…

VERSION 2.6.5
Remove use of get_magic_quotes_gpc() for PHP 7.4
VERSION 2.6.4
Fixed deprecated syntax in PHP 7.4
VERSION 2.6.3
Fixed compatibility with PHP 7.4
Changed memory limit checking.

after 2.6.5 install repeatedly logging eg:
[16-Jun-2020 21:13:29 UTC] All-in-One Event Calendar: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead @ wp-content/plugins/all-in-one-event-calendar/vendor/twig/Template.php:402 #8192

report it to their actual support page, there are various php7.3 errors, they fixed some I think but not all of them

wowser, you even notice updates to closed threads, I feel a 5* review coming on!

since recent update, Save on the Network Settings WebP page produces:
[06-Jun-2020 16:05:09 UTC] PHP Fatal error: Uncaught Error: Call to a member function inline_script() on null in wp-content/plugins/ewww-image-optimizer/common.php:10254
Stack trace:
#0 wp-content/plugins/ewww-image-optimizer/common.php(9136): ewww_image_optimizer_options(‘network-multisi…’)
#1 wp-includes/class-wp-hook.php(287): ewww_image_optimizer_network_options(”)
#2 wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(”, Array)
#3 wp-includes/plugin.php(478): WP_Hook->do_action(Array)
#4 wp-admin/admin.php(254): do_action(‘settings_page_e…’)
#5 wp-admin/network/admin.php(13): require_once(‘/home/[account]/p…’)
#6 wp-admin/network/settings.php(11): require_once(‘/home/[account]/p…’)
#7 {main}
thrown in wp-content/plugins/ewww-image-optimizer/common.php on line 10254

Noted this is an open issue on GitHub:
https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront/issues/492

Nice one!
.. though I didn’t know we were allowed to use that language in these forums! ??