Wordpress as a Wiki July 15, 2008
Posted by Andy Roberts in : wordpress, Wiki , trackback
Wordpress version 2.6 is now out on release and the video below shows some detail of the new revision control which gives authors some of the functionality of a Wiki on top of the most popular blogging platform.
From now on, a history of post versions is retained in the database together with the date stamp and author details, so that different versions can be compared and if necessary reverted. That’s one of the main essential features of a wiki taken care of. With self registration and a granular level of administrative privilege already built in, it should be possible to set up a Wordpress installation which is fairly open for public editing, just like a wiki. All that’s left to be added in order to give mediawiki a run for its money is a nice and simple way to link across between posts, by reviving the concept of CamelCase WikiText perhaps. Then there’s section editing, edit summaries and recent changes and the whole method of navigating from the post as published to the wysiwyg editor in the dashboard especially if this involves login along the way.
But the news is big because version 2.6 has just taken an enormous leap forward towards becoming something even more powerful. The idea of WordPress as a Wiki content management system is firmly on the agenda.
is an online professional who initiated DARnet 
A wiki without CamelCase is like a tube station without the tracks… the real power in a wiki is not the content but the connections between content…
Still, good news, thanks for keeping us posted.
This is one of the two big improvements in 2.6, in my opinion. Have you upgraded yet, Andy?
Do you encounter any plugin that doesn’t work?
They are big improvements aren’t they. I haven’t upgraded yet, I tend to wait for .n.1 also this trackback from Dennis Howlett:
http://www.accmanpro.com/2008/07/16/wordpress-26-much-to-like/
points to a bad experience by Chris Brogan
http://www.chrisbrogan.com/quick-note-wordpress-26-beware/
but that sounds like a one-off.
Thanks Andy for sharing this, interesting news and a great step forward I think
As someone who participates in both a group Wordpress blog and wikis, I think the idea that Wordpress could ever replace MediaWiki is completely laughable. The movement from the editing function and the public-facing version is far too slow (remember what wiki means?), and it doesn’t have anywhere near the kind of inter-page structure that most wikis need. That’s in addition to the lack of internal linking you already mentioned. Wordpress becoming more wiki-like is certainly a cool thing. But a replacement for wiki as we know it? Not happening.
Also, CamelCase is beyond outdated for three simple reasons: it’s confusing to the reader, you can’t disambiguate links ([[newname|name]]), and in a very large wiki page it is hard to pick out when editing. CamelCase works well in very small wikis that are meant for community organization and discussion, but not larger ones that need to produce a finished product.
Simple reasons are often wrong and laughable
1. CamelCase doesn’t have to confusing to the reader, they can, be automatically expanded so they look and feel like a normal link. What then becomes interesting is that CamelCase can become confusing for the author, in that it’s difficult to remember whether you want to link to ThatVeryCoolThingOfMine or MyVeryCoolThing.
In both the above cases, the tools can be made to support reading and writing (how about type-ahead on WikiWords?). MediaWiki, although being 2nd best wiki out there is still a bit shit on both scores.
2. You don’t necessarily need to disambiguate WikiWords and links, again, if the tools are good. For me, the only Wiki Syntax you should really need to know is CamelCase… and this should be optional, allowing the use of simple WYSIWYG alternatives where appropriate. Rmemember what wiki means? It means not having to refer to a WikiSyntax sheet for a language that’s become almost as complex as postscript.
3. Saying that CamelCase works better in smaller organisations is a. nonsense and b. unproven. In larger organisations there are always communities with a narrower interest. What CamelCase-ing does (when used) is force people to think of “the best title” for the page they are creating… which in turn is very useful when trying to create a wiki that mimics Design Pattern Language thinking (like Yahoo have done). Being forced to give a resource a meaningful, catchy and memorable name can be a good thing that helps the content being created get found later.
And as for your comment about speed. I made a tool that sync-ed a Desktop Gui Wiki tool called VoodooPad with Wordpress (via xmIrpc).. which meant I could write as fast as my gob is… without the speed hit of working with a web-based application. And that’s fast!
You’re right that Wordpress won’t replace MediaWiki. Hopefully something usable with replace both of them.
1. I find CamelCase to be confusing as a reader. It violates basic English grammar rules of capitalization, and subsequently looks unnatural. However confusing markup may be when in the edit window (to some), it looks just like normal writing from the other end. Linking systems should adapt to your writing, not vice-versa.
2. I groan whenever I hear people yammering about how WYSIWYG is the ideal for wikis. Your argument especially devolves for me in the context of Wordpress-as-wiki. HTML is just as (if not more) inscrutable than MediaWiki markup. I don’t use a reference sheet for wiki syntax, but even if I did, the fact that there’s a community supporting you in contributing to a MediaWiki site means you don’t have to know wiki markup to contribute. But if I want to build decent looking templates and tables (for example) that are properly flexible (WYSIWYG currently allows you make such things, but it’s not variable enough by a long shot), then I want the capability. WYSIWYG editing is playing to the lowest common denominator by pleasing newbies and luddites and cutting off advanced users at the knees. If you look at the actual data of who contributes the most good content to the successful wikis, it’s a core group of users (less than 1% of total editors, in the case of Wikimedia). If you want a wiki to be successful, enable them.
3. It’s not unproven. All of the biggest wikis in history use MediaWiki, while many of the (comparatively) smaller early ones use CamelCasing. For me, I guess it all comes down to the fact that you cannot escape the fact that all of the biggest and best wikis in history use MediaWiki. No organization forced users to tolerate it, and Wikipedia could easily have died if people rejected MediaWiki. But they didn’t. Saying MediaWiki is not the best option out there for creating a wiki belies the obvious truth in the numbers.
Addendum to my comment on WYSIWYG. WYSIWYG evangelism tends to get me fired up
What I’m really getting at is that WYSIWYG die-hards can’t seem to recognize that it’s not the best in every use case. I do really like it in some contexts, but not every wiki would benefit from adopting WYSIWYG.
1. CamelCase may violate grammar, but then don’t hotlinks violate punctuation. The “point” about CamelCase is that words, like CamelCase get automatically linked, something that never happens when all links are explicit.
2. You can use WikiSyntax if you like but that shouldn’t be the barrier to creation. Why should there just be one format? And WYSIWYG is far from being the “lowest common denominator”, they’ve just been very badly implemented at the moment.
One exception is Deki wiki which has made the best stab at a properly integrated WYSIWYG tool. And by the way it’s built on MediaWiki.
3. Just because the big wikis use it, it doesn’t make it right. How do you know there aren’t a billion passworded wikis that don’t. As I’m frequently told, size isn’t everything.
Addendum: Of course every wiki would benefit from adopting WYSIWYG, but I wouldn’t necessarily want it to be *forced* on the authors… unless it’d been a bad day
Well there are certainly many more individual wikis out there, and public facing ones too, that are making use of wysiwyg platforms such as wikispaces and pbwiki but mostly these are not very collaboratve efforts, being examples of NowEveryoneCanHaveTheirOwnWiki
Within the firewall I have some sympathy with the idea that the crucial early adopter advanced users can get cut off at the knees by poor implementations of WYSIWYG which produce unfathomable html code at the edit source level, rather than convert back into WikiText. So the proposal to provide a choice of editor is often in reality a one way migration.
Back to WordPress, if programs such as Dreamweaver can provide good switching between html and wysiwyg views without messing up the code too much then why not blog authoring and wiki editing tools?
Excellent feature. I love all the speculation about the bigger context — it’s exciting stuff. But for me, for now I’m just gonna be happy that some kind of version control is working its way into Wordpress.
[…] feature, which is rather wiki-like. This kicked off a discussion about using wordpress as a wiki , whether it can be regarded as a wiki, and whether you want to use it that way. Without actually […]
[…] although images can now have captions, which is pretty cool. From a writing place though, among the new features of Worpress 2.6 is the ability to track revisions to a document, much the way a wiki works. As a wiki and […]