Refresh jobs generated by changing page protection, fun.

You know, this makes me wonder if we should just introduce some sort of abstract "refresh links" table. Every time a page used something like {{PROTECTIONLEVEL:Foo}} or {{#isblocked:Foo|bar|baz}} we would call something like $parserOutput->refreshLink( 'protection', 475 ); or $parserOutput->refreshLink( 'blocked', 5 );

Then hooks or whatever could just initiate a refresh job for something like ( 'protection', 475 ) when the protection level of page_id = 475 was changed and any pages that used something like that would be refreshed.

Due to fix of bug 17970, this should get a higher importance.

Any progress on this?

Anyone?

Probably changing page protection should just call WikiPage::doEditUpdates()?

Or WikiPage::doUpdateRestrictions() should clear some caches itself.

I would like to work on this. I am new to wikimedia development. Can anybody guide me in fixing this?

Hey! I am new here and needed some guidance on fixing this.
I am a little confused here... What exactly do you mean by "some links depend on them"? And which table exactly needs to be updated? An example would be helpful. :)

I'm not sure if this was the exact case that was originally being pointed out, but I reproduced this bug by doing the following:

• Installed Extension:ParserFunctions
• Created a new page (not protected)
• Put an if statement in the new page: {{#if: {{PROTECTIONLEVEL:edit}} | http://somelink.com | nothing }}, which displayed "nothing" since there was no protection level
• Checked in the externallinks table, there was no entry for http://somelink.com.
• Protected the page, the if statement then displayed http://somelink.com.
• The externallinks table was still not updated, but should have been.

The issue almost certainly extends to the other link tables too. I don't know whether the if statement is the only way to make a link depend on the protection level, though.

Hope this helps. :)