On Tue, Jun 26, 2018 at 3:40 PM, Julian Foad <julianfoad_at_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 dev_at_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
Received on 2018-06-27 10:11:44 CEST