One of my goals with PHP is to simplify and streamline my workflow as much as possible. Ideally this helps prevent wasting enormous amounts of my time on stupid crap like autoloaders, library dependencies and re-inventing the wheel.

I’m using a few libraries on IOP’s site, but as much work as these have saved, I ended up with an ugly mishmash of autoloading and require code.

Enter the Composer project.

Composer is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you.

Together with Packagist, which is sort of a nascent RubyGems or PyPI equivalent, using libraries in PHP just got a whole lot cleaner. Composer even generates a complete autoloader, meaning a bunch of annoying code can be replaced with a simple composer.json file and this:

require 'vendor/autoload.php';

Except when they don’t. Because, sometimes, they won’t.

There’s always a catch, isn’t there?

The problem I ran into was the dated default PHP configuration on our shared cPanel host. Trying to run curl -s http://getcomposer.org/installer | php threw this back at me:

#!/usr/bin/env php
Some settings on your machine make Composer unable to work properly.
Make sure that you fix the issues listed below and run this script again:

The phar extension is missing.
Install it or recompile php without --disable-phar

The allow_url_fopen setting is incorrect.
Add the following to the end of your `php.ini`:
    allow_url_fopen = On

The ionCube Loader extension is incompatible with Phar files.
Remove this line (path may be different) from your `php.ini`:
    zend_extension = /usr/lib/php5/20090626+lfs/ioncube_loader_lin_5.3.so

* sigh * These are not settings most shared hosts grant users access to–and if you ask they’ll probably just try to upsell you a VPS. Thankfully though, many cPanel installations now allow users to select different versions of PHP (A2 does). And thankfully again, these alternate versions are often compiled with different flags.

That’s great for web pages, but Composer’s installer uses the command line. To use an alternate version of PHP in a shell, we need to know where the alternate PHP binaries are. An easy way is simply to switch the PHP Version via cPanel, then load a page containing phpinfo();. The actual PHP binary path isn’t listed, but it’s easy enough to figure out from what’s there. Mine was /opt/php/php-5.4.0/bin/php.

Once you’ve got that, you can fiddle with your $PATH (it’s searched from left to right) or just alias the alternate PHP binary:

alias php='/opt/php/php-5.4.0/bin/php'

I aliased php in my .bashrc file (reasons previously discussed) and composer installed flawlessly.

So a few months ago I mentioned wanting to get away from WordPress and PHP. It’s not going very well.

WordPress keeps sucking me back in. A favor here, a quick job there. Next thing I know, I swear I can’t remember how to iterate an array in Ruby or Python.

While sitting down to work on a WordPress project still fills me with dread, I did recently discover a few things which slightly alleviate my misery.

My favorite, as described here by David Winter, is the ability to move the wp-content directory out of the standard WordPress hierarchy. Aside from the database, wp-content holds basically everything which makes a site unique; themes, plugins, uploads, etc. With those out of the way, all of the core WordPress application code can be removed from the site’s git repo and stored as a submodule (pulling from the WordPress GitHub mirror), making version control a lot cleaner and easier and giving me one less thing to think about.

This directory layout should really be the default. The WordPress folder ought be a sacrosanct library, only changing when the application is upgraded. The ability to move wp-content was added back in version 2.6 released in July of 2008. I wish I’d learned about this sooner.

I’m also doing something inspired by Mark Jaquith’s WordPress local dev tips which also allows me to also keep my wp-config.php file versioned and outside of the wordpress directory.

Because it’s a really bad idea to keep password files in version control, I created a wp-config-db-sample.php file containing placeholders for the database login information:

That file gets copied to wp-config-db.php, populated with the appropriate settings (and added to .gitignore), then included by changing the top of wp-config.php like this:

After the obvious desire to takeover Yahoo’s unmatched traffic, the thing that most struck me about Microsoft’s proposed Yahoo! acquisition was what they’d do with Yahoo’s extensive foundation of Open Source Software.

Historically, Microsoft has had a deep institutional phobia about OSS. But Yahoo! uses PHP extensively, and Rasmus Lerdorf, the creator of PHP, has worked at Yahoo! since 2002.

This seems to make no sense. Unless the OSS and PHP backend is something Microsoft wants.

On January 31st, Mary Jo Foley published notes from an interview with Sam Ramji, Microsoft’s Director of Platform Technology Strategy. Foley rightly highlighted this quote from Ramji:

“Our focus is getting OSS on top of Windows, and I’m focused on (providing) interoperability between the LAMP (Linux, Apache, MySQL, PHP) and Windows stacks.”

She also posted this PowerPoint slide:

Boom, as they say. Microsoft wants to legitimize Windows as the foundation for a parallel WAMP stack. What better way to prove the viability of WAMP than running the biggest PHP web site in the world?

Microsoft may have finally realized that Open Source can be seen as a competitor, but also as free labor. Google and Apple, along with Yahoo! realized that a long time ago. Why try and compete directly when you can subvert it by becoming the dominant platform that software runs on? Instant credibility, and instant influence.

So far we’ve only seen the first chapter of this story, or perhaps the first act of this tragedy. The next phase looks like it may turn out to be Microsoft, Google and others fighting over Yahoo’s unfortunate carcass and tearing it to shreds.

Steve Ballmer has giant brass balls and Microsoft most likely anticipated that Google would do something to interfere with the acquisition. Microsoft is on the move. This should be an interesting week.

Disclosure: I’m currently holding Yahoo! stock and have previously owned stock in Microsoft.

Recently, I’ve spent some time working with MediaWiki for Lila’s school’s web site. A small part of what I’ve been doing has been implementing an exisiting design onto the wiki backend. In an effort not to overcomplicate anything (think longevity) I built the entire design adaptation on the default MediaWiki MonoBook theme. Everyone who’s visited Wikipedia has seen what this looks like. Monobook is a very well constructed theme with clearly defined parts that degrade nicely without its stylesheets. So far, with the exception of these two small changes, I’ve able to do everything I needed to with the default page structure.

First change: Fixing bad portlet IDs

Editing Mediawiki:Sidebar allows for nearly complete customization of the sidebar links. Custom sections automatically get custom IDs which can then be styled. There is one thing that seems like a bug however: If a section heading has a space in it, the portlet ID will have an illegal name. Classes can have spaces in their selectors, but IDs can’t. Here’s what I did:

<div class='portlet' id='p-<?php echo htmlspecialchars($bar) ?>'>

and the new one:

<div class='portlet' id='p-<?php echo str_replace(' ', '_',htmlspecialchars($bar)) ?>'>

Simple enough, PHP’s str_replace is used to swap underscores for spaces. I’m still feeling my way around the MediaWiki codebase, so this might not be the best solution to the problem, but it does what it needs to with a very lightweight function.

Second change: Classes from page title

I needed to change the background of the globalWrapper element depending on the page, the way I accomplished this was to use the page-title. This has one initial drawback, namely that colons are not allowed in CSS class names. However the workaround above can be recast here with added benefit. Switching colons for spaces results in multiple class names, so namespaces can be styled too.

Here’s the old code:

<div id="globalWrapper">

And the new code:

<div id="globalWrapper" class="<?php echo str_replace(':', ' ', $this->data['titleprefixeddbkey'])?>">

This method would seem preferrable to adding a CSS import rule which would look for a custom-named file. Even though CSS load errors don’t break pages with visible 404 errors, they would slow down page loads and litter the server logs. Checking that the CSS file exists is somewhat costly, and I suspect MediaWiki’s cacheing isn’t something that can be quickly skimmed over and implemented.

There appears to be a pageCSS extension somewhere, the hooks are even specified in MonoBook’s header, but I couldn’t find a working download and CVS repository doesn’t seem to be working anymore.