Last modified: 2007-06-29 15:21:42 UTC
For some pages a wrong protection status is delivered by prop=info&inprop=protection. Example: http://de.wikipedia.org/wiki/Schule is semi protected since 2006-10-02 (see http://de.wikipedia.org/w/index.php?title=Spezial%3ALogbuch&type=protect&user=&page=Schule ) but prop=info&inprop=protection&titles=Schule returns an empty protection value. same behaviour for http://de.wikipedia.org/wiki/Hauptseite - protected since 2006-09-02 Is there a problem with old protections?
The API implementation uses the protections table which was introduced in MediaWiki 1.9. I'll find out how pre-1.9 versions did their protections and check for them too. Can you confirm that this bug only occurs with pages that were protected prior to upgrading to 1.9? If you're not sure, ask an admin to unprotect and reprotect [[de:Schule]], and see if the API returns the correct value after that.
Rectification: it's actually called the page restrictions table, and it was added in 1.10. 1.9 has it in the page_restrictions field in the page table, and I'm writing a patch right now that checks both.
Created attachment 3838 [details] Lists pre-1.10 protections in inprop=protections The attached patch fixes this.
Only old protections seem to be affected - after unprotecting and reprotecting [[de:Schule]] the API result is correct.
The ideal fix would be to run a script which migrates the restrictions in batches. We appear to have one, in the form of maintenance/updateRestrictions.php.
*** This bug has been marked as a duplicate of bug 9386 ***
(In reply to comment #6) > *** This bug has been marked as a duplicate of bug 9386 *** This is not a dupe: bug 9386 is about Special:Protectedpages, this is about the API. Special:Protectedpages could be patched a la the patch I've submitted.
No, bug 9386 is about dealing with the problem that's also causing this bug, and the original report there. The "correct" solution for this bug is to migrate the old data, not to keep poking backwards-compatible checking into the code where it's not needed. *** This bug has been marked as a duplicate of bug 9386 ***
