Last modified: 2014-08-05 01:11:34 UTC
The url shows: <protection> <pr type="edit" level="sysop" expiry="infinity" /> <pr type="edit" level="sysop" expiry="infinity" /> <pr type="move" level="sysop" expiry="infinity" /> <pr type="move" level="sysop" expiry="infinity" /> <pr type="edit" level="sysop" expiry="infinity" /> <pr type="move" level="sysop" expiry="infinity" /> </protection> Why get each type added three times to the output? It is not better to get it unique? Thanks.
I'm not sure why it'd be "better" to get them unique. http://en.wikipedia.org/wiki/%s say's it's a bad request Using the page id... A direct SQL query only gives me 2 results, being one after the other protections, both edit=sysop:move=sysop 3 edit and 3 move is weird http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=&page=%25s&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1 (show/hide) 22:45, 12 November 2006 Ral315 (Talk | contribs | block) protected "%s" (No real article can be written here, and it's used by Firefox users to search. No need to edit further. [edit=sysop:move=sysop]) It seems to be a weird edge case. I dunno, seems something we shouldn't really care about/bother filtering (ie WONTFIX)
Looking at the database it's got restrictions both in the page.page_restrictions field (old style) and in the page_restrictions table (new style). Where the third pair comes from I don't know.
Unless it's creating something for the rows with both, making the third row with double restrictions?
The problem is, that updateRestriction.php only copy the page_restriction and does not remove it from page table. That sounds like space waste. When a wiki has never run updateRestriction.php the api shows no protection with prop=info&siprop=protection. That is because old restrictions are only check for pages with new protection, useless when updateRestriction.php was run. But the problem for this bug is, that the table page_restrictions contains two rows for one page, one for edit and one for move, for each of that both old protection are added type="edit" -> new style, from table page_restrictions type="edit" -> old style, from page.page_restrictions type="move" -> old style, from page.page_restrictions type="move" -> new style, from table page_restrictions type="edit" -> old style, from page.page_restrictions type="move" -> old style, from page.page_restrictions
(In reply to comment #4) > The problem is, that updateRestriction.php only copy the page_restriction and > does not remove it from page table. That sounds like space waste. > When a wiki has never run updateRestriction.php the api shows no protection > with prop=info&siprop=protection. That is because old restrictions are only > check for pages with new protection, useless when updateRestriction.php was > run. > But the problem for this bug is, that the table page_restrictions contains two > rows for one page, one for edit and one for move, for each of that both old > protection are added > type="edit" -> new style, from table page_restrictions > type="edit" -> old style, from page.page_restrictions > type="move" -> old style, from page.page_restrictions > type="move" -> new style, from table page_restrictions > type="edit" -> old style, from page.page_restrictions > type="move" -> old style, from page.page_restrictions That is better after I52111f30, because the values from page.page_restrictions not repeated a second time, but dupes still exist.
*** Bug 62247 has been marked as a duplicate of this bug. ***
