602952 - Resolve dekiwiki and django url handlers

Status: VERIFIED FIXED

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Description

[Austin King [:ozten]]

Currently Deki and Django battle to handle some urls such as
https://developer.mozilla.org/de/HTML/HTML5

We're broadening the scope of MDN and the documentation aspect, although core, should live under /doc
* Serviced by dekiwiki now
* Eventually by the SUMO/MDN wiki Django app

So our url will be something like 
https://developer.mozilla.org/doc/de/HTML/HTML5

1) Document changes to put deki under /doc
2) Figure out best way to redirect (301) all existing wiki pages to a location under /doc. This can be a static snapshot if that is more performant.

Comment 1

[Eric Shepherd [:sheppy]]

This makes me nervous; we got into a lot of problems when we moved everything from /doc/ down to the root level of devmo, so moving it back will probably just confuse things again. As long as we have good redirects, that should be okay, but we ran into problems with search engines not doing a good job dealing with the move last time (Google still routes people to the old URLs, even after all this time, for example).

Comment 2

[Fred Wenzel [:wenzel]]

When using proper 301 (permanent) redirects, Google is usually very fast at picking up changes. I agree that we need to ensure these redirects are in place.

I'd also go for an option that doesn't require us to put Deki onto a subdir, but if we are going to deprecate Deki (which is what we still want, right?) then we need to bend Deki to be part of the new Django site, not vice-versa. Another option would be changing Deki's domain (devwiki.m.o or something?) but that'd involve the same kind of redirects. So we should only do that if the subdirectory change is the real problem here.

Comment 3

[Jay Patel [:jay]]

i don't think we want to change the deki's domain.

if we are confident that the /doc redirects will work well and google will pick up the changes... let's do that.  but be ready to revert back if we run into issues.  

are people ok with that?

Comment 4

[Eric Shepherd [:sheppy]]

Yep, works for me.

Comment 6

[Austin King [:ozten]]

Bug#604706#c0 has some good input and we should reach out to Chris and the PromoteJS campaign once we've settled on final URLs and a release schedule.

Comment 7

[Chris Williams]

My concern of changing URLs again is you will waste all of the existing #promotejs effort, which is quite substantial. Since google gives more credence to this that are static and none to in page dynamic, we have no way of updating the links aside from asking everyone to update their badge. That will have a very bad effect on the campaign. Also the deep linking is working see http://arewefirstyet.com so altering it from the links should be avoided at all costs or at least done with understanding we are doing serious damage to the ranking. Yes google will pick the 301s, but it does downgrade the value of a link if it is to a redirected URL. Why can't the /doc be used as the root in order to maintain consistency?

Comment 8

[Austin King [:ozten]]

(In reply to comment #7)
I understand and agree however the constraints are:

1) We have 4 codebases
2) Dekiwiki used to live under /doc and did 302's to /
3) Django and Deki are broken in some locales, but not others
4) Long term Deki will be replaced with a Django based product, but in the meantime we have to resolve 3.

The best path forward (so far) is 
1) Move deki under /doc (where it used to live)
2) Find consistent position for locale which will work across all the sub-components natively or with ReWrite rules.

For high value PromoteJS urls we can put in ReWrite rules which would bypass Django and go to Deki. You have 12 keywords, can you give us the list of English URLs used in the badges.
Examples:
/en/JavaScript/Reference/Global_Objects/String
/en/JavaScript/Reference/Global_Objects/RegExp

Comment 9

[Jay Patel [:jay]]

Setting 0.9.1 milestone to see if we can get this setup soon.  It will be nice to have this implemented so we can monitor closely and make any necessary changes in 0.9.2.

Assiging to Austin for now.

Comment 10

[Austin King [:ozten]]

Renaming the summary.

We will use a solution which is not disruptive to production Deki urls.

Mindtouch Deki doesn't support hosting under /doc.

We'll take mod_wsgi off of / and use internal ReWrite rules for Django Apps. Forum will continue to be mapped to /forums and all other url handling will fall through to Deki.

Comment 11

[Jay Patel [:jay]]

ozten:  what's the status on this?  is this something we'll just have to tweak on the production web server config?

Comment 12

[Austin King [:ozten]]

(In reply to comment #11)
I've added the dependent bug(s). We'd like to get our staging setup like prod, so we can test the ReWrite rules there, before pushing to prod.

IT is working on an integrated staging env.

Comment 13

[Austin King [:ozten]]

We can test this on https://developer-stage9.mozilla.org/ which is our new integrated MDN environment.

Comment 14

[Austin King [:ozten]]

@retornam noticed the language widget is missing in the footer.

Comment 15

[Jay Patel [:jay]]

(In reply to comment #14)
> @retornam noticed the language widget is missing in the footer.

I don't think this is a bug... but rather an artifact of oremj using the live MDN site to setup the staging server.  NONE of the updates we currently have at http://mdn.staging.mozilla.com/en-US/ are on the new "integrated" staging server.

oremj:  is that something you can update quickly?  take an svn up from the current repo, not the production tag?

Comment 16

[Jeremy Orem [:oremj]]

So we just need to set up auto updating to finish out this bug?

Comment 17

[Austin King [:ozten]]

(In reply to comment #16)
No, we also need to fix the issues in Bug#608806

Comment 18

[Austin King [:ozten]]

This seems ready for WebQA.

Comment 19

[Austin King [:ozten]]

We'll have to punt, as we don't have enough time to QA. We can push out of cycle before 0.9.2 once we're  comfortable with it.

Comment 20

[Austin King [:ozten]]

Deploying now...
/docs is redirecting to /en-US/ instead of /en-US/docs
Same for /web, addons, etc

Comment 21

[Austin King [:ozten]]

And fixed...

Comment 22

[raymond [:retornam] (inactive)]

verified fixed