WordPress as a Wiki

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.

This entry was posted in Wiki, wordpress. Bookmark the permalink.

19 Responses to WordPress as a Wiki

  1. Tom Smith says:

    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.

  2. Hendry Lee says:

    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?

  3. Wayne Brewin says:

    Thanks Andy for sharing this, interesting news and a great step forward I think

  4. 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.

    • Tom Smith says:

      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.

  5. 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.

  6. 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.

  7. Tom Smith says:

    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 🙂

    • Andy Roberts says:

      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?

  8. Pete Forsyth says:

    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.

  9. Pingback: Harry Wood Blog / Wiki Wednesdays - Back in 2008

  10. Pingback: DrunkenDumbshow.com » Blog Archive » A number of updates

  11. Leon Paternoster says:

    I was just thinking about this. The membership org I work for wants to set up a ‘knowledge bank’: the people contributing to it will have varying degrees of technical competence, so a WYSIWYG editor is essential.

    We’ll have 400 or so of our own articles and documents to load up and then our members will be able to add their own. Very few will have experience of contributing to wikis, but they’ll have searched wikipedia.

    I’ve been experimenting with wiki software (docuwiki and pmwiki mainly) and, although they’re easy to set up and extend, I’m finding the whole concept of a wiki a bit of a pain. I mean, what is the issue with having a simple ‘Add an article’ button/link in the nav area? I think wikis are excellent for people who know how to write wikis, but rather daunting for the unititated.

    Using WP will enable users to add articles easily, exercise a simple version control and take advantage of tags and categories. I can rename the ‘Excerpt’ field ‘Abstract’ and display articles in lots of useful ways (most recent/random/most commented on/by category/by tag). Incorporate a Google search (WP’s search is truly dire) and I reckon you have a usable product.

    Apologies for waffling: just thinking out loud.

  12. Tom Smith says:

    I’ve been thinking about this too. And yes, having an “add new article” button is essential bit of usability because it is the first thing your users will be looking for (after the edit button).

    And so, because current wiki tools don’t “do it” for me I’ve written my own, a wiki that pays lots of attention to….

    * Connections between objects (and shows them, automatically building useful navigation)
    * The relevance of tags ( why have “delicioustags” and “WikiWords” and not have them connect in the knowledge base
    * The wider world, my wiki currently looks at the wiki word and also show news about that subject … it’s a “live” search… because the world keeps on turning

    For me, building a knowledge base and focussing on the assets rather than the connections between the assets is daft. Most wikis don’t do it and WordPress doesn’t really either.

    But the very main things is that my wiki has to look nice and be SUPER simple to use… without this you’ve lost your knowledge creators before you start.


    • Leon Paternoster says:

      my wiki has to look nice and be SUPER simple to use

      Sounds good. Is there a link?

  13. Tom Smith says:

    Should be live this week, but there isn’t much to see, it’s “just another web site”… but that’s kinda the point.

  14. monica says:

    Andy, I’m really glad you have shared this information. Unfortunately visiting your blog for the first time. But I’m impressed with your knowledge on wiki. I’m doing a course on distributed systems and like most of your post. Thanks Monica

  15. Links says:

    Hey thanks for sharing this post im looking to start a wordpress wiki site this has help me alot thanks.

Comments are closed.