Assigning to Tim.

There's not really a mechanism for scheduling jobs to a particular time, but it can probably be hacked up... On running, the job could re-file itself to run again later if a minimum time limit hasn't passed. It might run through a few times if the queue's light, then finally run for fun.

Started toying around with an extension today that goes a bit further...

Called ApproveJobs, it allows wiki admins to define jobs that require approval before being executed. I think this might solve some of the problems. Adds a simple flag to the jobs table on whether or not to release a particular job. Special:ApproveJobs allows anyone with the approve-job right (default: sysops) to release the job for processing. Also adding a 'bypass-job-approval' right that allows a user to have a job entered directly into the database and not require approval prior to execution.

Should have a working demo in a few days (trying to figure out where the best place for hooks are atm).

On second thought, it might be easier to put this directly into core (disabled by default).

I can't seem to find a good place to hook cleanly that will make sense in general (would be rather purpose specific...)

The job queue is for background maintenance tasks which should never, ever require any human intervention.

A manually-moderated queue for user operations like page moves and deletions would make sense (and I believe there's some existing work on a deletion queue extension, which may or may not be applicable to page moves).

The redirect fixer will be disabled after deployment of r41716, assuming $wgFixDoubleRedirects is left at false, which I'd recommend. It's obviously doing more harm than good. A different architecture is required.

Would it still help to trigger for admin page moves or "Editor" page moves on .de wiki and the like?

On some wikis it would help a lot. On huwiki, we have a hand-managed user class for people with autoreview rights; they are reliable (at least to the extent of not committing vandalism) and most of the active contributors are in that class, so giving it auto-redirect-fixing rights would account for most of the page moves.

mohamed.m.k wrote:

Yes please enable the feature to admins only instead of disabling it altogether because of some annoying vandals!

We don't currently have plans to revive this extension, and now have the ability to have longer redirect chains.

Perhaps increasing $wgMaxRedirects would be a better way to fix the same problem.