http://simile.mit.edu/timeline/

Nuff said. I might have to hack together a plugin, but throw it on the pile of things to do.

wow, what an interesting combination, but one brought about by necessity.

Windows – To get under the radar of the villanous IT department at work
Mediawiki – The best all round wiki software IMHO
XAMPP – Saves a lot of time doing configuration, has SSL support (which we’ll need)
LDAP – To authenticate against Active Directory. The whole Single Sign-On thing. If you’ve got a user database, why create a whole new one in your wiki and force your users to remember multiple passwords?

OK, setup windows and get it onto your domain. Setup XAMPP and Mediawiki. I installed XAMPP directly to c:\xampp, and moved the default contents of c:\xampp\htdocs into c:\xampp\htdocs\xampp_default. Then I installed Mediawiki into c:\xampp\htdocs. At this point you should have a working wiki, and you may like to apply a rewrite rule to make your wiki links look tidier.

Now go and grab the latest version of the LDAP Authentication plugin and pop it into c:\xampp\htdocs\includes

Now here’s the important part. The PHP manual is vague regarding setting up LDAP capability on Windows based systems, saying simply:

Note to Win32 Users: In order to enable this module on a Windows environment, you must copy several files from the DLL folder of the PHP/Win32 binary package to the SYSTEM folder of your windows machine. (Ex: C:\WINNT\SYSTEM32, or C:\WINDOWS\SYSTEM). For PHP < = 4.2.0 copy libsasl.dll, for PHP >= 4.3.0 copy libeay32.dll and ssleay32.dll to your SYSTEM folder.

So go ahead and grab libeay32.dll and ssleay32.dll and throw them into your c:\windows\system folder, and throw some copies into c:\windows\system32 for good measure. Why not? If we’re going to get our OS messy, let’s go all the way.

There is a bunch of disjointed information in the the LDAP plugin’s discussion page, so here’s the important stuff

:You must look at your php.ini. There are an entry like ”;extension=php_ldap.dll”. Search on your system for the php_ldap.dll copying the file in the /windows root/system32/ and remove the ;. SO that in php.ini the line shows like ”extension=php_ldap.dll”.

So hell, go ahead and do that too. I’m personally not sure that you should be or have to copy these .dll’s to your system/system32 directories – because php.ini declares an extension folder to reference, and the .dll’s reside there by default. However it can’t hurt to copy these .dll’s into your sysdir.

Now, the tricky part is modifying php.ini. php.ini resides in a few locations in a XAMPP install, and you’d be inclined to modify the one in c:\xampp\php however here’s where I was struggling. I couldn’t figure out why, after all my work, LDAP still wasnt showing up in phpinfo.php (more on that… right now)

Create yourself a file named phpinfo.php with the following code in it:

< ?php
phpinfo();
?>

and place it somewhere within htdocs. So as to avoid Mediawiki jumping in ( http://yourwikiaddress/wiki/phpinfo.php = a wiki page not found ) I popped it into c:\xampp\htdocs\xampp_default and fired it up ( http://yourwikiaddress/xampp_default/phpinfo.php )

You can see that the php.ini file being referenced is not c:\xampp\php\php.ini but indeed it is c:\xampp\apache\bin\php.ini and so that is the one you should be modifying. Modify it and restart Apache, and run phpinfo.php again. Do a find for LDAP and you should get something like this:

Do a search for SSL while you’re at it to ensure that SSL is going. By default AD does not allow anonymous searches etc so you’ll probably have to setup some trust via SSL.

Then, finally, follow the instructions given by Eric Santiago here and here
and you should be up and running.

It’s actually all easier done than said. But for reference, here’s the relevant part of my LocalSettings.php:

$wgDiff3 = “”;

# Restrict edit to logged in users only
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;
# Define that all pages can be read when not logged in
$wgGroupPermissions['*']['read'] = true;

# Prevent new registrations as we auth against AD as below
$wgGroupPermissions['*']['createaccount'] = false;

# Authenticate against Active Directory
require_once( ‘LdapAuthentication.php’ );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( “DOMAIN-NAME” );
$wgLDAPServerNames = array( “DOMAIN-NAME”=>”wgtn-ad-serv.dns.tld akl-ad-serv.dns.tld” );
$wgLDAPUseSSL = false; # It works, but I have a ldap.conf file
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = true;
$wgMinimalPasswordLength = 1;
$wgLDAPSearchStrings = array( “DOMAIN-NAME”=>”DOMAIN-NAME\\USER-NAME” );

# When you make changes to this configuration file, this will make
# sure that cached pages are cleared.
$configdate = gmdate( ‘YmdHis’, @filemtime( __FILE__ ) );
$wgCacheEpoch = max( $wgCacheEpoch, $configdate );

?>

We’ll get around to the SSL functionality when I figure out how to do it for a Windows based server. In the meantime, you can check out some more customisation/installation instructions here:
http://software.newsforge.com/software/06/05/12/1539231.shtml?tid=74&tid=13

So I was Digging during idle time at work, and came across Unobtrusive Sidenotes

I have to say, I’m damn impressed, and can see a place for this paired up with a wiki. Some of you, especially when reading my larger posts, may note that I tend to use a lot of bracketed dialogue to expand on a point (you know, like this, because if I lay it all out with backhistory, the amount of questions tends to be lower. Possibly because the reader has a fuller picture.) Unobtrusive Sidenotes is perfect for my style of writing (which, by the way, according to an online tool that was once featured here – I write to the level of Reader’s Digest which is hardly remarkable; I have been reading RD since I was a toddler)

Heh, see what I mean? Me and my brackets

Anyway, back to the application of sidenotes to a wiki. I’m not too sure how well it would work in say, a wikipedia type of wiki usage, but for a technical wiki, sidenotes, I think, would be valuable for imprinting for example tips and tricks relevant to the content. Of course the killer is the ability to show/hide the sidenotes. Don’t want to see them for printing? No problem. Reading some content and you’re not too sure about a point, show the sidenotes to get some more context…

The only difference I would make would be to indicate sidenoted words when sidenotes are hidden, maybe using the X(HT)ML style dotted underlining.

It’s important, I think, for the Open Source community to recognise that there needs to be a collation of tools to make that one killer app – straying away from the “do one thing and do it well” mentality, sure, but that’s where things seem to be headed. Mediawiki + Unobtrusive Sidenotes + a good WYSIWYG editor + some way to integrate with OpenOffice/KOffice + an email interface for email-to/from-wiki + good RSS Feeds + LDAP/AD Authentication + iCalendar (or some wikiable calendar) + exporting to PDF + whatever else as one package will provide some really stiff competition to Sharepoint, which is only improving in integration with Office with the upcoming 2007 release. You could probably use a bit of AJAX to do a number of the extras. Something like Confluence.
Without of course taking Mediawiki too far down the same path as Sharepoint – it’s important that at its core, Mediawiki remains a wiki and not a bastardised spawn-of-wiki-CMS.

Just to expand on my last ramble on this topic… I was lying on the floor here at work (as you do) and began to think about what challenges faced the integration of mediawiki into a sharepoint solution (what? You dont happen to think constructive thoughts when you’re lying on the floor at work at 5 in the morning?)

* Corporate politics “we paid for MS/MS have their hands down our pants/we read that open sauce is insecure/it’s not shiny enough” ad infinitum and…
* …The very similar PHBS (Pointy Haired Boss’ Stupidity)
* Unneccessary overlap (ie having two seperate database systems, if mediawiki could magically become MS-SQL compatible…)
* Not yet foolproof – Jo(e) Office Worker wont be interested in learning wiki syntax for the greater good of collaborative documentation. Mediawiki has come along a bit as of late in this regard, with preliminary work on integrating FCKEditor and talk of using an intermediatary XML format. If you dont tell management the name of the WYSIWYG editor (I read it as FUCKEditor… if only such a thing existed outside my mind ) it should be a great development for aiding the proliferation of wiki tech. Making wiki more like MS Office will make it that much more accessible
* More overlap – Sharepoint search for the Sharepoint section of the corporate site, and wiki search for the wiki section of the corporate site. There needs to be a way to tie the two together, even something simple like passing keywords from one to the other.
* While we’re on the topic of searching, the wiki search needs the option to have a checkbox titled “Search this Category only”
* More manglement. Try convincing them that open editing to all is a good idea. I had to impliment a strict Change Control proceedure in my development wiki to keep manglement happy. (The short of it – the Article was protected and treated as a production copy. The related Discussion area (development copy) was a duplicate of the article and is editable to authenticated users. When an edit is made, and automated email is dispatched. If the change is approved, it’s a simple matter of a wiki sysop copying the Dev copy and pasting it over the Production copy. If the change is declined, simply roll back the Discussion area)

It’s interesting to note that a google search for the keywords Mediawiki and Sharepoint has my site at the top of the results, I hardly consider myself the authority on the topic.

I was a tad frustrated with the lack of progress on our knowledgebase at work, which is based on static html pages (maintenance headache) and so I looked around for alternative solutions.

Long story short, I decided to setup a development wiki on a recycled workstation, and for a while it was kicking arse and taking numbers… but it didnt fit into the grand scheme of things. I recently presented it to management and they’ve decided to investigate modifying their existing Sharepoint solution to cater for the needs of my department.

Personally I’m slightly averse to this – I think Sharepoint is a great platform for content management and shared documentation (in terms of document collaboration – word, excel, visio etc documents) but as a knowledgebase system it’s just not suited. So I’ve been researching how to integrate Mediawiki and Sharepoint, just in case.

It’s a very hard topic to research, because everyone is too busy trying to draw comparisions between the two systems, when instead they should be focusing on how to make the two compliment each other. They are targetted at two totally different purposes, so instead of trying to get one to do the job of the other, just merge the two into one monster toolset. Just look at the solution names we tag the two with: Sharepoint is a “Content Management System” and wiki’s are a “Knowledgebase Platform/System/Solution” Comparing the two is like trying to compare a Fruit with a Vegetable.

Firstly, get the LDAP extension for Mediawiki, this will allow the wiki to hook into Active Directory for authentication, which is one of the major steps of integrating with Sharepoint – as many Sharepoint admins are rolling out Sharepoint for the reason of having a single sign on.

Secondly, you have to integrate the wiki within the Sharepoint environment. This is done easily enough by creating a web page view web part as per the instructions on this Intranet Journal Article

That should get you on the track to integration.

There are a couple of niggling problems as far as I can tell, for example it appears that MediaWiki doesnt like being held within an iframe, though I’ve only tested using http://en.wikipedia.org so it might be something that has been intentionally setup. My other thought is perhaps Sharepoint doesnt like the http://wikiaddress/Wiki_Name_Page convention, in which case you have to turn off the user friendly page names and go with the old http://wikiaddress/index.php style

EDIT: It appears that this is a design function of Mediawiki to prevent frames abuse, as I initially thought. You can read more in the Mediawiki FAQ

And the other problem I’ve noticed is that you cannot assign a percentage value to either the height or width of the Sharepoint iframe, which means that this happens:

Which is something you’ll have to figure out with maybe a resolution detection script to adjust an array. For my work it would be easy – all workstations in my department should be using a resolution of about 1280 * 1024 if they have LCD monitors, and if not, it’s just another reason for management to upgrade our workstations

EDIT: It appears that this has been discussed many times elsewhere, the most productive resolution can be found here

Well, I hope this ramble helps someone out, somewhere…

Addendum: Of course, you could just use Flexwiki as it’s developed by MS devs and has basic Sharepoint integration, but Flexwiki isnt as good as Mediawiki IMNSHO