[RFC|Merged] Modular cron

[DavidIQ]

One thing I'm wondering is why does cron.php need append_sid?

Based on the current set of tasks it should not. Perhaps there are tasks that could take care of something session-based, but I cannot really think of a use case.

More than likely it's because cron.php is loaded for basically all users as an image on the index page. In some cases it could cause the user to be logged off if there is no SID. That's just a guess though.

[igorw]

cron.php does a very minimal bootstrapping:

Code: Select all

// Do not update users last page entry
$user->session_begin(false);
$auth->acl($user->data);

I doubt it would mess up the session. In the worst case it would create a new guest session when cookies are disabled.

[EXreaction]

Why does cron.php load the session at all? Would save a few queries without it.

[A_Jelly_Doughnut]

Is anyone going to bother looking at and maybe committing this code, or have I entirely wasted the time I put into it?

In fact, I have looked at it I didn't really have any feedback (it looks good at this point)

[rxu]

Would be nice to have a feature to add/modify/delete cron tasks directly via ACP.

[ToonArmy]

Why does cron.php load the session at all? Would save a few queries without it.

Logging and stuff like that will probably break otherwise.

[Oleg]

As I explained in a private message to naderman (which I grant permission to forward or publish as he wishes), I will not be contributing any more code to phpbb until all of the following happens:

1. Code in modular cron branch (this topic) is merged or a person with commit rights lists the issues that need to be addressed before it can be merged, and agrees to merge it once the issues are addressed.

2. All of my remaining patches are reviewed, and 80% of them are either merged, rejected or provided with a list of issues to address (as in #1) by a person with commit rights who agrees to merge the patch once issues are addressed.

[rxu]

nn-
Contributing to phpBB is totally your free will, so you're free to start and stop it any time.
Also, personally I don't think that any kind of ultimatums to phpBB Group from anybody with imposing conditions to contribute could be acceptable.

[igorw]

To repeat one of my questions which was not yet answered afaik.

If anyone wants to help, please test forum pruning via both phpbb cron and system cron.

How would one test this via system cron? I didn't see any specific code for this, so would it be something like "curl http://localhost/phpBB/cron.php"?

1. Code in modular cron branch (this topic) is merged or a person with commit rights lists the issues that need to be addressed before it can be merged, and agrees to merge it once the issues are addressed.

2. ...

It's pretty clear that the dev team supports the proposal and the patch. As it seems to me, they have just been pretty busy, especially with both 3.0 and 3.1 to maintain / work on. While I agree that it would be nice to have all patches instantly reviewed and merged, it's a bit much to expect, imo. Give them a chance, blackmailing them will not help. Sure, it's easy to blame the dev team. But the fact is that phpBB is moving to become more community oriented. And this means that the community also needs to take responsibility to review the patches.

Your contributions are valuable, and I am sure they will be gratefully received by the phpBB teams and community. Just give it a bit of time and some kind *bump*s. This is surely the completest non-dev-member feature for phpBB 3.1 I've seen so far, and I have no doubt it will become part of 3.1. But for everything to work smoothly, both sides need to work together.

So please, do.

Not out of fear, not out of blackmail. But because we want ascraeus to be more than a pretty olympus. Thanks.

[bantu]

Impressive work.

Here are a few things I noticed within the code.

• Autoloading can now be used as per the comment in the ticket.
  This includes prefixing classes with phpbb_ etc.
• You should update install/schema_data.sql to include your new config variable.
• As a lesson learned I think we generally want every function/method documented with @return, @param etc. although it is quite easy to see what they do.
• Although PHP lacks try/finally, wouldn't it be possible to unlock cron using register_shutdown_function() if available?
• You can use an integer casting instead of the intval() function if you wish, it should be faster.

I'm almost certain this will be merged into develop at some point.