Over a month ago we started playing with the idea of bringing MediaWiki pages into WordPress post. The logic being you can combine the presentation possibilities and RSS feed generation of WordPress with the ease of formatting, editing and collaborative sharing of MediaWiki. The term Bliki is one of the ways folks have been identifying such a hybrid, and I have been really interested in the possibilities (here is a brief overview of the idea from a presentation for the MAC Learning Environments web conference). Andy Rush found themes for both WordPress and MediaWiki that seamlessly tie the two together visually (read more here). Alan Levine found an authentication extension for MediaWiki that allows you to create the same login and password for both applications in one shot (read more here). The next step is pulling MediaWiki pages into blog posts, and we have been doing some preliminary trials here at UMW’s Division of Teaching and Learning Technologies. In particular, Patrick Gosetti Murray-John’s has coded the beginnings of what we are provisionally calling the GrabMediaWiki plugin (which is based on the name of a Typo3 plugin that does this very thing and inspired my thinking about it) which can be found here.
I have gotten an earlier version of this PHP code to work (see it here). I have included the exact code I used in that post below -you will need a plugin like EXEC-PHP for this to fly- with varying levels of success: it works well with WP 2.1 and MediaWiki 1.6.8 using the Monobook theme, but balks on the MistLook theme for MediaWiki. Also, it doesn’t seem to treat all MediaWiki installs equally. So, in short, we’re out of our league and we need your help! You can find a working basis of the code on Patrick’s blog and below, but this is a far cry from a seamless WordPress plugin that allows you to enter a MediaWiki URL in a field on the WordPress write post tab and whammo, integration! We are not expecting that outcome immediately by any means, just the possibility that folks who may have some programming chops, or know programmers with lamb chops, take a look at the code (or even a shot at the integration) and see what they might come up with (many eyeballs…). The future of educational technology rests squarely on your shoulders -are you geek enough to save the galaxy;)
<?php
//error_reporting(E_ERROR & ~ E_NOTICE); $curl = curl_init();
curl_setopt($curl, CURLOPT_URL, “http://bavatuesdays.com/bavawiki/index.php”);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
$page = curl_exec($curl); // sucks the mediawiki page in curl_close($curl);
$page = str_replace(’ ‘, ‘ ‘, $page); //kills the nbsp entitiy–make sure visual editor doesn’t clobber it’
$wppageDOM = domxml_open_mem($page); //puts the mwpage into a form for manipulation
$divs = $wppageDOM->get_elements_by_tagname(’div’);
foreach ($divs as $div) {
if ($div->get_attribute(’id’) == ‘column-content’) { //grab only the body of the mw page
$contentDiv = $div; }
if ($div->get_attribute(’id’) == ‘jump-to-nav’) { //kill navigation div
$parent = $div->parent_node();
$parent->remove_child($div);
}
$div->remove_attribute(’class’); //clear off classes to avoid style collisions. might need to do the same if style attributes are present
}
$h3s = $contentDiv->get_elements_by_tagname(’h3′);
foreach ($h3s as $h3) {
if ($h3->get_attribute(’id’) == ’siteSub’) { //kill the reference to original mw page
$parent = $h3->parent_node();
$parent->remove_child($h3);
}
}
echo $wppageDOM->dump_node($contentDiv); //spit it out!
?>
Loading ...
[wiki:MyGreatWikiPage]
or something… No curling or parsing required, the plugin would just go out to the configured wiki and suck in the appropriate page directly from the database.
it’d be harder to incorporate other distributed wikis (a wikipedia page, one from another mediawiki, etc…) and rules out non-mediawiki sources, but it’d be a much more integrated way to go…
I like the mashup idea of using divs or other elements to just suck out the content of a particular section of a page. that could be more flexible, but breaks if the markup changes (between versions, between servers/themes, etc…)
I was looking for a way to combine MediaWiki for viewing and searching with something like WordPress for input (or maybe some basic HTML/PHP form that creates MediaWiki pages automatically).
Would this work for that?
I think this is an excellent solution and would provide a perfect base for our experiment. We are gonna try and experiment with this and see if we can get it to work. On top of this, how might we stabilize this solution and then keep on pushing on the scraping tool. Great stuff, thanks for the sound advice.
@Andrew,
I think your idea here is great and similar to some of the stuff we have been imagining. Great a nice front end with a feed through the blog that several, though select, folks can edit through the MediaWiki.
Now we just have to figure out how to do it…
Or, if you just want to create the appearance of pulling content from one site into the next (ie, you didn’t need for mediawiki content to reside in the wordpress database) you could kludge this through embedding the content from one site into the other via an iframe —
Or, you could look into doing this within Drupal (and I know that suggesting that on this blog is akin to digital heresy, which is one of the reasons I make the suggestion — that, and the fact that it would be easier
)– there are several existing options that could be extended to support exactly this type of functionality.
Cheers,
Bill
I have to first say I like your style a lot. You are the Drupal equivalent to my WordPress fanaticism, and how can I do anything but respect that?
Also, thank you for your suggestions about working through this in WordPress, our restraint and generosity is duly noted.
OK, but more to the point. If this can be done easily in Drupal, which I often hear a lot of when it comes to old blue eyes, show me an example where the functionality described above is being used currently to some affect. I am not being at all facetious here. I think that a CMS that can pull in wiki pages and allow you to port content seamlessly from a MediaWiki (note that I did not say Drupal book which is by no means comparable) into a more structured CMS like Drupal is an important part of the evolution of these tools.
In fact, we have tested our code in Drupal -yeah, we sometimes use this unnecessarily laborious tool- and it does work to a degree but not without many of the same issues that WP has in terms of themes, MW versions, etc. If this can be accomplished quickly and easily in Drupal -I can think of about 15 uses for it right away. Not to mention the possibility of pushing for a university-wide open source CMS in the not too distant future. But, unfortunately, I don’t think Drupal is any closer to this integration than WP is right now, and whether it is easier or not remains to be seen. But the bigger question regarding these two competing tools is simplicity, finesse and power: WP has got it and Drupal yearns after it like the clumsy older brother.
Man, I haven’t had a rant like this since this morning, thanks for egging me on Bill, as you can tell it doesn’t take much. And, whether it is apparent or not, I really do enjoy the banter -there may even be a point in it somewhere -but no promises on this count.
i’m just sayin’, is all…
drupal rules! wordpress drools!
http://drupal.org/project/liquid
You just switched to WordPress, how can you be fanboying Drupal on the hallowed ground of the bava? Whose side are you on anayways
the only side I hallow is truth and righteousness… drupal has that covered, much of the time…
Like Mr. Norman, I also hail from the land of truth and righteousness, and I am fortunate that Drupal lives there as well. This makes my dogmatic, closeminded fanatacism far easier to justify
Now that that’s out of the way, if I had to do this today, I would try one of the following options:
1. As D’Arcy suggests, try the liquid module for a wiki within Drupal.
2. Try the wikitools module in conjunction with the recent changes module, the diff module, and the freelinking module - this combination gives a nice, lightweight wiki-esque functionality within Drupal. FWIW, this is the combination we use within DrupalEd, and the wiki syntax filters work in conjunction with the WYSIWYG text editor.
3. For moving content from Mediawiki to Drupal, I would install one of the four aggregation modules (aggregation, feedparser, leech, or simplefeed) and subscribe to the rss feed from either “new pages” or the “recent changes” Special Page within mediawiki — this would import the feeds into the Drupal site, where all the advantages of Drupal’s taxonomy, access control, views, etc could be leveraged.
If I had more time, I would clean up the use case: will Mediawiki and Drupal be installed on the same server, within the same domain, or in different domains? Will I need to pull content from multiple mediawiki instances into multiple drupal sites? Are there any access control concerns? Is SSO required, something nice to have, or not needed at all, or something that could be approximated via one username and password via LDAP (ie, not SSO, but still only having one username and pw)?
Once I had sorted out these questions, I would look at the options for SSO, or one username and password, looking most closely at either OpenID or the Drupal/Mediawiki AuthDrupal extension.
When it came to truly moving content between sites, I would look at leveraging Mediawiki’s xml import/export, and at the pre-existing points of connection within Drupal, the import/export api (which is a great start, but needs work) or the html2book module (a relatively new module, but written by a great dev). If neither of these methods worked, I would look to build a translation filter that parsed Mediawiki’s xml into a form that translated cleanly into Drupal.
If I only wanted to create the appearance of Mediawiki content appearing within Drupal, I would look at creating a CCK field that would take a url and then display that url within an iframe within the Drupal site — this approach would have the advantage of not only working with Mediawiki, but with literally any page anywhere on the web, thus allowing you to embed content in your site from anywhere, and comment on it as needed (think a lightweight trailfire).
Anyways — when it comes to the “right” solution, there isn’t any one clear path — it’s usually a murky road between available time, available resources, and the current state of the art within the organization. Both Wordpress and Drupal have a lot to offer.
Also, I hope that this is enough provocation to spark another rant.
Cheers,
Bill
You’re good, real good! And given how well the Drupalites have represented here I am going to play with this in more depth and sign up at DrupalEd to see how all this integration is working. Your generosity with thoughtful solutions in these comments is a wonderful example of sharing the precious resource of available time, and it is certainly not lost on me -though I may come off as a cad at time:)
I’m particularly interested in the third possibility you list:
Now the rss for MediaWiki is pretty weak, and not available on a specific page-by-page basis making a direct import of an article extremely difficult -if not impossible. This is at first a simple solution for aggregation, but it doesn’t incorporate the bliki logic of making these tools relatively seamless
Whereas this option sounds like it is moving in the direction of a vision similar to how I interpret the bliki:
Is parsing MediWiki’s xml a version specific challenge? It is this road I would be interested in and a close look at boht the import/export APIs for both Drupal and WordPress is a path I would not be able to really make sense of given my own own real and readily apparent limitations -yet suggests a road along which we might travel to make this happen.
In fact, I am not too concerned (just a little) with whether this is done in MediaWiki, Drupal, WordPress or some other tool, rather I would really like to see the promise of the bliki combination incorporate many of the elements that all of these applications have distinguished themselves by, namely:
WP: ease of use, multimedia possibilities galore, etc. (mega-rich open source community)
Drupal: Sophisticated user management, slick frontend/backend integration, etc. (rich ope source community)
MediaWiki: the amazing history, recent changes, and ongoing extension development for this product (richer than most other designated open source wiki applications)
Man, I’m getting weaker and weaker by the day, does this mean i am maturing or fatiguing?
Thanks again, Bill, for an amazing couple of comments (or were they posts playing comments on bavaTV?)
RE
This is definitely the way to go for an easy to maintain solution that sits comfortably between these applications — really, an xml translator that took mediawiki xml and translated it into a form acceptable for other applications — effectively a translation api that could probably leverage one of the many php-based filters that exist for various types of markup syntax —
So the main module (really, more of an api) would take the mediawiki xml and translate it to (roughly) title, body, metadata, and uri of the original source — the title would be the title of the page, the body would be html markup generated from the wiki syntax, the metadata would be any terms associated with the page for use with the taxonomy system of the receiving app, and the uri of the original source would be appended into the body to credit the original source.
Then, helper modules would take the data generated via the api and submit it to the respective platforms, perhaps via an xmlrpc call —
Applications could be added to the stack via additional helper modules; one for Drupal, one for Wordpress, on for Mambo, etc.
Using an api plus helper modules plus xmlrpc calls (or something else that’s standard-based) would reduce the amount of conflict between different versions of these applications.
Something like this would probably get the job done. But at this moment in time it’s some of the best vaporware around
RE signing up at DrupalEd — the test version of the site is actually running a dated copy — so to see the most recent version as of yet, you’ll need to download and install the tarball — That’s something I need to take care of as time permits –
Cheers,
Bill