1

I've got a puzzle. After updating to CiviCRM 4.7.27 (from 4.7.23) on WordPress, suddenly the civicrm cron jobs stopped being run. With some digging, I found that the credentials for the user I had set up to run cron were being rejected ("ERROR: Invalid username and/or password").

I confirmed that the username, password and site key were all correct (none of them had changed), but I still can't get it to work. I even created a new user with a new password, but that also failed. Both users have the correct permissions to access CiviCRM, etc. as specified in the documentation. I am even able to log in directly to WP using these credentials; they are only rejected in the context of a call to run cron.php.

I use the URL method of calling cron.php, which includes the username, password and site key in the full URL.

This isn't critical - I can still run it manually from inside CiviCRM, but I have already spent a lot of time on this and don't want to spend much more.

CiviCRM 4.7.27
WordPress 4.8.3, with WordFence 6.3.21, all plugins up-to-date
CentOS 7, with the standard PHP 5.4.16 as supplied by the main CentOS repositories

Thanks in advance!

Improve this question
4
  • Could you have a look at the Troubleshooting section in docs.civicrm.org/sysadmin/en/latest/setup/jobs and permissions for cli.php and cron.php. You may need to change permissions to 744 to allow execution in /wp-content/plugins/civicrm/civicrm/bin/cli.php and cron.php. I have to do this after every update of civicrm in wordpress. Hope this helps.
    – peterb
    Commented Nov 10, 2017 at 21:35
  • If the error message is "ERROR: Invalid username and/or password" then cron.php is executing so it can't be filesystem permissions?
    – Chris Burgess
    Commented Nov 11, 2017 at 0:08
  • Thanks for the suggestion: permissions for /wp-content/plugins/civicrm/civicrm/bin are 775, and for both cli.php and cron.php they are 664. It's unusual to give write access to the group, but at least that should mean the user has access. I thought the executable bit was only for directories? Anyway, setting it for cron.php didn't change anything, sadly.
    – SJNorton
    Commented Nov 11, 2017 at 4:43
  • Did you manage to track down the cause? Another person reported very similar problems with WP/Civi today.
    – Chris Burgess
    Commented Nov 20, 2017 at 18:42

1 Answer 1

Reset to default
0

I'd try to run CiviCRM cron via the CLI. If your webhosting has CLI access, you can do this using wp-cli or cv. Both will let you execute CiviCRM's scheduled jobs. See Managing Scheduled Jobs > Command Line Syntax for setup instructions.

I can't say why you're running into issues, and I don't know why you'd have started having issues at the upgrade of 4.7.27 - that's worth looking into (and could be worth debugging - you'd start by checking the input variables are correct when that error is thrown in CRM_Utils_System::authenticateScript()).

It could be that WordFence is playing a part in this. CiviCRM's URL cron method involves putting the username and password into GET parameters, which isn't generally a recommended practice (those details can be leaked from GET, see note here). It wouldn't surprise me if WordFence detected and removed sensitive variables in GET params; another possibility is that WordFence might block a user if it detected them logging in every few minutes (as could be happening with URL cron). This is speculation; I don't know WordFence at all.

If CLI cron is available to you, that approach might mitigate this situation, and would at least avoid the possibility of leaking your CiviCRM scheduled job user credentials. It's not a guaranteed fix and I do recommend a shot at debugging what's actually happening, especially if it means resolving some new bug that's sneaked into 4.7.27!

(This isn't a very certain answer, but I hope it helps!)

Improve this answer
4
  • Thanks for your comprehensive reply! I would love to work at debugging it, but I really don't know what I'm doing and this is a production web site, so... However, I installed wp-cli, set up the cron job to call it, and everything seems to work as expected. I can see that this is a much cleaner way to do it, but of course I have to have full access to my system (which I do, on a Linode, but I would not have had in the past).
    – SJNorton
    Commented Nov 11, 2017 at 5:16
  • So, it's working, but the original mystery remains unsolved. If someone could help me with the steps to do that, I'd be interested in debugging it at a less busy time. Thanks, all!
    – SJNorton
    Commented Nov 11, 2017 at 5:17
  • By the way: I had Wordfence running before this all came up, but I upgraded it to the paid (premium) version at basically the same time I updated CiviCRM. I suppose a first test would be to disable it and try the URL method again.
    – SJNorton
    Commented Nov 11, 2017 at 5:23
  • Maybe WordFence has logging somewhere, that says what it intercepted? Let us know how you get along!
    – Chris Burgess
    Commented Nov 11, 2017 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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