Same here, from Japan. I can see beta.developer.mozilla.org but wiki.develper.mozilla.org doesn’t load on browser and end up with timeout.
host command ( for DNS query) showed me beta.developer.mozilla.org resolved to d1avawhiqh9uo1.cloudfront.net, and wiki.developer.mozilla.org to somewhere on .us-west-2.elb.amazonaws.com.
Technical question regarding the UX for authors:
Is it possible to serve both pages under the same domain and distinguish which one to show based on whether the user is logged in or not?
That would avoid any UX issues resulting from serving them from different domains, e.g. having to click twice to start editing an article or access the article’s history.
I guess that should be possible by checking the session cookie in a rewrite condition and serve from the different vhost based on that. (Stack Overflow answer regarding how this can be done in Apache.)
And sorry for coming up with that question about basic functionality so late in the process!
Sebastian
Disclaimer: I’m not involved in the site development, but I can answer this question anyway.
Is it possible to serve both pages under the same domain
You could try to do that, but things would get ugly pretty fast. The issue is, only the logged-out reading UI is updated right now (the logged-in contributor UI is staying the same for the foreseeable future). So it would not be a temporary inconvenience, but rather constant maintenance headache. The problem is, they use entirely different frameworks (jQuery vs React) so to serve both from the same domain, one would have to make sure to clear the browser cache based on logged-in/logged-out state. Probably, disabling cache altogether is not an option. That seems cumbersome and error-prone and likely not worth the hassle.
That would avoid … e.g. having to click twice to start editing an article or access the article’s history.
I think this is easier to solve by adding a simple check to the redesigned reader mode: on page load check whether the user has a logged-in cookie and if so, redirect to the old editor website.
(Stack Overflow answer regarding how this can be done in Apache.)
I think they use meinheld because the redesign site sends response header
server: meinheld/0.6.1
1 Like
Don’t use the URL. Use the domain:
▶ traceroute -d beta.developer.mozilla.org
traceroute: Warning: beta.developer.mozilla.org has multiple addresses; using 99.84.216.63
traceroute to d1avawhiqh9uo1.cloudfront.net (99.84.216.63), 64 hops max, 52 byte packets
1 192.168.1.254 (192.168.1.254) 0.414 ms 0.149 ms 0.143 ms
2 75-40-88-1.lightspeed.chtnsc.sbcglobal.net (75.40.88.1) 1.440 ms 0.992 ms 1.310 ms
3 99.94.0.114 (99.94.0.114) 1.620 ms 1.421 ms 1.592 ms
^C
▶ ping beta.developer.mozilla.org
PING d1avawhiqh9uo1.cloudfront.net (99.84.216.63): 56 data bytes
64 bytes from 99.84.216.63: icmp_seq=0 ttl=240 time=25.759 msI think it could be possible. Mind you, we’re using AWS CloudFront but I supposed it would technically be possible to have dynamically redirects based on cookies. But it all feels pretty fragile. Probably best to keep it explicit and simple.
A possible bad side-effect is if you’re in the wiki to editing (“wearing the wiki hat”) but then you open the read-only site in another tab to see it “as non-editors would see it”. If that’s the case, it would keep redirecting you back to the wiki site.
1 Like
I can’t reproduce this. Do you maybe have a link to a page where you are seeing this?
Hey Takeshi, would you mind trying it again? We made some changes we think should fix this.
Hi Kadir,
Now Firefox loads both pages and I can see beta.developer.mozilla.org and wiki.developer.mozilla.org .
I can login to wiki.developer.mozilla.org while I can’t login to beta.developer.mozilla.org from the link placed upper right corner of top page: https://beta.developer.mozilla.org/users/github/login/?next=/ja/ .
BTW, is the login link necessary on beta.developer.mozilla.org? Beta is for viewing.
Thanks for the quick feedback Takeshi! Can you tell me what happens when you click the login button on beta.developer.mozilla.org?
Login is not necessary to view the beta page. We will offer additional features for logged in users later though.
After I click login link on the beta site, https://beta.developer.mozilla.org/ja/ , browser seems to be loading some page, but 2 or 3 seconds later it eventually comes to same page.
The URL Transition took by Network Monitor is as following image:
I expect that whoever made the top navbar in https://beta.developer.mozilla.org was probably some junior software engineer, because it’s definitely not the quality I would expect for a site aimed at providing frontend guides and resources. I mean that search input is just terrible, and that login link and those dropdowns. I’d expect the quality to be nothing short of exemplary.
How will these benefits be felt?
What tangible aspects of this conversion are aimed at users explicitly?
1 Like
I don’t get it either.
Why do you make a new front-end to a totally fine site?
1 Like
In the past, logging in to MDN meant that all further requests would bypass the CDN for documents. That’s not necessarily so bad for people living close to our servers in Portland, but would be a severe degradation of performance for people living further away. With this change, we can offer features that will require users to login without degrading their user experience.
One example of such a feature is a browser compatibility banner on top of the page that shows you compat info for the browsers you have to support. In the past, we wouldn’t have been able to cache those pages, since they’d be specific to each logged-in user, even though only a small part of the page is customized. With the new front end, we can have the documents on the CDN – same for everyone – and insert the features that are unique to any given user.
1 Like
as a heavy user of mdn, thats nothing i would ever request, desire, or think of.
how many requests for that did you all receive?
in doing so you’ve upped the barriers of entry for new users.
the difference in trade-offs seems incredibly contrary to mozilla’s mission.
Hmm, I don’t think I understand what the upped barrier is referring to. Would you mind expanding on that?
1 Like
using react is not as easy as editing plain web platform documents.
moreover, check out these screenshots of users who you claim to be supporting, not liking this at all
The page transition changes, if I once remove cookie and site data from github.com in browser setting.
After I click Login link on the right upper corner, I’m taken to github authentication page, then I seems to be passed 2FA, I’m taken back to the same page on beta.developer.mozilla.org, with not logged in state.
Again, I might be misunderstanding you here, but MDN editors are not expected to write react code, it’s the same wiki as always for editors. People who contribute to the MDN frontend code – Kuma – will write react code, but they are also the ones who requested the change.
Regarding the examples, I’m glad you’re bringing them up. Currently, we can’t ask people to log-in and tell us about their preferred language. Once people log in, they will get a slower version of the website, after this change, we can address that.
The specific issue here is that people go to Google, which will serve the localized version first (with the /nl/ locale in the URL for the dutch version for people who google in the Netherlands). Since they have requested that URL specifically we serve that localized version to people regardless of their own accept language.
1 Like
Update:
Firefox 69.0.3 make it, while Firefox 60.9.0esr doesn’t with a fresh profile. I mean the login to beta site.
And I’m on Debian/GNU Linux, just FYI.