Not sure what exactly broke, but upgrading to CiviCRM 4.7.1 on CentOS 6 required adding PHP 5.4 via the SCL repo. Something in that process broke the cURL/wget/php cron job calls. (Invalid username/password despite logs showing it correctly. See https://issues.civicrm.org/jira/browse/CRM-17981) So, I created a cron job with: scl enable php54 "wp --user= --url= --path=/path/to/wp/ civicrm api job.execute auth=0" It runs, and everything seems fine. However, when I go to Scheduled Jobs, everything reports as using a GMT/UTC timezone. If I click to run manually, it reports the local time. I've check the php.ini file and it has the correct timezone declared, as does the site's Settings page. Anybody got a clue?
-
We are seeing something similar in Drupal. The report listing when the emails are sent shows a 10 AM EDT time stamp. The time stamp on opens shows 2 PM. Who ever tries to fix it please check all the time stamps.– user469Mar 25, 2016 at 22:52
-
What you're seeing is a different issue from this. You may want to post it as a separate question.– Jon G - Megaphone TechMar 26, 2016 at 1:41
-
If you have a new question, please ask it by clicking the Ask Question button. Include a link to this question if it helps provide context. - From Review– Jon G - Megaphone TechMar 26, 2016 at 21:46
Add a comment
|
1 Answer
wp-cli doesn't bootstrap the settings, so doesn't load the timezone.
Because of this exact issue, I wrote a patched version of the CiviCRM extension for wp-cli to add timezone support. It's available here. As far as I can tell, the original author has abandoned the project, because they haven't merged any pull requests (including this patch) in over a year.
You can also use wget-based cron - but then you're subject to your webserver's PHP timeouts, as opposed to the CLI PHP timeout, which is usually higher (or non-existent).
answered Feb 11, 2016 at 5:33
-
I REALLY wish that I could use the wget/cURL/PHP methods. However, I get the "Invalid Username/Password" error that others have also experienced. Thanks for the patch, I'll apply that and see if I get anywhere.– G HFeb 11, 2016 at 14:01
-
Jon, doing a quick dig through, it looks like Civi has pulled this into the base code. It seems like this should be a bug report, with a simple update easily going back.– G HFeb 11, 2016 at 14:21
-
BTW, I only did the timezone piece to my install by editing wp/wp-content/plugins/civicrm/wp-cli/civicrm.php with: (Added lines 2 and 3) civicrm_initialize(); $timezone = $this->getOption('timezone', get_option('timezone_string')); date_default_timezone_set($timezone); $result = civicrm_api($entity, $action, $params);– G HFeb 11, 2016 at 14:40
-
@GH - when you say "it looks like Civi has pulled this into the base code", I'm not sure what you mean. Could you please elaborate? Feb 11, 2016 at 17:54
-
On the 4.7 install, it's got the standard CiviCRM code ownership comment above what is on GitHub. I haven't taken the time to do a diff between the installed and the GitHub version beyond that. However, because it's got the commented out section above the code, I'd assume that CiviCRM is no longer pulling from the GitHub version. I could be making a wrong assumption though.– G HFeb 11, 2016 at 18:08