Editing an old revision loads the current revision:
Base: https://de.wikipedia.org/w/index.php?title=Wikipedia:Projektneuheiten&direction=prev&oldid=161800657
Editing an old revision loads the current revision:
Base: https://de.wikipedia.org/w/index.php?title=Wikipedia:Projektneuheiten&direction=prev&oldid=161800657
I cannot replicate. When I click "edit source" in that context I get the editor loaded on the page with the wikitext of the revision shown (161800657). Can you give more information?
I can reproduce today too. The header shows that the old revision is loaded, but at least the last section
4 Vorschau
4.1 Version 1.29.0-wmf.8 ..."
is not shown in 2017 Wikitext Editor. Could you pls look especially for this section?
Using the above links, I get a revision that is neither the requested nor the current revision: The first headline in the content shown in NWE is dated "19. Januar", while it is expected to start with "11. Januar", while the current revision starts with "9. Februar".
Very odd - the api call appears to be returning the content of the next revision which starts "19. Januar". In fact all the revisions for that article appear to be off by one, and I can't reproduce locally. Tagging services team as this appears to be nothing to do with the VE code.
I have just verified that this is the content served directly by Parsoid:
mobrovac@wtp2001:~$ curl localhost:8000/de.wikipedia.org/v3/page/html/Wikipedia:Projektneuheiten/161800657
yields content with 19. Januar. Adding the Parsing team.
What does direction=prev do? If you remove that, Parsoid renders exactly what's shown.
Interesting, so oldid=Xn along with direction=prev/next gives you id X(n-1) or X(n+1). Seems like a very strange API.
Change 344505 had a related patch set uploaded (by Jforrester):
[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget.init#activateTarget: Don't trust oldid, it lies
Change 344505 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] *ArticleTarget: Don't trust oldid in the query string, it lies
OK, this should now be fixed in master (and so will be fixed in production in a week's time, as long as nothing goes wrong). Sorry for the confusion!