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

RESOLVED FIXED

Status

developer.mozilla.org
General
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: lorchard, Unassigned)

Tracking

Details

(Whiteboard: [specification][type:feature])

(Reporter)

Description

5 years ago
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}
(Reporter)

Comment 1

5 years ago
Blocking the content zones MVP, cc'ing people
Blocks: 907234
(Reporter)

Comment 2

5 years ago
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
(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'?
(Reporter)

Comment 4

5 years ago
(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
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.
(Reporter)

Comment 6

5 years ago
(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
(Reporter)

Comment 7

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

https://github.com/mozilla/kuma/pull/1386
What will happen if someone creates an /Apps page and then a user, on the old design, visits developer.mozilla.org/Apps?
(Reporter)

Comment 9

5 years ago
(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
(Reporter)

Comment 11

5 years ago
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.
Blocks: 861991
No longer blocks: 907234

Comment 12

5 years ago
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

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.