On Tue, Jun 26, 2018 at 3:40 PM, Julian Foad <julianf...@apache.org> wrote: > Johan Corveleyn wrote on 2018-06-25: >> > Johan: what is the recipe/regex for converting PAGE[#FRAGMENT]? The PAGE >> > part seems to be unchanged, at least in simple cases. >> >> Yes indeed, the PAGE part is unchanged. However, since pages can (and >> will) be renamed [...] we should redirect the old pages to the "Tiny link" of >> the new pages (which are in fact stable [1]). > > Perhaps. The general solution I would recommend for all migrations is to put > the simplest possible logic at the old (retired) location and implement > everything else at the new location. In this case, that could be a redirect > from the entire old base URL to the new base URL, keeping the rest of the URL > unchanged. > > Maintaining redirects from the old to the new names of renamed pages should > be the responsibility of the new location, in an ideal world. Because it is > not an issue unique to the migration, it exists for everyone linking to > Confluence. Relying on the "tiny links" isn't really a solution, because it's > unrealistic to assume everyone will always use them. (I don't often use them, > myself.) Confluence, and every web content management system, should (in my > opinion) provides a facility for redirecting old URLs to new ones. I haven't > checked whether Confluence does. > > To me, that strengthens the case for making only a very simple redirect of > the base URL at the old location.
Okay, good point. However, when I now go to https://cwiki.apache.org/confluence/display/SVN/FrontPage (which you renamed to "Apache Subversion Wiki") I get a 404. Though the body of the page contains the suggestion "The page you were looking for may have been renamed to the following: Apache Subversion Wiki". Perhaps that behaviour can be adjusted in Confluence to perform an automatic redirect. So if we're going to redirect pages based on their name, I think you can indeed redirect https://wiki.apache.org/subversion/PAGE to https://cwiki.apache.org/confluence/display/SVN/PAGE (perhaps double-check that this works correctly for names that contain spaces, but I think it does) Subpages need to be special cased though: PAGE/SUB becomes PAGE+SUB (or "PAGE SUB", i.e. the slash becomes a space). For example: https://wiki.apache.org/subversion/FS2/Design to https://cwiki.apache.org/confluence/display/SVN/FS2+Design >> > How/where do we configure a redirect from the wiki.a.o subdomain? Ask >> > infra? >> >> I don't think we can automate / script this, because of the need to >> use those "tiny links" as target. We're only talking about ~100 pages, >> so my idea was to just do this manually: edit each page and change the >> content into "#REDIRECT <newurl>". That would even maintain the >> original history in the MoinMoin wiki (until it gets deleted someday). > > >> As for the #FRAGMENT: that's more difficult. [...] > > I assumed the migration tool already implemented the required conversion, as > I assumed it already converted intra-wiki links. But if not, or if it's too > difficult to extract, ... Hm, yes that logic is inside the migration tool somewhere (at least it's used when generating the "section anchors" and generating the intra-page links of the TOC). But I have not looked into that in detail. I'll try to take a look at the source code that does it to see if some regex can be "extracted" when I find the time. Or if you want to take a look yourself, see: https://github.com/AtlassianContribs/universal-wiki-converter >> [...] Unless someone has a really good idea on how to solve this in an >> elegant way, I would just ignore supporting the "old fragments" in old >> links. We'll redirect the user to the correct page, but we can't guide >> him to the correct section ... too bad. > > ... then I agree with that: just forget about fragments. > >> > I see we already have some redirects from subversion.a.o/... configured in >> > site/publish/.htaccess; I have just updated this one: >> > >> > - Redirect /wiki http://wiki.apache.org/subversion >> > + Redirect /wiki https://cwiki.apache.org/confluence/display/SVN >> >> Great. >> >> > So far we're just talking about simple redirects. It would be a whole step >> > better if we could publish the new Wiki's pages as an overlay onto >> > Subversion's own top-level URL namespace: >> > >> > https://subversion.apache.org/<PAGE> >> > >> > From a site design or information design perspective that presents a much >> > better joined-up site, and changing the back-end from MoinMoin to >> > Confluence or to/from plain HTML wouldn't force us to change the URLs in >> > our web pages and source code and docs. Also, much of our web-page >> > material would be easier to maintain using the wiki's editor than as raw >> > HTML. >> > >> > Any idea where to start with that? >> >> I'm not sure if that's a good idea. Making the wiki pages available >> through url's that are part of our top-level namespace, yes, perhaps. >> But putting the entire website in the wiki? Feels a bit weird to me, > > I didn't mean our entire web site, I meant the Wiki pages and "plain" web > pages should share the same URL space so we can choose on a page-by-page > basis which tool to create the page with. > > For example, yesterday I was editing the "/roadmap.html" page in Vim and > thinking this would be much easier if it was a Wiki page, not only for > WYSIWYG editing but largely because it would help me create and maintain all > the intra-wiki and wiki-to-Jira links to other pages. Ah yes. +1. >> except perhaps for some specific pages (like the faq) ... though I'm >> not a website designer, so I may be wrong. Can't really put my finger >> on it, but I believe for the webpages themselves you might need more >> flexibility than what you get inside the wiki. > > For some, certainly; for many, not. Ack. >> Maybe those ideas should be bounced off of some infra people, or >> people in other ASF communities. > > I have been wondering where best to find ASF people interested in organizing > project web sites and tools for project communication. There is much more I > would be interested in discussing -- not least the evolution and better > integration of mailing lists, mail archives, IRC, and IRC archives. > > Maybe I will try d...@community.apache.org . Yes, that might be the right venue. Though I tried a couple of months ago to get some tips / guidelines on website design and style, but didn't get much response (i.e. there were no foundation-wide resources for that): https://lists.apache.org/thread.html/80793924f3cc1f0e9b2923858cb4cc9175e4d6cca30e9320b929fbc2@%3Cdev.community.apache.org%3E Maybe that just means there is room for improvement here, to get some ball rolling for gathering ideas / efforts across the ASF. -- Johan
