[Assigned] CLI Implementation of "WPML Import Export" Fails
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.
I am trying to:
Run the cli command "wp wpml import process" after finishing my imports but it times out at the step "Verknüpfung von Produktattribut-Übersetzungen" which is something like Linking of product attribute translations.
I found the following in the logs:
13-May-2024 10:02:20 UTC] Cron-Unschedule-Event-Fehler für Hook: publish_future_post, Fehlercode: could_not_set, Fehlermeldung: Die Cron-Ereignisliste konnte nicht gespeichert werden., Daten: {"schedule":false,"args":["39947"]}
I understand the issue you're experiencing. Sometimes, due to network issues or other background processes, the import process can get stuck at a particular phase. This can also happen if we initiate the import from the WordPress interface. In such cases, clearing the caches or performing a hard refresh in the browser and then starting the import process again can often resolve the issue.
Since it is stuck in the "Linking of product attribute" phase, could you please restart the import from WP-CLI and check if the issue persists? Don't worry about duplicate products; no products will be created until the import is completed.
Let me know the update. I will be happy to help if you need further assistance in this matter.
so the process in the wp-backend works but takes ages (~1min) and the on in the cli fails consistently at that step when i run it the first time after a new import but after it times out i can run it again and it correctly finishes then. But still it should be possible to run it at the first try successfully i think 🙂
I completely understand and agree that it should be resolved on the first attempt. However, as I mentioned earlier, due to caching or other background processes, the issue might occur once. In one of the cases, we found that the problem was due to an incorrect term relationship.
The error log that you've shared indicates an issue with WordPress's cron system, specifically with unscheduling an event for the publish_future_post hook. This could be caused by several issues, such as file permission problems, database issues, or conflicts with plugins.
Ensure that your WordPress installation has the correct file permissions. Incorrect permissions can prevent WordPress from writing to necessary files. You can also Disable and Re-enable WP-Cron which sometimes resolves issues with scheduled events.
Add the following line to your wp-config.php file to disable WP-Cron:
define('DISABLE_WP_CRON', true);
Execute the import process again and once if it is completed without issues, you can enable the WP Cron again.
Once the import is completed properly, you shouldn't encounter the issue again. But, keep the WP Debug enabled and if the issue happens again, please share the detailed error log. I will review that and assist you accordingly.
Hello There,
I hope you're doing well. Sorry for the delay in responding.
I've tried to run the import process from the CLI in a minimal environment (only with WPML and its add-ons), but I can't seem to replicate the issue. The process is completed successfully without any errors.
Could you please let me know if there are special steps needed to replicate the issue? Also, have you tried starting the process with a different post type besides "Product"?
Let me know the update. I will be happy to help if you need further assistance in this matter.
i did import several product variations (9000) with the new parameters and the linking set up via wp all import and tried the cleanup afterwards, but no, it won't finish, neither in the cli nor the wp backend. There are no errors either, any possibility to enable logging to further understand the issue?
no it always stops at counting "Linking of product attribute translations" in the backend and won't even show starting this step on the backend.
both processes time out after about 10 minutes. The cpu processing time can't be an issue (5950x ryzen). So it has to somehow end up in a loop. I could run xdebug on it when you tell me where to look.
I tested multiple times with WooCommerce products and noticed that the process got stuck at the "Linking Product Attribute Translations" step. However, when I performed the same action from the WordPress UI, I did not encounter the issue.
During my investigation, I noticed that the process got stuck at 149 items (check the attached screenshot). However, When importing from the UI, 149 items were imported, but the rest were skipped(Screenshot: hidden link). Despite this, the process didn't get stuck in the UI. Also, there are no errors being logged in the debug file.
Therefore, the issue with the CLI could be caused by the items being skipped.
Before I escalate the matter to the 2nd tier team, could you please check if any items are being skipped during the import process from the UI? Once I receive your confirmation, I will escalate the issue and take the necessary actions to resolve the problem.
I've escalated the issue to our second-tier team for further investigation. As soon as I have any updates or information on this matter, I will inform you.
Our dev team is currently investigating the issue. Since the problem occurred via CLI, any errors should be logged in the PHP error log and the server error log file. Could you please try to recreate the issue once more and check both the PHP and server error logs? If you notice any entries that appear right after the issue occurs in the CLI, please share both error logs in your next response. This would help our team a lot to understand the root cause of the issue.
so I did some research myself on that topic and it seems that it has something todo with the sql query that counts the amount of product attributes to be fixed and afterwards gets batches of 100 each to process.
I made a complete copy of the site on my local system and there the queries actually went through in a reasonable amount of time. The only difference in my opinion to the live system is actually that the local system is runnning on mysql 8.0.30 (on windows) and the live system is running mariadb 10.6.16 (on ubuntu 20.04.06).
The first query did run through on the staging environment (also live server but different url) after a whopping 19min30s without any error, but then failed to run the third "Limit 100" query.
It could be some performance issue with that query and mariadb at that point.
Thank you for continuing your research and sharing this valuable information with us.
I have forwarded the information to our 2nd tier team for further investigation. They will check if there is a way to optimize the SQL query and share any updates. As soon as I hear back from them, I will inform you.
Once again, than you so much for your patience and kind cooperation in this matter.
sorry for my slow response, I think I figured out the issue why the query was taking so long (I accidantelly had a misconfiguration in my importer so that the translation groups didn't consisted of 1 post per language but up 50 per language (All variations of a variable product had the same translation group).
Since that is fixed now the script seems to be running fine in the backend but still stops in the cli when it has to skip entries like you figured out yourself. Is there a fix for that available?
Glad to hear that the import process is working fine in the backend.
The issue with the CLI getting stuck when entries are skipped has already been reported to the 2nd tier team. Currently, there is no available solution for this issue. Our team is actively working on it, and we hope to find a resolution soon.
Thank you for your patience and cooperation in this matter.
