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 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:
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.
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.
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.