CUNY Academic Commons

There were cron issues in 3.0. Does cron not work at all on sub sites?

I didn't try any sub sites. Cron does work on the main site, but only through alternate cron or by visiting wp-cron.php directly.

WP 3.0.2, if it makes a difference. It'd make me feel better if I knew it was a core issue, as I did plenty of face-desk maneuvers while testing.

I'll do some testing. It could be that a plugin is causing it. I don't remember exactly what the cron issue was, but it involved sub sites vs the main one.

I scheduled a post in my local dev copy & it published ok. Is there something in particular that isn't working?

Email digests (using wp-content/plugins/buddypress-group-email-subscription) aren't sent when ALTERNATE_WP_CRON is off. It's possible that the problem is with the way that the plugin schedules events, but it's strange that it works with alternate cron. It could be a problem further up the cron chain, though, but I have no idea how to troubleshoot that.

I can speak about the OS crontabs, Boone.

André - wp cron is not truly cron - it fakes it by testing on page load to see whether a certain time has passed and if so, then firing an event. Though maybe it's worthwhile thinking about whether it makes sense to move some of these processes to a real cron event.

@Boone - did cron work in cdev with MU 2.9.X?

I just pushed a change into master. In the digest email, no email from values were being passed to the digest email process.

Since the digest runs once a week. I'm planning on writing a plugin that will store the results of any cron job on the main site in the database so we can examine afterward.

I just pushed a plugin into master that will log unsuccessful wp_remote_post calls on the main site.

Thanks for all this so far, Ron.

I pulled the plugin to cdev to test in the same environment as the production server. The entries in the sitemeta are giving an error. Here are two consecutive keys, which I take to be the request (http_api_debug on the way out) and the response (http_api_debug on the way in). We're getting a 401, but it's not a WP page. Does that suggest there's a server config issue at work here?

cdev has the htpass on it. The alternate cron hooks into a browser request where the default one uses a remote call. I suspected that regular cron would not work correctly in cdev because the remote call is not authenticated with apache.

Ron, is there something that André can do so that apache will allow the remote call that we need? The address being requested is commons.gc.cuny.edu/wp-cron.php, right? (

I was going to do a bit of research to see if there is a way to exclude certain urls from the authentication requirement.

Here's an example of excluding a uri from the htpasswd requirement:

http://www.webdeveloper.com/forum/archive/index.php/t-49423.html

Some of it may need to be done in the vhost entry, so I'll leave this one for Boone.

Let me know if I can lend a hand here, ok? I can easily re-conf htttpd.conf if .htaccess doesn't do it.

Sorry, that link above doesn't explain how to exclude uris from htpasswd. Doing more research.

André - does the cdev or commons user have read access to the httpd.conf or vhosts file on the Commons box? Ron wants to have a look for debugging.

Yes, Boone. How about I post the .conf to our redmine "files" section or something? Is that private?

I don't think it's private. Could you put it on Bootcamp or email it to me?

Hmm.. Basecamp is probably not ideal, because then everey time I made changes I'd have to manually upload that via BC's web ui which could be hard to script.
I guess I'll leave it up to you guys, because I believe the file is readable by default. : )

Ron - André's right, /var/httpd/conf/httpd.conf is readable by the cdev user. Shell in and check it out yourself.

We should be able to implement this: http://www.askapache.com/htaccess/apache-authentication-in-htaccess.html#allow-conditional to allow cdev to post to itself & allow both cdev's IP and 127.0.0.1 (just in case).

This looks like a workaround for the fact that cdev is protected by .htpasswd. But regular cron isn't working on the production server either, where there is no such restriction. Am I understanding this correctly?

Yes, this is just for cdev. We need to get by the password issue so we can see what other errors crop up.

Is Andre going to do the edits to the httpd.conf? He had offered above, so I was leaving that edit for him. That way he can put whatever notes on it he needs for his own documentation.

@Andre/Boone - did someone implement the changes I lniked to in http://redmine.gc.cuny.edu/issues/show/432#note-29

André, can you make the following changes? Because cdev is password protected at the httpd.conf level rather than at .htaccess, I don't believe that I have the access to do so. Presumably there is a Deny/AuthUserFile etc rule like the following somewhere in cdev's Apache configuration; we need 'Allow from' lines like I have inserted below:

Order deny,allow
Deny from all
AuthName "htaccess password prompt"
AuthUserFile /home/askapache.com/.htpasswd
AuthType Basic
Require valid-user
Allow from 146.96.128.200
Allow from 127.0.0.1
Satisfy Any

Boone, more than happy to edit that config. But it's probably better if we move that stanza to the local .htaccess file, so you guys will be able to edit it more freely going forward. What do you think?

That'd be ideal, André. Please move the whole kit and kaboodle to .htaccess (and make sure allowoverride is set). Also, could you please put .htpasswd in a place where I can read and write it - maybe in /home/cdev?

Thanks!

Will do. I'll let you all know if this breaks anything as best I can.

I believe that's already the current location for the password file, but it was owned by root. I'll change that now.

Ok, looks ok to me, but I don't know/remember the htpasswd. Let me know if it's broken, ok?

Looks good for now. Thanks, André!

Worked for me as well :)

@boone, do we need to clean out those cron log records from the DB so we can see the current ones?

Yup, I just cleared them out. I'm going to start pinging around cdev to try to get one to record.

Hi Ron,

Sorry for the delay in this - it keeps getting lost in my pile of things to do.

I just checked cdev to see if the messages have been recorded. They have, though I'm not sure what to make of them. Every few hours, a cron response like this is being recorded:
a:4:{s:7:"headers";a:0:{}s:4:"body";s:0:"";s:8:"response";a:2:{s:4:"code";s:0:"";s:7:"message";s:0:"";}s:7:"cookies";a:0:{}}

In other words, the response appears to be empty - no code or anything. Is this the same thing that was happening before? Does this mean that cdev still isn't able to make contact with itself because of htpasswd?

I've been way too busy as well. I owe you an email I think. I think that response is due to cron not having anything to do. I'll log in a little later and schedule a post.

If the scheduled post works okay we may have to dummy up some group activity so that the email digest has to run.

The post appears to have published fine. So, we'll have to drum up some activity that triggers the email digest.

I set myself up with daily digest on http://cdev.gc.cuny.edu/groups/another-test-group-for-forums/. Can we have a few people generate some activity in that group?

Also, I'm assuming mail is running on cdev?

W00t :) Nice to see that fixed even though we don't know how we fixed it.

Do you want that cron debug plugin put up on wp.org/extend? Also, don't forget to disable/remove that plugin.

Yup, I disabled the plugin in https://github.com/castiron/cac/commit/beea18a059d2d2b16164b7c6d3a23962d5f6a9ae (just commented out the add_action)

Great idea about putting it in the repo. When you get a chance, could you take care of that? I think it could go pretty much as-is - if anyone out there was feeling really ambitious, they could build an admin panel for it, but I don't think that's necessary.

I'll request the repo over the weekend and upload it sometime next week.

Nice work, guys. Thanks.

http://wordpress.org/extend/plugins/cron-debug-log/ - Should be available in a few minutes.