Rubénerd!

XAMPP is currently only availably as 32 bit application. Please use a 32 bit compatibility library for your system.

Aaaaaaaah!

The problem

We've all seen that famously misspelled error message when attempting to install XAMPP on our 64 bit desktop Linux machines. I wonder how many people using XAMPP are still on 32 bit? I suppose enough to justify keeping it 32 bit. Speaking of which, this Kingston biscuit is falling to bits. Munch munch.

Here's the install scenario that will result in that error.

# tar xzvf xampp-linux-[version].tar.gz -O /opt
# cd /opt
# ./lampp start

Chemists have solutions

Other guides I've come across ask you to install a slew of things, and changing the launch script. For me on Fedora 17 x86_64, I was able to run it just by installing this:

# yum install glibc.i686

This also pulls in nss-softokn-freebl.i686.

Now you can run XAMPP without modification:

# tar -C /opt
 sudo ./lampp start
XAMPP: SELinux is activated. Making XAMPP fit SELinux...
Starting XAMPP for Linux 1.8.1...
XAMPP: Starting Apache with SSL (and PHP5)...
XAMPP: Starting MySQL...
XAMPP: Starting ProFTPD...
XAMPP for Linux started.

From about 16:50 to 16:55 UTC+11, the site was down. My bad, all good now!

Vinícius Lira over in this comments thread has proposed a ridiculously elegant solution to using a default WordPress installation to host multiple blogs on different databases. If it works, it's genius.

STEP ONE: Create a subdomain that points to your WordPress installation, such as "http://newblog.site.com/"

STEP TWO: Create a new database, such as "newblog"

STEP THREE: Edit the "wp-config.php" file and replace:

define('DB_NAME', 'wordpress');

with:

if($_SERVER['HTTP_HOST'] == "site.com" or
$_SERVER['HTTP_HOST'] == "www.site.com") {
  define('DB_NAME', 'mysitedatabase');}
elseif ($_SERVER['HTTP_HOST'] == "newblog.site.com") {
define('DB_NAME', 'newblog');
}

Haven't tested it myself yet, but it seems too simple. It shouldn't work. If it does, it'd be schweet.

Every time I try to pry myself away from WordPress which I've been moved over to in 2005 after thinking for far too long, another feature comes along that makes the decision harder. I'll give you the attention you deserve one day Django!

In this case, it's the ability to show a summary of a post with a link to read more, but only posts you elect it to happen to. Given I merged all my blogs into this one recently I've decided to use this on anime reviews which tend to have a ton more graphics and are much longer. It also means I can append a mild NSFW warning on some posts above the read more link when Her Senjougaharaness insists on spending half an episode in the shower.

To pull it off, make sure you have this code within the the_content() method, NOT the_summary() as you may assume. Finally, wherever you want the more link to be inserted, add <!--more-->.

Spiffyness.

Coursesy of Nick Hodge of Microsoft I read this article from The Register discussing Microsoft Azure's support for PHP. In particular these paragraphs stood out:

Yes, let me introduce you to the professional PHP programmer. You see, PHP is like a handgun. On its own, it is simply an inanimate tool that has no moral leaning. In the hands of a responsible citizen, it can be used to the benefit of society. But in the hands of someone who is untrained or mentally unstable, it can be used to commit horrible atrocities.

Whenever there's such a tragedy, other developers are quick to blame PHP. If PHP were illegal, then Yahoo would never have happened. If we regulated PHP tightly, then there would be no Digg. Now, it's not fair to say that the world would be better off without PHP, but its community could certainly use less encouragement, which is why Azure's support for PHP worries me.

This has been one of my primary criticisms of PHP from day one, aside from some elements of the language that don't make sense. PHP can be used to create elegant and fast web applications, but only in the hands of competent programmers. It is way too easy to easy to create horrible spaghetti code in PHP. Even in the hands of said competent programmers, maintaining PHP code others have written I think is also more difficult than it needs to be. Then again I've heard people use the exact same observations to claim the language is more flexible; each to their own.

In a way I make up for a lack of time by using high level languages like Ruby and Python because more than PHP (or Perl) they force you to do things "more correctly", Python moreso.

My post about Michael Franks was the last to use the SimpleTags plugin. Couldn't think of any other picture to put here!

When I started using it for this blog back in 2005, WordPress didn't have native tagging abilities. The Ultimate Tag Warrior was the most popular third party plugin to provide them at the time as evidenced by the importer available for it in more recent WordPress versions. I chose not to use it because I've never been comfortable with plugins altering my blog's database.

The solution I found at the time was Broobles' SimpleTags which allowed tags to be defined within the text of a blog post either inline or in a block. When the post was rendered the plugin would generate a nice list of Technorati tag links with the rel="tag" attribute so they'd be recognised as such. No muss, no fuss.

ASIDE: All posts here that used SimpleTags have since been mass tagged with the simpletagged tag using WordPress's tagging system. That's right, I have an internal tag for posts that have been tagged in another system. I also had a grilled chicken sandwich for lunch, and I don't hear anyone complaining.

When WordPress implemented tagging support I stopped using SimpleTags, meaning most of my posts from 2006 (and very early 2007) still have them. Fortunately SimpleTags still works even with the latest versions of WordPress so I can keep it installed to generate those links. For example, I can define a few right here:

tags, tagging, simpletags, wordpress, php, plugins, grilled cheese sandwiches, jaffles, software, reviews

That was fun, I haven't done inline tags in a long time!

Even though I've moved over, I can see situations where SimpleTags would still be preferable to using WordPress's tagging abilities. Unfortunately (in my opinion) WordPress handles tags very much like categories in your blog database, meaning if you don't want your tables to get ridiculously huge and therefore take longer to backup, you have to be more restrictive in your tagging. With SimpleTags you can tag a post with as many as you want; I remember on many posts I would include several different spellings of the same word, and with posts about software I'd include a generic name tag along with a more specific name and product version tag.

So I did end up reviewing SimpleTags, it just took 4 years to do it ^_^.

This is probably old news in the WordPress world since 2.6 and subsequent versions have been released, but given I've decided to stick around using it for a bit longer I thought it was worth getting right when I installed it fresh here since the [forced] move.

One feature I really don't use is Post Revisions. While I can see the benefit of using it on a Wiki, on a blog written by just one guy it doesn't really make much sense; plus it adds junk records to the database which makes backing up said blog a more time consuming process than it needs to be.

Courtesy of Lester Chan, if you want to turn Post Revisions off, just add the following line to your wp-config.php file.

define('WP_POST_REVISIONS', false);

He also has instructions on how to delete existing entries made my Post Revisions if you've had it turned on for a while.

For those of you following my adventures with the WordPress WXR/RSS export feature (here, here, here and here), I finally figured out why the resulting file was truncated and only contained posts up to October last year. It's so simple I'm kicking myself for not figuring it out sooner: PHP on my webhost was configured to only allow a maximum file size of 4MiB.

As I've said before I'm not a PHP guy so I had to do a bit of digging, but it turns out the most reliable way to increase allowed file sizes if you don't have access to your php.ini file (usually this is the case) is to add the following line to your root .htaccess file:

php_value memory_limit 32M

You might have to do some trial and error to find a size value that works. If in doubt, contact your webhost.

I think the people at WordPress ought to include a simple warning on the Export page of people's blogs informing them of the file size limitation on their web servers, or barring that issue an error if it runs out of space with a link to a page explaining how to increase available file sizes instead of cheerfully and misleadingly informing users the export is finished. I imagine there are plenty of people who've been caught out by this, some of whom I'm sure aren't web developers and wouldn't know where to even start looking to solve this.

This is the logo for phpMyAdmin right? :). Photo by wileypics on Flickr

UPDATE: This was another blog post I thought I'd published, but for some reason it was only saved as a draft, whoops! The original timestamp was for 2009.03.24

Reading back some comments I've been receiving from people regarding my long string of WordPress WXR/RSS Export posts, it seems I didn't explain what I'm trying to do very well.

The problem is, I have three separate blogs and a podcast which I'm trying to merge together into one blog (but with separate categories etc) to make it easier to maintain it all. To do this, I obviously need to export the posts from all these WordPress installations and import them into the new site.

Along with more traditional MySQL table exporting, WordPress has an Export Posts feature which creates a single "WordPress eXtended RSS" WXR file which you can import into another blog (I think even Movable Type supports these now). The advantage of using WXR files instead of exporting SQL files is that it's easier for WordPress to merge multiple sources of posts because fields like the post ID are created as they're being imported. As I understand it with WordPress tables, if you tried to import two sets of tables from two separate databases into one, there might be overlaps and clashes and it could get messy. Or if it is possible, it certainly wouldn't be as easy or straightforward.

Anyway, it turns out that while the WordPress Export feature works fine on three of my WordPress installations, on this blog it seems to fail at a seemingly random point in October last year, and I haven't been able to figure out what's going on.

I've been thinking perhaps the key is to export a SQL file from PhpMyAdmin from this blog, import it into my new meta blog, then use WordPress to import the WXR files generated from the other sites. That way it doesn't matter that WXR doesn't seem to work here.

I haven't bothered learning too much about the inner workings of WordPress or it's database because I've been intending to move off it for quite some time, but studies and work keep getting in the way! WordPress is really easy to use, but it's really kludgy in some areas and it's security record is less than stellar. I use MediaWiki for many projects, but it would be overkill for a site like this.

Clear as mud!

Photo from my Flinders Ranges set on Flickr. Think it captures the mood pretty well.

Thought I'd just post another quick update on my adventure to get the WordPress WXR/RSS export feature working. In an earlier post I claimed I had given up on this, but since then it's been gnawing at my mind enough to make me want to figure out what's going on!

ASIDE: Sometimes I find thinking out loud helps me work through a problem. Please forgive me if I make no sense! Well, less sense than I usually do.

I read in several WordPress forum posts that sometimes faulty authors (ha) in the database are enough to confuse the exporter, so I merged my authors into one. Not only didn't this fix the problem it actually made it worse; before it would export 4.4MiB of data, now it exports 4.2MiB worth. This translates to exporting all the posts I've created here up to early October last year.

I'm not a PHP guy, but I figure if this problem was being caused by an insufficient maximum file size value in my host's PHP settings, doing something on the database end wouldn't make any difference. I've also seen people throw around numbers like 25MiB and discussing the need to use Gzip on PhpMyAdmin for example; my blog would not reach that.

My next thought was that it might be a poorly formed post that trips the exporter and stops it. If this were true though, I would expect the exported file to abruptly end; instead it's well formed (well, as best as a WXR/RSS file could be expected to be) and has all the correct end tags in place. It's a valid file, it's just missing a large swath of posts! Also, every single post validates as XHTML 1.0 Strict except one which has an embedded video, and that was written much later than when the exporter stops.

I also doubt it has something to do with the server configuration because my Rubenerd Show WordPress installation on the same server was able to export all the posts without any problems at all. I can only logically surmise that there must be something up with my WordPress install on here, or a fatal error in one or more of the MySQL database tables. I've only been running this install since early 2006 but who knows, perhaps something corrupted it.

I will figure this out if I have to stay up all night... if only the Boatdeck Cafe was open 24 hours!