I’ve been digging deep into the innards of MediaWiki, the software that powers Wikipedia and hundreds (thousands?) of other wikis, for a new website I’m working on. I chose to use MediaWiki because it’s one of the most featureful wikis available, yet isn’t so complex that it takes forever to customize.
Unfortunately, while it’s a nice enough application on the outside, MediaWiki’s insides are complete shit. The code is a horrendous mess, but that’s not the worst thing about it. The worst thing is that it’s a badly-architected horrendous mess.
There are places where the developers make feeble attempts to separate logic from presentation, which in many cases just ends up making things more complex, because you end up with a sort of pseudo-separation where some parts of the presentation layer are separate, while others (a lot of others) are still embedded in the logic.
For example, each section of the sidebar is defined in a completely different part of the application. One section is defined in, of all places, a language file. Another is defined in a skin template. Yet another is embedded in a PHP include deep in the heart of the application. It’s ridiculous.
I was also shocked to discover a directory named maintenance, which is included in the web root of the application and contains hundreds of command-line PHP scripts intended to be run only by administrators. One of them is named eval.php. Guess what it does?
The only thing keeping the public at large from executing these scripts over the web is an .htaccess file. That’s fine if you’re using MediaWiki on an Apache server configured to allow .htaccess overrides, but what if your server isn’t Apache? What if it’s not configured to allow overrides? I didn’t see anything in the install docs that warned me I needed to secure this directory.
Here’s a nice little snippet from MediaWiki’s default skin class, MonoBookTemplate:
<div id="p-cactions" class="portlet">
<h5><?php $this->msg('views') ?></h5>
<ul>
<?php foreach($this->data['content_actions'] as $key => $tab) { ?>
<li id="ca-<?php echo htmlspecialchars($key) ?>"<?php
if($tab['class']) { ?> class="<?php echo htmlspecialchars($tab['class']) ?>"<?php }
?>><a href="<?php echo htmlspecialchars($tab['href']) ?>"><?php
echo htmlspecialchars($tab['text']) ?></a></li>
<?php } ?>
</ul>
</div>
<div class="portlet" id="p-personal">
<h5><?php $this->msg('personaltools') ?></h5>
<div class="pBody">
<ul>
<?php foreach($this->data['personal_urls'] as $key => $item) { ?>
<li id="pt-<?php echo htmlspecialchars($key) ?>"<?php
if ($item['active']) { ?> class="active"<?php } ?>><a href="<?php
echo htmlspecialchars($item['href']) ?>"<?php
if(!empty($item['class'])) { ?> class="<?php
echo htmlspecialchars($item['class']) ?>"<?php } ?>><?php
echo htmlspecialchars($item['text']) ?></a></li>
<?php } ?>
</ul>
</div>
</div>
Notice the lovely mixture of HTML into a PHP class, as well as the complete lack of sensible formatting. This is just a tiny sample; there’s lots more.
In spite of all this, I’m still going to be using MediaWiki, because, sadly, it’s the best thing out there at what it does. That should tell you a lot about the general quality level of open source PHP applications.
