On Tools->Scheduler you have to manually select a task and give it a frequency to run. Once saved there is no way to edit a scheduled task. You select a task based on the name found in the plugin's GetCronJobs(). No matter what frequency you select, the actual cron job limits what frequency will actually occur, which kinda comes back to item 1 in that you have to actually create a real cron job to get the whole thing rolling in the first place. The actual real cron job seems to be a whole bunch of guesswork, for me anyway..
When you have multiple tasks scheduled, exec_cron.php will only do the next one due to "limit 1" in the query.
When you uninstall a plugin that makes a cron job that you added to your Tools->Scheduler it does not remove it from the schedule.
- (1) The list of requirements for running QP does not include not running on a windows server, but any plugin that uses the *CronJob?() hooks is basically requiring that.
There are 3 potential solutions I see to this:
- we throw out the idea of doing cron jobs and scheduled tasks.
- we require and test for not-windows servers (which actually should be testing for the ability to run a cron job).
- we test for windows servers (which actually should be testing for the ability to run a cron job) and develop a way to simulate cron jobs on windows servers (which actually should be simulating on servers that can't run a cron job). Of these I like #3 even though I don't like cron jobs.
- (2) This seems really bad. I'm user #1 and have no restrictions on me of any kind, but I can't edit a task once scheduled. I can see it, or delete it.
The solution is obvious: I should be able to edit the task in the same way I can edit plugin settings. Perhaps with a warning saying you might screw shit up the way turning off a hook on a plugin's settings page warns you?
- (3) This is just wrong. For example the captcha plugin uses these 2 hooks, but whatever it is doing with them probably doesn't get done for the vast majority of users because it doesn't tell us "go do 2 different tasks to make something happen".
It seems to me GetCronJobs() *could* contain all the info required. In other words the returned array contains "name, ctrl, params". So add "sched", or "mins, hrs, days, wks, foo, bar" the way the actual cron job schedule is built. Item #2 says we could then edit the task(s) if we desired, but installing the plugin would automagically add the task.
- (4) The drawback here is that I told my task to run every 10 minutes and it didn't - because the actual cron job was running once per hour - so I better post a bug report in the forums...
This one sucks to fix because it can only be done by informing plugin authors and especially installation owners. Installation owners need to know they need to set up a cron job and that their cron job will control task frequency. We then suggest they run their actual cron job every hour. For plugin authors, after we do the solution in #3 we then make sure they know the installation owner is suggested to run every hour and therefore their plugin should not try to run more often than that.
- (5) No actual cron job means none of this stuff will happen at all ever period.
We need to clearly inform the user or installation owner that any plugin using the *CronJob? hooks will not work if they do not actually build a real cron job. Unfortunately I can't find via google a way to tell if a server is capable of running cron (the assumption is all non-windows servers can but that doesn't mean permission exists), nor can I find a way to tell if there are any cron jobs scheduled that end in "qp_srvc/cron_exec.php" which would tell us they got it set up.
- (6) Probably more accurate to say that exactly what your actual cron job needs to say depends on a heck of a lot of situation-specific information. Root domain? Subdomain? Folder under either root or subdo? Server limitations in general?
Solutioning this is hell.
- That other app said "wget -q -O filename.html http-to-cron_exec.php" but that did not work for me. Don't have the link handy, but it is on their manual. It also attempts to output the info to a file instead of email. The file got created but was empty even though the cron job never actually ran for me using wget, so I dunno.
- Apparently creating an output file assumes wget will work. For me, wget failed although I did not guess my way through all possible ways to do it. usr/bin/wget for example. I found something that works for me. Doesn't mean it is the only way that can work for me, nor does that mean it all users out there will be able to use the same way as me.
- Randomly guessing my way through it, with a bunch of help from google, I came up with "php -f /home/whatever/name/folder_name/qp_srvc/cron_exec.php. I also know that adding a -q will reduce the amount of emails the actual cron daemon sends. Then there was something about dev/null can tell it to shitcan any messages the daemon generates, but that seemed to be a "maybe based on server limitations". (for testing I wanted those emails so I didn't even try dev/null/whatever stuff.)
- ANYWAY all I can think of is to finally put out a reasonably useful tutorial about what MIGHT work and why. Assume folks gotta do it through cPanel, and try to explain the diffs between wget and php including what types of arguments you can make with either of them. Offer sample strings that might work depending on if they work or not. Finally, describe a way to test their environment. For example "set up a cron job to run every 5 minutes and give it a valid email addy then check your email in 5 minutes and see what that says".
- (7) There seems to be a good reason commented in the code, but again this will only lead to trouble based on misunderstanding what the plugin authors and installation owners need to be doing based on how it works.
I'm not really sure on where I'm at with a solution. One method would be to say "it only does one each time your actual cron job runs so deal with it". Another, IMHO better answer might be to do something like "foreach( tasks as a_task)" then loop through whatever is scheduled.
- (8) The actual cron job sends you an email with an erro message from the core, and the core reschedules the task.
Another easy solution, especially after item 3 is addressed: when uninstalling a plugin that uses the cron hooks it should remove itself from the scheduled tasks list.
AND, getting back to item #1, we still won't have a way for any of these tasks to get done on a Windows server. Thus, I come back to a simple idea of mine that wasn't all that well thought out but needs to be considered in some way: a once per day hook. Actually it should not be a hook. It should be a bit of logic that looks at the cron job stuff AND the fact that we're on a Windows server OR the fact that none of the scheduled tasks are getting done (due to being on a Windows server or because the install owner, for whatever reason, does not have an actual cron job hitting qp_srvc/cron_exec.php), then do them. Ideally with the "foreach" type of thing where we limit the tasks to one per plugin such that each task is done at least daily. This action I would easily tie in with the way autopruning is triggered by the first hit of the new day.
Oh and I would ditch the canned tasks, but only because I have no idea what value they offer an installation. If any
- Posts: 2072
- Joined: Sun Nov 22, 2009 7:20 am
- Location: Maricopa Arizona