Last modified: 2012-10-15 04:37:47 UTC
After making a dumbass mistake on commons by editing a high-use template for a stupid reason (and raising the job queue to an unreasonably high number), I figured these sort of mistakes by dumbasses could be avoided in the future. It'd be nice if someone made a patch that ignored edits when they were done to an area of the template that was between a <noinclude> and </noinclude> (or if the edit itself added <noinclude> to the template). I'm not too much of an advanced programmer but I figure a check should be made in the diff text before the request is sent to the job queue to see if the edit was made in a non-included area. Also, I'm not sure if this warrants a bug report so if it does please split this. I accidentally edited the template (a high use one as previously mentioned) three times because all three times the template page didn't load after the edit took place (I got the standard wikipedia is down message, the edit was on commons though). Of course not being stupid would be a better fix but that's uncurable. ;/
To clarify the above, other edits were going through fine at the time (edits to other commons and wikipedia pages).
cf bug 8322
Is bug 8322 really related to this one? I mean, here we have the opposite problem: Job queue submission reacts on every change to the template, not just a change in the preprocessed source (for transclusion), isn’t it?
Too much of a special case check. This is an easy way to end up with errors and unmaintainable code.
What you could do is run the extractions on the old and new versions of the page, and only submit the updates if there's a change. In theory, that should work reasonably reliably. In theory. :D It doesn't sound like _too_ evil a hack, and avoiding spamming the job queue would be nice.
(In reply to comment #5) > What you could do is run the extractions on the old and new versions of the > page, and only submit the updates if there's a change. > > In theory, that should work reasonably reliably. > > In theory. :D > > It doesn't sound like _too_ evil a hack, and avoiding spamming the job queue > would be nice. > This is done already.
Changing all WONTFIX high priority bugs to lowest priority (no mail should be generated since I turned it off for this.)