ucsendre

Hi @jsuarezgpk

Yes, it does. It works with 8.3 too.

Dear @grigaswp

Your tip worked like a charm. <3 You have saved me spending my time digging into Porto theme’s template files.

I just simply had to make a copy of my translation file in Loco to the “system” location, empty caches and voila – the magic happened ??

Thank you very much indeed.

Best regards,
Endre

Hello @shameemreza

I have translated all possibile strings using Loco.

(link: https://ibb.co/1MCBWwT )

I have also ran those tools as you suggested, cleared the cache, opened the site in an incognito (private mode) browser window, but the text remains untranslated.

Please find woocommerce system info here:
https://prod.pastebin.prod.webservices.mozgcp.net/tVCda9Jq

Thanks and regards,
Endre

https://contactform7.com/2023/11/30/contact-form-7-584/

Hi @tractanz

I think your question has now been answered ??

Hi @konamiman and @babylon1999

I do not want to disable this message but I really need to translate the output string to my customer’s language.

I have tried Loca Translate but that can not find the string in WooCommerce translation database.

Could you be as kind as to help me out I would be more than grateful indeed.

Thank you very much in advance.

Best regards,
Endre

Dear @wpchefgadget

Thank you for the quick response and action.
I can confirm the security message has also been removed from Plesk panel.
All clear and relaxed now ??
I wish you a happy weekend.
Best regards,
Endre

Hello @gravid7 ,

_YOUR_ code is vulnerable as it was reported by ithemes (see link above) and by patchstack.

Please do not waste our time by asking unnecessary things from us but do look and fix the broken code which makes our websites open for exploits. ASAP please.

Thank xou!

Kindest regards,
Endre

Hello @vmarko

Yes, it works when line 33 is commented out.
Thank you for the quick fix.

Hi @bcolflesh

You can find it here: https://github.com/woocommerce/woocommerce/releases/tag/7.2.2

Cherry pick 36119 into release/7.2 (#36126)

* Re-run the 7.2.1 state migrations when merchants update to 7.2.2. (#36119)

The wc_update_721_* functions were not guaranteed to succeed, because of a hardcoded prefix. We also could not depend on the async migration tasks persisting through to the 7.2.2 update.

* Prep for cherry pick 36119

Hello @marksi-1

Try rolling back to the latest “stable” version:
contact-form-7.5.6.4.zip

• This reply was modified 2 years, 2 months ago by ucsendre.

Hello @talismyra

You can find earlier versions at the bottom f this page:
https://www.ads-software.com/plugins/woocommerce-delivery-notes/advanced/

Direct link to version 4.6.5:
https://downloads.www.ads-software.com/plugin/woocommerce-delivery-notes.4.6.5.zip

I can confirm the bug reported by @kircherc and I would like to add that the filed names are in English regardless of the language is set to another language (Hungarian in our case).
Even unused field’s names are printed like “Company:” at private customer orders and “State:” despite we do not use that field at all in Hungary. Absence of “Country” filed does not affect us as we only ship locally.

Hello @submedia
I know it does not solve the main problem (that is why I called it workaround), but the basic problem for many of us was that the orders are no longer ordered on the admin screen because they are in ordered by time by default (which is messed up now).
So the quick fix was to set the ordering of orders to the ID – which is not (yet) messed up ??

I found a quick workaround until dev guys find the issue. Copy the below code into the functions.php file of your (child)theme.
This makes the ordering of shop orders default to post id (number of order).

function set_order_of_shop_orders_in_admin( $wp_query ) { global $pagenow;
if ( is_admin() && 'edit.php' == $pagenow && isset($_GET['post_type']) && !isset($_GET['orderby'])) {
if ( $_GET['post_type'] == 'shop_order' ) {
$wp_query->set( 'orderby', 'ID' );
$wp_query->set( 'order', 'desc' );       
} } }
add_filter('pre_get_posts', 'set_order_of_shop_orders_in_admin', 5 );