912084 - Content zone URLs need to break out of /{locale}/docs/ URLspace

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: General, defect)

Description

[Les Orchard [:lorchard]]

What problems would this solve?
===============================
Content zone pages are wiki documents, and wiki documents live at /{locale}/docs/{document path}. 

But, we'd like them to live at paths like /apps/ and /program/

So, we need a way to serve content zone documents up from more flexible URLs

Who would use this?
===================
Content zone maintainers

What would users see?
=====================
Content zone documents at URL paths outside of /{locale}/docs/

What would users do? What would happen as a result?
===================================================
Users would visit content zones and see URLs not under the /{locale}/docs/ URLspace

Is there anything else we should know?
======================================
Some initial notes & questions:

* Is it correct to assume that a redirect from /apps/ -> /{locale}/docs/apps is insufficient?

* We easily can't get rid of the /{locale}/ part of the URL, so there will at least be a redirect from /apps/ -> /{locale}/apps/

* First thought is to do per-case tweaks to .htaccess and/or urls.py for zones, but this is not a general solution

* We'll need some tweaks to determining the canonical link to a wiki document - eg. for the CKEditor link dialog, and elasticsearch.

* Ideally, these docs would not be served up from two places - ie. /{locale}/apps/{path} vs /{locale}/docs/apps/{path}

* That also raises the issue of if or how to handle an attempt to create a doc at /{locale}/docs/apps/{path} when a content zone has relocated the docs to /{locale}/apps/{path}

Comment 1

[Les Orchard [:lorchard]]

Blocking the content zones MVP, cc'ing people

Comment 2

[Les Orchard [:lorchard]]

Another thought: Maybe create a /{locale}/docs/zones/{path} URLspace that's "special", in that those docs under zones/{path} are actually served up from /{locale}/{path}. 

We could wrap that document tree with access controls, and could otherwise isolate that tree from the rest of the wiki for special handling

Comment 3

[Eric Shepherd [:sheppy]]

(In reply to Les Orchard [:lorchard] from comment #2)
> Another thought: Maybe create a /{locale}/docs/zones/{path} URLspace that's
> "special", in that those docs under zones/{path} are actually served up from
> /{locale}/{path}. 
> 
> We could wrap that document tree with access controls, and could otherwise
> isolate that tree from the rest of the wiki for special handling

I'd figured we'd be able to have pages that were both a regular landing page and the base of a zone, but sounds like that's not happening. I guess we will need to create zone pages that then enclose all of the related tree of content instead.

Will it be possible to have a zone that says 'all pages under /docs/Web are part of this zone'?

Comment 4

[Les Orchard [:lorchard]]

(In reply to Eric Shepherd [:sheppy] from comment #3)
> (In reply to Les Orchard [:lorchard] from comment #2)
> > Another thought: Maybe create a /{locale}/docs/zones/{path} URLspace that's
> > "special", in that those docs under zones/{path} are actually served up from
> > /{locale}/{path}. 
> > 
> > We could wrap that document tree with access controls, and could otherwise
> > isolate that tree from the rest of the wiki for special handling
> 
> I'd figured we'd be able to have pages that were both a regular landing page
> and the base of a zone, but sounds like that's not happening. I guess we
> will need to create zone pages that then enclose all of the related tree of
> content instead.
> 
> Will it be possible to have a zone that says 'all pages under /docs/Web are
> part of this zone'?

Yes, that's basically what we came up with and I implemented for bug 907236. 

A document gets converted into a zone with the attachment of a DocumentZone object. Then, every child of that document inherits the custom zone CSS (bug 907238) and common navigation (bug 862080). I'm thinking that this bug adds an URL relocation feature to DocumentZones, and all children of a given zone move along with it

Comment 5

[Eric Shepherd [:sheppy]]

But what about when you don't want it to move. We don't want all the pages under /docs/Web to move, even though we need a Web zone. All that documentation needs to stay where it is.

Comment 6

[Les Orchard [:lorchard]]

(In reply to Eric Shepherd [:sheppy] from comment #5)
> But what about when you don't want it to move. We don't want all the pages
> under /docs/Web to move, even though we need a Web zone. All that
> documentation needs to stay where it is.

I think the URL relocation thing can be an optional Zone feature

Comment 7

[Les Orchard [:lorchard]]

Got an initial pull request for this that does most of the work:

https://github.com/mozilla/kuma/pull/1386

Comment 8

[John Karahalis [:openjck]]

What will happen if someone creates an /Apps page and then a user, on the old design, visits developer.mozilla.org/Apps?

Comment 9

[Les Orchard [:lorchard]]

(In reply to John Karahalis [:openjck] from comment #8)
> What will happen if someone creates an /Apps page and then a user, on the
> old design, visits developer.mozilla.org/Apps?

This is independent from the design. So, if a zone is assigned a url_root of "Apps", everyone sees it at /Apps

Comment 10

[[github robot]]

Commit pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/3c03e59940125d9d91fa13e773059d047c9ee33a
bug 912084: Redirect/rewrite Middleware for zones

Comment 11

[Les Orchard [:lorchard]]

Second half of this work has a PR:

https://github.com/mozilla/kuma/pull/1415

This should take care of remapping wiki URLs as they appear in links, buttons, search & etc as generated by Kuma. 

It won't rewrite URLs in document content. But, that shouldn't be the end of the world because a) there shouldn't be very many of them (if any) and b) the middleware will automatically redirect them to the proper location until/unless they are updated.

Comment 12

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/a42c499ecf8a46f35d7afbfb6525d4e3a6d44e01
fix bug 912084: Remap wiki URLs constructed via sumo.urlresolvers.reverse() for content zones

* Hack in sumo.urlresolvers.reverse() to apply URL remaps for wiki
  content zones

* Bug fix to constrain zone remaps per locale

* Tests

https://github.com/mozilla/kuma/commit/2fbcf292d207c4665b28ab4fa45ecd9d6539899f
bug 912084: Cache wiki URL remap queries

https://github.com/mozilla/kuma/commit/7cffdf6f79f0a2c32699582d6fd63629f7586240
Merge pull request #1415 from lmorchard/912084-remap-wiki-url-construction

fix bug 912084: Remap wiki URLs constructed via sumo.urlresolvers.reverse() for content zones