Last modified: 2010-05-15 16:03:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14575 - Moving subpages doesn't move subpages that have nonexistent parents
Moving subpages doesn't move subpages that have nonexistent parents
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.13.x
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-18 00:42 UTC by Mike.lifeguard
Modified: 2010-05-15 16:03 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mike.lifeguard 2008-06-18 00:42:33 UTC
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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-18 13:10:35 UTC
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.
Comment 2 darklama 2008-06-18 13:39:04 UTC
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.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-18 13:45:46 UTC
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.
Comment 4 Mike.lifeguard 2008-06-18 15:04:44 UTC
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)
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-18 21:45:18 UTC
$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.
Comment 6 Mike.lifeguard 2008-11-25 03:42:15 UTC
Just to note that wgMaximumMovedPages was upped to 500 for us. Should be ok for /most/ things (though as always higher is better!)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links