We have the ability to rename and re-title pages, but this becomes insufficient in the context of parent / child relationships between pages. So, we need to be able to: 1) Change the title and partial slug of a page 2) Change the parent document for a page And, when one or both of those things happen: 1) Revise the full slug of the edited page to reflect its new parent 2) Revise the full slugs of all children of the edited page to reflect the new hierarchy 3) Create redirect pages for all pages affected by the URL changes Sheppy mentioned that this is accessed via a "Move this page" command under the "This page" nav menu. Probably makes sense to do the same, here. And, since the ripple effect of changing a page slug could be huge, it may also make sense to remove the ability to edit a slug from normal document editing and require the use of this new "Move this page" command.

Ah yes, it's critical that the root page and all subpages automatically get redirects configured. Thank you for mentioning that!

Sheppy, do users do this often?

Well, the major users like jms and I do, as well as a number of core volunteers. The number drops off after that. Moving pages is something we do quite frequently.

Changing the title to better represent the feature that this provides our users.

I'm caught between two minds on this one: 1. Is it as easy as searching for "/OLD_PAGE/" (term between slashes, "starts with term/") and simply substituting strings? 2. Is it more complex and we need to use a recursive loop to look at parent -> child relationships based on ID?

Friendly all aboard ping. We scheduled this one to be completed before the next sprint. How's it looking?

The major requirements I know are: * Move the page and all its sub-pages * Leave redirects behind for the page and all its sub-pages Anything else?

* Watch for conflicts; don't allow the move if the target root page exists, unless it's a redirect (in which case you may be intentionally un-redirecting it; this happens sometimes). * Ideally, you would see a list of what will be moved before the move actually occurs, so you can be sure you haven't inadvertently chosen to move more than you meant to; we did this semi-often on MindTouch.

Also it should be case-sensitive. A lot of, but of course not all, the slug rename (hence page move) are to fix erroneous casing in the original slug.

Implementation is done. Merging will happen with bug 805147.

Raymond, copying you on this for exploratory testing. The feature has landed, but is complex enough to warrant some additional research.

I'm going to change this over to bug 902599.

Adding this to redesign blockers

I just tried to move XUL->Mozilla/XUL and got this: http://pastebin.mozilla.org/3312489

Note: when I received that error, a big number of XUL pages moved over to Mozilla/XUL which I didn't expect. I expected everything to roll back to XUL in the case of any errors.

I have a fix for the mindtouch ID bits of this, still not sure why the transaction decorator didn't roll back the whole thing though :/

:sheppy - do we have a list of the planned page-moves so I can spot-check them locally?

(In reply to Luke Crouch [:groovecoder] from comment #19) > :sheppy - do we have a list of the planned page-moves so I can spot-check > them locally? No list. Just a lot of stuff in our various heads. Here are some examples: https://developer.mozilla.org/en-US/docs/XUL --> https://developer.mozilla.org/en-US/docs/Mozilla/XUL https://developer.mozilla.org/en-US/docs/XPCOM --> https://developer.mozilla.org/en-US/docs/Mozilla/XPCOM

More trees that have to move: https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference --> https://developer.mozilla.org/en-US/docs/Mozilla/XPCOM/Interface_reference https://developer.mozilla.org/en-US/docs/XPConnect --> https://developer.mozilla.org/en-US/docs/Mozilla/XPConnect https://developer.mozilla.org/en-US/docs/NSPR --> https://developer.mozilla.org/en-US/docs/Mozilla/NSPR There are also hundreds and hundreds of individual pages that will have to move, because they're at the top level of the site hierarchy and ought not to be.

bam: https://github.com/mozilla/kuma/pull/1548

Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/89648212a9673c57af0e06ac00fda4b5311780e1 bug 764431 - drop old mindtouch fields from models https://github.com/mozilla/kuma/commit/68613ed7b8d9e616dec11950cbc09a9f806f02f4 Merge pull request #1548 from groovecoder/page-move-764431 bug 764431 - drop old mindtouch fields from models

How is this working on prod now? I've moved a couple small things with it but nothing major. Are we waiting on the email confirmation fix before we do bigger moves?

So far so good. Haven't done a lot yet, though. I'll keep you posted.

Another 2 weeks gone by ... ready to close this yet?

fwiw, I moved 112 pages at once on Saturday. https://developer.mozilla.org/de/docs/CSS/ --> https://developer.mozilla.org/de/docs/Web/CSS/ No problems so far. Breadcrumbs look good. Redirects are in place.

This is officially fixed!