I'm using WP all import to update WooCommerce products stock. WPML is installed, 2 languages, only variable products, all duplicated. When I manually run the import from the "run import" button of the import manager, everything works great. The variations products stock are well updated, for main product language and duplicate one. BUT, when I activate the same import from a CRON job, only the main language products variation stock are updated. The duplicate product stock stay unchanged. Short video of the process here :


It looks like if the option "Increase speed by disabling do_action calls in wp_insert_post during import." were automatically enable for CRON jobs.

Any idea to force this action, or to force saving/updating/duplicate products and variations after/during import to affect duplicated products would be appreciate.


Just like most of the problems I work on, I don't know the fix until I do some work to figure it out. This is one way to go about finding your way to the bottom of this problem.

There are some basics to cover before anything else:

  • If you are sure do_action calls are being skipped, have you checked to make sure the problems with the data are the problems you would expect from do_actions not happening? If that is the problem, then you need to reinstate the do_action calls.
  • You need to find out if the import works from the command line. If it does, then you know the cron setup is the problem. But the problem could be unrelated to cron. Running at the command line will reveal the anwser to that.
  • Have you looked at the php error log and the cron log, if there is one, for clues? If there are no errors there, that is bad and there should be. That would be the first thing I would fix. I keep blocks of code for turning error reporting on and off depending on sitution;
  • Are you certain the import run through cron is the same import run by the browser?
  • The reason for asking that question is the procedure for troubleshooting is a lot different depending one that condition.
  • Who developed the import and what support can you get from them?

If cron and the browser both run exactly the same programs, there are only a few areas where the problem could be:

  1. The part of the import for the 2nd language might rely on system variables that are available only in webserver mode, and not from the command line. Examples are $_POST, $_GET, $_SESSION and HTTP.

  2. The php.ini settings for the command line might disallow things that are allowed by the php.ini used for the web-based edition. A common example is short open tags allowed in web-based php but not from the command line, but there are lot of things it could be. The easiest way to check is to produce the phpinfo() output from both the browser and command line and compare the results to find differences. If there are differences, you might be able to just adjust the php.ini in effect for cron and be all set. You might need to make changes to the program so it will run with command line configured the way it is, depending on the settings involved and your access or lack of access to the php.ini files for editing.

  3. PERMISSIONS The account running the program for the web server might have permissions the account running from the command line does not have. Tracking down with certainty which accounts are running php can be done by running the php function posix_getpwuid(posix_geteuid()).

If the import programs run by cron are different from the ones run through the browser, you can still start looking at the items I listed above but you might have to look at the whole program and system environment to track down the cause of this problem.

If you go through all that, you will be close to having this fixed if it is not fixed already. Please let us know how this problem goes and do not hesitate to ask any questions you might have.

| improve this answer | |
  • >>If you are sure do_action calls... not sure >>Have you looked at the php error log... The cron log is exactly the same as the browser import log >>Are you certain the import run through cron is the same import... I guess. I configured the cron with trigger and execution scripts given into the import manager, from the same import ran by the browser. >>Who developed the import... WP all import team. They sent me to WPML support. The part 2 of your answer is too complicated for my level. I will wait for WPML dev to see if they find something. Thank you Scotty ! – eds Dec 2 '16 at 17:08
  • Can you run the import from the command line? – Scotty Jakes Dec 3 '16 at 0:52
  • I fear I'm not able to do that. My host doesn't offer cron job services, so I configured it from an external solution : cron-job.org Maybe it is a part of the problem... – eds Dec 3 '16 at 18:41
  • Well, then you are stuck having to cycle your trouble shooting through cron. that is a big handicap. I did not understand your description of the logs. The logs are your main hope for a solution here. Cron can have a log completely separate from php. Are you able to control which php messages are logged? Are you able to work with the source code of the import process, to add diagnostic checks to isolate the problem? If your access to logs and control what goes into them is limited, and you cannot run from the command line, you are in a bad situation. – Scotty Jakes Dec 6 '16 at 18:10
  • What do you think of the idea of copying this system to a server where you have root privileges? $5/month from Digital Ocean gets you a server with 20G of disk. – Scotty Jakes Dec 6 '16 at 18:10

Reason it is not working is because wp_cron is executed during init stages of WordPress so that means your import / export using $woocommerce is not going to work. $woocommerce at that point is not initialized because wp_cron happens before page load.

I'm in the same boat, I'm trying to solve this issue but so far have not found a workaround. possibly using add_action within the wp_cron hook but that would complicate things a lot. Best bet is to setup a real cron job in the server.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.