View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015288||phpList 3 application||Command Line||public||13-05-09 16:40||09-04-10 18:30|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||2.10.11||Fixed in Version||2.10.11|
|Summary||0015288: v2.10.10: Commandline cron not working|
|Description||Following issue was reported by jfm5440:|
==== Start Quote ====
My command line processqueue cron jobs worked fine under 2.10.4 but after upgrade to 2.10.10 they stopped.
It looks like the parameters are not getting passed. I have the "$commandline_users = array();" set so no user id is needed.
Well it appears to be a PHP register_globals problem.
If i stub out
require_once dirname(__FILE__) .'/commonlib/lib/unregister_globals.php';
from index.php the cli works.
I know there are security implications in leaving register_globals on (which is my php.ini default because I want to for some old scripts).
but index.php should work without global registration right?
anyway if I edit .htaccess and add
php_flag register_globals off
the cli continues to work fine.
==== End Quote ====
|Tags||No tags attached.|
Clean install of 2.10.10 undergoing initial config and test on a LAMP hosted server - mails refused to go out even though cron emailed correct action complete.
Mails stayed queued whether sent to the test list or direct to the test user.
commenting out the require_once dirname(__FILE__) .'/commonlib/lib/unregister_globals.php'; from index.php released the mails ....
.... however ....
My hosting company has "register_globals = on" set at a server level, and I had to perform 2 bug fixes before the above one worked -
- in lists/.htaccess => knock out the globals line reported as a fix for the 500 error during install (I had to do this to get phpLIST to install)
- in lists/config/config.php => set the $commandline_users = array();
to read => $commandline_users = array("admin","server_user_name"); before cron would run.
(Replace "server_user_name" with your actual server login name => is this a security risk? plain text server user name in the config file?)
.... also ....
I'd also had to apply the updated files -
http://forums.phplist.com/viewtopic.php?f=17&t=24505 (attributes order listing not saving on subscription page)
http://forums.phplist.com/download/file.php?id=106 (lists/admin/connect.php patched file)
That last one, the patched connect.php file, was critical
.... because ....
even after applying all of the above, mails created BEFORE patching connect.php still will not go (cron reports an error within the email that is the same as why connect.php was patched).
It therefore appears that the _globals issue has potential to be masking other bugs for which patches are already available.
||this has probably been resolved by fixing other register globals related issues. I tried on the latest code and it works ok on commandline.,|