The problem doesnt seem to be exactly new, but apparently not as common as one might think either: You want to migrate your MediaWiki wiki pages into a (existing) Trac installation.
The following is the indirect path to the solution with explanations on how things work. for the direct solution go to section Direct Solution.
Indirect Solution
The TracHelpPage says regarding this issue:
You can use the attachment:wiki:TracWiki:mediawiki2trac.py Download script as a starting point. WikiProcessor for the MediaWiki styles has been started as trac plugin on http://trac-hacks.org/wiki/MediaWikiPluginMacro.
You are supposed to download the mentioned mediawiki2trac.py from the above link, copy it into a directory on your (web)server and execute it with e.g.:
python /PATH/mw2tw.py > mwexport-mediawiki2trac.sql
Unfortunately the script does only some minor importing without regard to versions, attachments (i.e. associated files) and redirects etc.
A bit more interesting is the following Trac ticket: http://trac.edgewall.org/ticket/5241 especially regarding the different handling of attachment/media-files in MediaWiki and TracWiki. MediaWiki handles attached files in a completely different way than Trac does:
In Trac, you have attached files that are associated with a given page. Whereas in MediaWiki you have files that are uploaded and it’s up to the wiki-editors to create links to the uploaded documents.
So, the process for dealing with “attachments” depends on a couple of factors.
If you want your downloaded documents to be unique in Trac like they are in mediawiki, then that’s a problem. AFAIK, uniqueness in mediawiki is based on the filename whereas in Trac it’s a combination of filename and what Wiki page the attachment is associated with.
So if you have an attachment that is linked in multiple places from on your MediaWiki page, then to have the same effect you’d either have to set up an independent web for these attachments (so all things would link to the same file) or you need to give up on the notion that the file is unique and that you have attachments that represent copies of the file in question.
So – whats wrong here:
- First we don’t want redirect pages to create stub-pages in Trac with no redirect functionality.
- Secondly existing media-references should be kept intact.
As I am not really proficient with Python I reimplemented the migration script with PHP:
Features
- Import directly from the MediaWiki MySql database into the Trac Sqlite3 database file
- Convert basic MediaWiki markup to Trac markup (so no separate MediaWiki parser for trac is needed)
- Optionally remove category entries from wiki pages
- Preserving Image/Media links. This assumes you manually copy the old mediawiki attachment files into a new flattened out directory (without the hashed subdirectories)
- Optionally migrate revision comments
- Optionally keep redirect-links intact. Even though Trac doesn’t know redirects as MediaWiki does the script will change links to redirect pages so the link directly points to the real page
- Optionally discard Stub pages
- Optionally discard pages with fewer than X bytes
- Remove custom specified substrings from pages (e.g. old MediaWiki templates)
- Replace custom specified substrings with replacement-strings (e.g. custom copyright notices)
Limitations
There are some limitations though:
- Complex markup (e.g. tables) will not be converted
- As the script directly accesses the Trac Sqlite3 database file the corresponding Sqlite3 extension needs to be enabled in PHP
- I personally didnt need this feature, so the script discards old revisions – if you take a look at the old python version of this script it shouldnt be hard to implement this though
Direct Solution
- Backup your trac database file – seriously – do it!
- Download and unzip the following script into a web-accessible directory on your webserver: mediawiki2trac.zip
- Edit the settings section at the start of the script – comments should hopefully be self-explanatory.
- Call mediawiki2trac.phpin a web browser.
- You need Sqlite3 support in PHP for the script to work. If you get an error message like Fatal error: Class ‘SQLite3′ not found in…. you are missing the extension. See for example http://ubuntuforums.org/showthread.php?t=891767 on how to install this on Ubuntu.
- When calling the script it first starts in test-mode showing you what replacements etc would be done. Activate live processing by clicking on the given link.
