Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
WlugWikiConversion
Edit
PageHistory
Diff
Info
LikePages
After the [June Commitee Meeting|CommitteeMeetingTopics.2005-06-20] the committee has decided not to pursue the MediaWiki option further at this time. Instead our efforts are focussed on investigating two possible paths for migrating to the latest version of PhpWiki and will be actively looking to work with the PhpWiki maintainers to try and merge our local changes with their current HEAD. We have a list of WlugWikiCustomisations that need to be considered in the migration. The remainder of this page remains for historical reference. Or if you're AristotlePagaltzis, you might consider it to be hysterical reference. ---- Currently we're considering moving the WLUG wiki from PhpWiki (or WlugWiki, as we are really running a fork of PhpWiki by now) to MediaWiki. This isn't about pros or cons of either piece of software! !! Conversion of Wiki Content I'm currently working on a script that was originally written by Isaac Wilcox. This does a reasonable first pass on converting the wiki markup, however there's a lot of things it doesn't do yet, mostly involving any old-style wiki markup, which is rife throughout the WLUG wiki. Maybe I need to stress this some more. __The script I have does not convert the content perfectly. It does not do most old-markup constructs at all, unless they happen to also be new-markup constructs. There are many new-markup constructs it does not understand. It is NOT finished. It is a LONG way from being finished. From the time I've spent on it so far, I would say that there is at LEAST as much time to be spent on it to get it to the point where we can bother trying to hand-fix the output, as there is in fixing/modifying the current wiki software.__ Also, having migrated the content, every page will need to be visited, and checked for validity, and resaved. This is very important! A lot of the 'special' pages within Mediawiki __only__ get updated when a page gets saved. The Backlinks and Category equivalents are obvious examples. We can let this happen "as the wiki gets used", but the fact is for the new site to work properly we will *have* to do this. We could, I suppose, write something which simulates editing then saving a page, which will address the automagic pages, but won't confirm the markup was translated completely. I'm aware that if we aim for 100% conversion we'll probably fail, but what we're probably looking at is approximately 80% of the wiki markup being converted at the moment, and still a requirement to walk across pretty well all of the 7000 odd pages in the wiki. !! Plugins There's a bunch of plugins we've written - WlugMember being one of them - that will have to be rewritten. This probably isn't such an onerous chore, as most of the plugins we've written are pretty simple, however it's something that must be taken into account. !! Extensions We've also added a lot of extensions, such as the spam limiting and google query banner. These will need to be reimplemented. I think MediaWiki has a much nicer framework for adding these at least - it probably won't involve hacking the theme directly like it did in phpwiki, but this needs to be taken into account. Media wiki uses the term "extensions" for what phpwiki calls "plugins", the two are one and the same. MediaWiki has a lot more "layout" extensions than phpwiki did. -- PerryLorier. !! Current things that rely on the wiki * meeting reminder bot (parses wiki page content) * library (relies on the wiki style sheet) * WantedWikis generation * modify/remove GreenStone full-text index of wiki * pci database (better integration) * committee fortnightly reminder bot (parses wiki page content) !! Problems with the current wiki that we hope to address * No (easy) security updates, as we are a fork of PhpWiki * No ability to fix font problems across platforms due to PhpWiki nesting tags ** I think we can do this with our current software, we just need to spend some time tweaking the theme. -- JohnMcPherson * No ability to do any kind of layout inside pages, eg. text to the right of an image, a floating text box in a page (to move Coming Up from the sidebar to the main page) ---- One big issue is that Mediawiki markup sucks rocks. It doesn't have any concept of blocks; it would be like converting the wiki back to old markup. I don't know how well Mediawiki is designed internally, but the markup used is a very big deal, and Mediawiki rides the short bus as far as that is concerned. Personally, I'd suggest taking a look at [MoinMoin | http://moinmoin.wikiwikiweb.de/FrontPage] instead. Check out the [GNOME Live!|http://live.gnome.org] for an example of a decently busy and relatively large wiki running ~MoinMoin. The ~MoinMoin formatter doesn't seem to understand blocks either, but at least it uses indentation and remembers context across linebreaks in enough cases that it can be considered sane enough. And the wiki engine comes with a few neato features. Also, it's [Python], which will please PerryLorier :) and is better than [PHP] anyway. --AristotlePagaltzis ---- Not having any experience with either MediaWiki or MoinMoin I'd have to say that based on a comparison of features listed on their respective webpages I would favour MoinMoin. It looks easily themeable :) -- MattBrown ---- According to the comparisons, moinmoin doesn't have version control. That seems like a pretty glaring ommision in a wiki. -- ~PhuqmAll ----
No page links to
WlugWikiConversion
.
