{"id":1117,"date":"2013-06-29T21:57:55","date_gmt":"2013-06-29T20:57:55","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=1117"},"modified":"2014-03-17T23:34:21","modified_gmt":"2014-03-17T22:34:21","slug":"github-extension-for-mediawiki-and-simplecache-php-library","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2013\/06\/29\/github-extension-for-mediawiki-and-simplecache-php-library\/","title":{"rendered":"GitHub extension for MediaWiki and SimpleCache PHP library"},"content":{"rendered":"

Background<\/strong><\/p>\n

\n

A few months back I got annoyed at having to maintain some documentation both in README files and on-wiki. I figured I\u2019d be a lot nicer if I could just embed those README files in the wiki and have their contents rendered. I therefore created the GitWeb<\/a> MediaWiki extension, that would get the contents of files in a git repo via the WMF GitWeb interface.<\/p>\n

This worked nicely until recently the WMF decided to use GitBlit<\/a> (which appears to be less fail then GitWeb) without continuing their GitWeb support. This meant that all the wiki pages that where embedding content pulled from it suddenly broke. After kgh<\/a>, the SMW wiki overlord, pointed this out to me, I was lazy and preoccupied with other things, so did not do anything on this for a month or so.<\/p>\n

I\u2019m currently on a week long holiday in Belgium and yesterday (Friday) evening was hanging out at the local hackerspace 0\u00d720 (whitespace)<\/a>. I figured I really ought to fix the file content embedding issue and thought this would be a quick bit of hacking to make the old GitWeb extension work with GitBlit that would take roughly an hour.<\/p>\n

It occurred to me that the new code could also fetch the file contents from GitHub<\/a>, and that this have some advantages. For one it provides increased stability. Clearly the WMF does not care about the stability of the paths provided by their git browser, so a future upgrade of GitBlit or switch to yet another tool might result in re-occurrence of the problem. Something similar happening for GitHub seems much less likely. Another point for GitHub is that more people use it, thus increasing the number of people this tool is useful for.<\/p>\n

I started work on this new GitHub extension by copying the GitWeb files and replacing GitWeb by GitHub. Inevitably I ended up wanting to do something more exciting then that. And lucky me, I saw some room for design improvements to the code.<\/p>\n

The technical part<\/strong><\/p>\n

Though it certainly is not the most elegant code ever, the old Gitweb extension certainly wins the \u201cnot a lot of code there\u201d badge. Do admire the 30ish lines of code<\/a> that make up the meat of the extension. Not very testable, flexible, extensible or reusable. Though a perfectly valid approach for such a small task. Nevertheless, boring!<\/p>\n

The steps I took in refactoring this code to the current state where roughly as follows. Some of my thoughts along the way are between these things: \u201c\u201d.<\/p>\n