Hi Benedikt,
Thanks for the link (I have been loosely following that thread).
I have in fact converted the Confluence data to ASF CMS mdtext files.
Everything is in the site/trunk/content directory:
* ipojo, obr, and site are copies from the current
felix.apache.org site (so the current site is currently
preserved but I would consider it static for now)
* The rest is converted Confluence content. This is up to
editing now.
In addition there is a site/tools folder which can be checked out to manually
generate the site if needed.
Finally, I have described how the CMS site currently works in the
site/trunk/content/documentatio.mdtext file. You can view this file in your
preferred editor or in an Markdown editor (such as Mou).
I think going forward we should now crosscheck the new pages against the old
pages. Once a page has been "finalized", the old page can be removed and we
would add a redirect to the .htdocs file in the root such that we have a
redirect for the old URLs to the new URLs.
Yet, currently I am still waiting for Infra to setup the CMS staging area such
that we have automatic builds of the site.
Regards
Felix
Am 18.12.2012 um 11:20 schrieb Benedikt Ritter:
> Hi Felix,
>
> commons is also in the process of migrating the website. They also have a
> main site and several sub project sites. Maybe the discussion on commons ML
> [1] can help you with the felix website.
>
> Regards,
> Benedikt
>
> [1] http://markmail.org/message/amw6yrsgaqj2btug
>
>
> 2012/12/13 Felix Meschberger <fmesc...@adobe.com>
>
>> Hi Marcel,
>>
>> Am 13.12.2012 um 15:36 schrieb Marcel Offermans:
>>
>>> Hey Felix,
>>>
>>> I did this a bit earlier in the year for the Apache ACE site, so I can
>> definitely help out a bit.
>>
>> Cool. Thanks.
>>
>> Actually, since the Sling site is very similar in setup to the Felix site,
>> I hope to be able to leverage the same tools that I used for the Sling site
>> also for the Felix site.
>>
>> After that any help is highly appreciated.
>>
>>>>
>>>> (1) We will get immediate site updates: Whenever we change one or more
>> pages and publish, the change will almost immediately be seen on the web.
>> There is no multi-hour delay and incertainty any longer
>>>
>>> Yes, this is a great advantage. Also, we can "stage" changes, and view
>> them on a special staging site before we publish them. All in all this is
>> one of the biggest advantages I've seen so far using the new approach.
>>
>> Yes.
>>
>>>>
>>>> When switching I think we should start with a double site: The new site
>> available directly through the URL at http://felix.apache.org and the old
>> site still available at http://felix.apache.org/site. This has nice
>> advantage, that links from the web still work and we can crosscheck the new
>> pages against the old ones easily. Over time we will remove the old pages
>> but add (static) redirects to still support the old URLs but redirected to
>> the new pages.
>>>
>>> So you propose that we make the new and old sites 100% identical as a
>> first step, and then replace the old site with a bunch of redirects, and
>> then start discussing potential changes and improvements to our site
>> (layout and content wise)?
>>
>> Yes, more or less: My idea is to have the old site still live while we
>> also have the new site. We can work on improving and fixing the new site
>> while at the same validating it against the old site.
>>
>> Regards
>> Felix
