Author: mike.lifeguard+bugs
Description:
This was reported to me by Darklama@enwikibooks:
When moving Page along with subpages, where Page/Subpage does *not* exist but Page/Subpage/Subsubpage *does* exist, that subsubpage is not moved. I'll link to the log once I find it.
Version: 1.13.x
Severity: minor
ayg wrote:
I've tried this on my test wiki and it works fine. Please report if you can reproduce it consistently. Also note if it's simply not on the list of moved pages, or if there's an error message for it.
There's no reason why this shouldn't work, in general. Perhaps some other issue prevented the particular page from being moved (protected? created as the move was being processed?) and Darklama assumed it was because the intermediate subpage didn't exist.
darklama wrote:
I don't recall seeing any error message and none of the pages were protected. The pages weren't moved and they weren't listed as being moved. I made the assumption it was due to intermediate subpages not existing because that is what appeared to be the case. A lot of unmoved pages without intermediate subpages. However the move code doesn't support that theory, so I now think it could be due to $wgMaximumMovedPages if its set to 100, because that is about how many pages I think were moved from a rough count. I attempted to rename [[b:Special:Prefixindex/Programming:WebObjects]] to [[b:Special:Prefixindex/WebObjects]] when I encountered the problem. If this is the source of the problem, than it should be fixed so there is some way to continue moving pages where it left off or perhaps put the moves on the job queue.
ayg wrote:
It looks like you moved 97 pages, so theoretically you should be under the count, but who knows. If there's consensus on Wikibooks to raise $wgMaximumMovedPages, you can open a bug requesting that. Or open one requesting that there be some improvement made so that moves can be picked up where they left off. (Clearly, you could do so already just by moving the main page back by itself and re-moving it with subpages.) A message is printed when no more pages will be moved due to reaching the limit, but it's all the way at the bottom and easy to miss.
It looks like this particular issue doesn't exist, in any event.
mike.lifeguard+bugs wrote:
Well admins are supposed to not be rate-limited on anything, and only admins can do move-subpages (though not necessarily). So I think it doesn't make sense to have a max number of pages to move anyways - unless non-sysop users may do move-subpages (but then, they already have a rate limit, so it still doesn't really make sense because they will hit the rate limit first unless it is higher than $wgMaximumMovedPages)
ayg wrote:
$wgMaximumMovedPages isn't meant to slow down vandals so they can be reverted more easily, it's meant to prevent insane amounts of log spam. If someone moved 1000 pages at once, it would probably fill up all of RC within a second. It also could cause considerable confusion if it took many seconds to move all the pages, which may be possible (they're moved one by one now): odd things could happen if someone moves a page to some other place while it's waiting to be moved.
1000 is probably a more sensible default if it's sysops-only, though. I originally set it to that before I realized the issues that could occur with deliberate log spam by vandals. But really a better interface (in terms of logs, especially) would be best for this kind of mass operation. If we could condense the entire move with subpages into one log entry when viewing RC/overall move log/contributions/watchlist, but display them individually when viewing the log history for an individual page, that would be a big improvement.
mike.lifeguard+bugs wrote:
Just to note that wgMaximumMovedPages was upped to 500 for us. Should be ok for /most/ things (though as always higher is better!)