radchuk2012
Forum Replies Created
-
Greetings!
Thanks for the fix! In version 5.7.2 everything works ok.Forum: Plugins
In reply to: [Contact Form 7] 5.7 Woocommerce language translation broke with 5.7Found what the bug is:
The default form of the plugin is written to the data table “postmeta” > “_meta_key” > “_locale” with the “meta_value” > “uk”, and all new forms are written by the plugin with the value “en_US”.
It looks like version 7.5.6.4 builds a query to this table somehow differently and does not cause a bug.
If you change the table to “uk” then the display of WooCommerce content starts working correctly.I updated the plugin from 7.5.6.4 to v5.7.1, after that I changed all form values to “uk” and new forms began to be create by copying with the value “uk”.
Those not created by copying are still created with the value “en_US” and cause a bug in v5.7+.
- This reply was modified 2 years, 2 months ago by radchuk2012.
Forum: Plugins
In reply to: [WooCommerce] CF7 v5.7 + WooCommerce system translation bugFound what the bug is:
The default form of the plugin is written to the data table “postmeta” > “_meta_key” > “_locale” with the “meta_value” > “uk”, and all new forms are written by the plugin with the value “en_US”.
It looks like version 7.5.6.4 builds a query to this table somehow differently and does not cause a bug.
If you change the table to “uk” then the display of WooCommerce content starts working correctly.I updated the plugin from 7.5.6.4 to v5.7.1, after that I changed all form values to “uk” and new forms began to be create by copying with the value “uk”.
Those not created by copying are still created with the value “en_US” and cause a bug in v5.7+.
I updated the plugin from 7.5.6.4 to v5.7.1, after that I changed all form values to “uk” and new forms began to be create by copying with the value “uk”.
Those not created by copying are still created with the value “en_US” and cause a bug in v5.7+.
Found what the bug is:
The default form of the plugin is written to the data table “postmeta” > “_meta_key” > “_locale” with the “meta_value” > “uk”, and all new forms are written by the plugin with the value “en_US”.
It looks like version 7.5.6.4 builds a query to this table somehow differently and does not cause a bug.
If you change the table to “uk” then the display of WooCommerce content starts working correctly.Did some research on the bug myself today:
There are only two plugins installed on a clean WordPress installation and the language of the site is “Укра?нська”:
Contact Form 7 v5.7.1
WooCommerce v7.2.0
Twenty Twenty-Three v1.0 Theme (Default WordPress Theme)
The bug manifested itself when there is a contact form output anywhere on the WooCommerce product or product catalog page and any non-default contact form is selected when installing the Contact Form 7 v5.7.1 plugin (simply copy the contact form created when installing the plugin and place its shortcode).To do this, you can create any page and put the shortcode of the contact form in its name, after which it will be displayed in the header after publication.
Immediately after these actions, the buttons and some texts of the WooCommerce plugin interface begin to be displayed in English instead of the selected Ukrainian.
The first link with a set of plugins, the rest with a bug display:
https://xtemos.nyc3.digitaloceanspaces.com/wp-content/uploads/2022/12/Track-order-scaled.jpg
With the default WordPress theme “Twenty Twenty-Three”:
https://gyazo.com/306db0504ecf45c39d37386f35abdea7
Description of the identified problem from the author of the theme on which the site zyabkin.ua works – when switching to the standard theme “Twenty Twenty-Three”:
With the version https://downloads.www.ads-software.com/plugin/contact-form-7.5.6.4.zip everything works fine, it looks like there is a problem with your plugin version 5.7.
Greetings!
I have a catalog of 39,734 products and 4,779 general attributes, 41,148 attribute values, excluding personal attributes.
Your version of the plugin, despite all the approaches, still completes the task in 9 hours, sometimes with breaks in the middle of the process.
After finding a solution to the problem, I came up with another plugin that copes with the task of generating a file up to 20 minutes without cached data (with a cache up to 10 minutes), which I chose – https://uk.www.ads-software.com/plugins/best-woocommerce-feed/
I also tested the work of a plugin that generates data at the time of a request for a file url (does not use cron). On the plus side, it uses the *.webp output image file format (displayed to users with compatible browsers when visiting pages, otherwise *.jpg). Of the minuses, it does not have filters and rules, a limited number of platform support (Google, Bing). The task will be completed even faster, a little over 5 minutes, and then it will use a cache that is automatically updated on change with a response of 420 ms – https://woocommerce.com/products/google-product-feed/
To summarize, there is a bug in your plugin that cannot process data arrays for entry-level online marketplaces.Hello!
Thank you, the information will be useful. The question is closed.Greetings! What is the average time for one batch of 750 products? Installing the update 1 day – if the cycle by the number of batches exceeds the day, then the behavior of the plugin is to complete the list of products with the state of the quantity at the time of the start and then start again or does the cycle start again after 1 day from the start?
Same problem – active PHP session was detected. PHP-FPM 8.1. WooCommerce: 6.7.0