I've not posted much stuff on the blog lately. I know. I will write about my NaNoWriMo 2013 experiences and write a little bit about other stuff that has been going on.
But here's a micro-rant about MediaWiki.
Currently, MediaWiki install at Avarthrel Encyclopædia is at version 1.21.5 and uses Semantic MediaWiki 188.8.131.52.
"But wait!" I hear you cry. "MediaWiki 1.22 is out! And so is SMW 1.9!"
Yeah. I can't upgrade.
At least this time I was able to roll back to the old versions and they keep working. Last time anything of this magnitude happened, MediaWiki was randomly totally hosed and I had to do some random data archaeology and switch to MoinMoin.
Thing is, MediaWiki 1.22's installer just fails silently. It completely, utterly refuses to do anything, even to print out error messages.
I suspect I could try installing a newer version of SMW. Unfortunately, SMW extension nowadays relies on Composer, which apparently requires PHP's proc_open() function to be functional.
Yes, PHP is a programming language that lets your system administrator to disable features, which in turn means that your ability to run software written in PHP is entirely up to the moods of the system administration. Your feature set is something or other. Read "system administrator" as "your web host". I have no control whatsoever over this. I suppose I could contact the support and ask them about this if this shit just keeps going.
Before you say "just move your stuff to another webhost!" ...no, that's not an option. Every move would require tons of tweaking anyway. And who's to say some other webhost isn't randomly doing this shit too?
I previously only had this problem when I tried out MediaWiki's new Scribunto extension, which runs an external Lua interpreter. Again, this requires proc_open(). Fine, I couldn't run the extension.
Now, apparently, new versions of SMW - the whole upgrade process - requires Composer. Many new extensions are moving to use Composer. Which fucking requires proc_open() too.
In layman terms: The webhost disabled one feature of PHP for "security reasons". A feature that an increasing number of software projects is using.
And, incidentally, a feature that most other programming languages won't consider a security hazard at all. You either succeed in running an external program or you fail to run an external program. That's up to the operating system, not the bloody programming language.
Worst of all, disabling proc_open() in web apps is justified, but no, Composer isn't a web app. It's a command line app, meant to be only run by people who know what they're doing on data they're personally managing. Nevertheless, proc_open() is disabled on both web apps and command line apps - it makes no difference. I can't run Composer,
and I can't run Drush to manage the Drupal install. (Update: Drush does seem to have a mechanism of overriding PHP settings, and I got it working. Composer, however, doesn't have this feature, because why not. Go figure. Also, this doesn't take away the fact that the security model is very daftly designed because it's all or nothing.)
I blame PHP for this idiocy. This is absolute, absolute bullshit.
PHP is one of the most widely used programming languages ever, and MediaWiki is one of the flagship applications that is supposed to prove how amazing programming language PHP is. And even it fails to work in any sane and coherent manner.
I don't blame MediaWiki developers. It's this bloody programming language.
On this date, I henceforth pledge that I'm not developing any new PHP software for personal projects. Ever. I'll stick to Python and Ruby web apps.