Introduce pretty permalinks for Customizer

[westonruter]

In #28536, celloexpressions suggests:

it would be nice if users could see the URL being previewed in a readable manner. And it would be cool if the url was more contextual to the page being customized. What about implementing support for ​http://example.com/sample-page/customize-like URLs, similar to what the front-end editor does?

Currently, when previewing a specific URL, this URL appears in the url query parameter and is URL-encoded—making it unreadable. While a customize rewrite endpoint is one approach, for example:

/2014/04/01/hello-world/customize/

This could potentially introduce conflicts with existing rewrite rules. Another approach would be to introduce a new rewrite base, for example:

/wp-customize/2014/04/01/hello-world/

Special care will be needed when the domain of the admin is different than the domain for the site appearing in the preview.

Note that any return or theme query parameters would need to remain attached to the above URL:

/wp-customize/?return=http%3A%2F%2Fexample.com%2Fwp-admin%2F

See also #25457

[celloexpressions]

I would definitely be in favor of figuring out how to make it happen with /2014/04/01/hello-world/customize/, because then in conjunction with pages (#27406), we could use /2014/04/01/hello-world/customize/widgets/ for deep-linking and contextually updating the url when navigating in the customizer (I wouldn't do that for sections/subsections, only parent sections/pages). This certainly isn't my area of expertise, but I think we should be able to make it work around any conflicts.

[westonruter]

Or deep linking could be served by query parameters or fragment identifiers.

[celloexpressions]

Replying to westonruter:

Or deep linking could be served by query parameters or fragment identifiers.

Right, but that wouldn't be as pretty :)

It would be awesome to come up with a way to beautify all of the core query args, but that probably isn't realistic. In terms of conveying purpose with the URLs, I think incorporating the front-end URL, customize, and the customizer page/section if it has multiple contexts as #27406 suggests would be the most important parts to make readable.

[celloexpressions]

Needs patch still, but we'd like to take a look at this in 4.1 along with other related tickets (see IRC logs).

[wonderboymusic]

There should be conversations about how to do routers better across the board. The router for Media Grid is not a great example of how to implement. It should be something that is baked into the architecture, not duct-taped on.

[wonderboymusic]

I am moving this into the backlog until there is a patch - there are a lot of Customizer tickets. If a patch materializes, great.

[celloexpressions]

This isn't as closely tied to the other batch of tickets we're doing here, so we can leave it in Future Release for now, but it should really happen in 4.1 along with deep-linking, in-Customizer navigation, etc.

[celloexpressions]

While this would still be nice to have, it doesn't result in much of a usability improvement compared to some other long-standing issues. Given that a big API for routers and/or significant customize refactors are not likely to happen at this point, efforts would be better spent on issues with direct user-oriented improvements (like browser history and deep linking in #28536 - without pretty permalinks).

I'll close for now, but feel free to reopen with a patch.