Hi David, I've got three PT installations all on the server but on different domains and I've been updating them using a cron job run from a shell.
All of the sudden they've stopped importing the feeds. All I get is the text telling me that it's backfilling the reviews. The feeds are pulled using wget (the filesizes and timestamps changed) but import.php just isn't running. However, if I manually do the import from the admin panel then the feeds do import so it's not a database issue.
I've tracked it down to the command line arguments not being read when I'm calling import.php from the cron job. I've stuck a couple of echo statements in to import.php and both $argv and $argc are empty. It looks like my web host has somehow turned off $_SERVER['argv'] and $_SERVER['argc'].
Whilst I'm waiting for them to confirm or deny this, if it's a change that can't be reversed is there a way around this ? Can we force import.php to import all feeds by default ? If so, how ?
Cheers
Phil
Thanks David, that worked in conjunction with changing the path to php in the script which does all the wget'ing, unzipping etc from /usr/local/bin/php (which is what used to work) to /usr/bin/php.
Looks like my web host recompiled and moved some stuff around - still waiting for a reply back from them though.
Regards
Phil
Hi David
Sorry to bother you again, a quick question (hopefully).
I have got automation imports cron.php working on one site, so I know it works on my server. However I have other sites on different domains using a central shared feeds directory. I can see the feeds, register them and import them manually okay and If I use debug mode and do it by the browser it works okay i.e /scripts/cron.php?password=yourpassword
However when I try to use the automation import.php or cron.php the product table empties but no products are imported. That would suggest that I have the script configured ok. I am still using 12/10B.
Do you have any ideas what the issue might be?
Thanks as always.
Ben
Hello Ben,
That sounds like the command line version of PHP on your server is not set-up / built to change directory internally to the same folder as the script. The best thing to do is to chain a cd (change directory) command in line with your existing command. You can chain multiple commands in a single cron job by separating them with semi-colon. For example, if you are currently scheduling:
/usr/bin/php /home/example.com/public_html/scripts/cron.php...then instead, use:
cd /home/example.com/public_html/scripts/;/usr/bin/php cron.phpHowever, if the cd followed by php is what you already have in place, or of course if you try the above and no difference, let me know and I'll investigate further with you...
Cheers,
David.
--
PriceTapestry.com
Hi David
Thanks for the reply.
Doh The answer was in front of me all the time!!
I was already using the cd version which did not work. But then I saw that your Support Info page on the admin panel already had another option which I tried and it worked.
Brilliant.
PS the new version looks really good with excellent features like the voucher codes. Well done and Thanks again
Ben
Hello Phil,
That sounds like the /usr/bin/php version of PHP has been built in CGI (designed for web servers not using the Apache module) rather than CLI mode however according to http://php.net/manual/en/migration5.cli-cgi.php the cli version should always populate argc/argv.
In the mean time, it is straight forward to hard code @ALL as the filename. In scripts/import.php look for the following code at line 14:
$argc = $_SERVER["argc"];$argv = $_SERVER["argv"];
...and REPLACE with:
$argc = 2;$argv = array("","@ALL");
Hope this helps!
Cheers,
David.
--
PriceTapestry.com