Category Archives: wordpress

getting a wordpress linux box up in 5 minutes (*)

diving

If you’ve ever went to the trouble of setting up WordPress on a Windows machine yourself, going through a PHP, MySQL and phpMyAdmin installation, then sort through all the IIS crap you run into you’ll love TurnKey Linux virtual appliances (aka pre-installed virtual machine boxes).

You can for example download a WordPress appliance which has all the stuff mentioned above pre-installed, launch it in VMWare Player, go through a 5 minute config et voilà! You have your very own virtual Ubuntu box up and running with a fully functioning fresh WordPress install on it. You can even flex your 1337 Linux command line skillz through “Shell in a box” which simulates a shell window in your browser. Or you can use SFTP/SSH. Wickedness indeed.

There’s more fun to be had though. Lot’s of other cool appliance are available containing tons of Open Source Software to be messed with. There’s a LAMP stack, one for Drupal, Ruby (how hip!) etc. Not quite geeky enough for ya? Well alright, go ahead then, get one of those appliances and upload it to Amazon EC2 and be all “in the cloud”. Cause they can do that you know. Oh yeah.

Don’t know if it’s a good idea though. Security wise and all.

(*) If you have VMWare Player installed and already downloaded the zip file of course. :)

Photo by MissMaze, cc-licensed.

making your blog go mobile

Mobile! It’s the latest and greatest of the buzzes isn’t it? But it’s damn right too, because more and more people are starting to use their mobile devices to reach out into the fabulous and marvellous inter-webs to do all sorts of productive things like using twitter, visiting reddit, tumbler and 4chan or read interesting articles on websites and blogs (probably being posted in their twitter stream) about kittens.

So let it be known that in the year 2010 A.D. you better bloody well have a mobile version of your website online or you’re going to miss out. Well, maybe not miss out, but you won’t be one of the cool kids (see photo) for sure! So how do you join the club of the hip and mobile-ready web sites?

Lot’s and lot’s of programming, l33t CSS skills and plenty of testing on all sorts of devices will get you there.

Or if you’re running a WordPress blog, you can also check out these two plugins which basically turn your old fashion 2009 blog into a futuristic mobile-touch-screen-enabled piece of awesomeness!

  • WpTouch: turns your blog into it’s touch-friendly html self and allows people with iPhones and Android devices (among others) to easily tap and click around with their greasy thumbs.
  • WordPress Mobile Edition: the name sort of gives it away doesn’t it? This baby enables those poor sobs who still have and oldskool smartphone without a touch-screen to use your site as well.

You can run them both to make sure you aren’t missing a single mobile hit on your site.
Very 2010.
Very hip.

Photo by Kid Paparazzi, cc-licensed.

wordpress woes: cut-off posts and how to fix them

A while ago I found out some of my older posts were cut-off in the middle of a sentence or even in the middle of a word. Turns out that somewhere along the way of performing WordPress upgrades the MySQL tables’ collation had changed from a latin1 variant to utf8. Turns out that this conversion doesn’t work without it’s flaws and ends up cutting off your posts where “special characters” are used in the text. So if you use a word like “trés” your post suddenly ends with “tr”…

I wasn’t very happy with that as you can imagine. What’s even worse is that this kind of data corruption is hard to detect as well. I ran into it by accident while dishing up an old post to link to. How many more of my posts were also mangled like this? So it was time to dish up some SQL magic to help and figure out how big the damage was.

I ended up writing this simple statement which detects any posts not having their last character in a list of characters which typically end a post. A dot for example as a last character indicates a full sentence and without a space after it chances are big it was the last sentence as well. The query also displays the last 50 characters of the post which allows you to judge if a post really has been cut off or if it’s a false positive.

SELECT id, right(post_content, 50), post_content
FROM `wp_posts`
WHERE right(post_content, 1) NOT IN (".", "!", ")", "?", ">", "]") AND post_status = "publish"

All I needed after this was a backup of my database that still contained an intact copy of the affected posts. Luckily I have been using the WP backup tool to email me a database backup every day since 2007 so that wasn’t a problem. To restore the content of the posts I transformed the SQL insert statement from the backup to an update statement looking like the following to update the post back into it’s original state:

UPDATE wp_posts
SET post_content = '<Old post content goes here>'
WHERE id = <id>

The special characters in the post were in most cases transformed into blocky question mark symbols when reloading the post in the WP editor. So after some manual labour to reset those into the proper characters the post was ready to be republished and finally restored.  Yay!

So this proves once again that there’s no such thing as too many backups and that collation issues are a bitch for all developers out there. Some tables are still in latin1 so I think I’ll have to convert those at some point to utf8 to be safe. But that’s something for later.

Photo by daveknapik, cc-licensed.

using javascript code in wordpress posts and pages

For this bookmarklet creation tool I posted a while ago I noticed that it was actually quite hard to get some custom written JavaScript code embedded in a WordPress post. When searching for a solution to the issues I ran into, I noticed there either wasn’t a lot of info to be found on this topic, or the plugins that where supposed to fix this where either not working or causing other side effects.

So what kind of issues did I run into when trying to get my JavaScript code to work?

  1. Empty lines in JavaScript code cause a “<p>” paragraph tag to be inserted causing it to become invalid.
  2. Using CDATA tags as proposed by some does not prevent the paragraph tags from being inserted when white-lines where used. Once you save your post or page the editor will wrap the code in CDATA tags anyway, but that doesn’t cause any problems.
  3. HTML tags in strings used in the code caused the tags to be filtered out by the WYSIWYG editor.

What I wanted to find was a solution that allowed me to used JavaScript directly in the WP post and that made it safe to switch between HTML-code view and the visual editor. I found that sometimes the JS code works as long as you stay in the HTML-view, but as soon as you switch to the visual-view it gets mangled up, causing the code to break. This is a bit fragile and it would really suck if you’d have to fix the same code over and over again simply because you edited it in the wrong view. So we have to avoid this at all cost. A (working) plugin would be nice, and I didn’t feel like changing templates or core WP files to get this to work.

So how do you get it to work then without having to install any additional plugins?

  1. Don’t use empty lines in-between the code lines. It’s annoying to read since it’s all packed together but you can’t avoid  the paragraph tags from being inserted any other way.
  2. To avoid the HTML tags from being removed from the string data you have to break up the HTML tags so the editor’s regular expression matches don’t catch them any more. For example instead of the string ‘<br />‘ you use '<' + 'br />'.
  3. Write and test the code in your favourite editor and browser. Once it works, apply the above changes to your code to make it work in your post or page.

If you follow those tips your JavaScript code will continue to work after the editor mangles it. However, this doesn’t make it any easier to edit the code afterwards. So if you intend to insert a reasonable amount of code it would be wise to keep a copy of the code in case you want to edit it again easily afterwards.
Another option is to put all your code in an include file, include it in your post and simply call the necessary functions. The advantage of this approach is that it makes your code more manageable and easy to update. The annoying part is that all code isn’t safely embedded in your post so you have to maintain an extra file on your server which you might forget when you’re backup things up or switching hosts.

Photo by ruiwen, cc-licensed

new theme! finally! yay!

For a while now I was getting pretty tired with my old blogging theme, and wanted to restyle the whole thing. For the new theme I wanted to be able to use widgets, which makes changing your layout so much easier. I also wanted to use the extra screen real estate everybody has nowadays by broadening the columns up a bit, and have the content adapt to the screen size.

Since I like minimal themes I went for something without a lot of images in it. I still like gradients, even though I’ve heard they’re so 2007, but I used them never the less. I’m not a graphics artist, so a wicked looking vintage or cool scruffy looking layout isn’t up my league anyway. Gradients are super easy to do in GIMP btw, which makes my life so much easier, and I like that.

The theme itself is based on SandBox, which is awesome. Building  a good theme from scratch for WordPress is pretty hard and wasn’t my ambition anyway, and SandBox sure makes it easy to concentrate on style alone. Another SandBox theme I drew inspiration and CSS examples from is Takimata. This is probably one of the most original SandBox themes around, and is definatily worth a look if you’re looking for something different. I almost used this one as is.

To see the theme in all it’s glory any browser except Internet Explorer will do. Thanks to Browsershots I tested the new  layout on more browsers than I can remember, and IE is the only one that isn’t displaying the geeky looking slashes in front of the titles. Check the screenshot if you’re not on a kickass browser btw.

Some tweaking will probably be done in the next few weeks, but with the widgetised sidebars, that’s possible without having to change a single line of code, which is awesome.
Yay!

photodropper wordpress plugin

CC logo on an orangeI checked out the new Photodropper WordPress plugin lately, which looked like the gem of a plugin I have been looking for recently. It allows you to search Flickr’s vast pool of Creative Commons pictures straight from WP’s writing page, and insert the chosen pictures complete with attribution links and all.
Sounds sweet as pie right? Well don’t go jumping around naked in glee just yet, there’s more to it than that.

For one the provided attribution is flawed. Instead of doing what’s said in the CC license legal text they only provide a link back to the original author. The original name of the work is not mentioned, and there is no link to the original CC license used either.

Here’s what the CC FAQ says about it:

the proper way of accrediting your use of a work when you’re making a verbatim use is: (1) to keep intact any copyright notices for the Work; (2) credit the author, licensor and/or other parties (such as a wiki or journal) in the manner they specify; (3) the title of the Work; and (4) the Uniform Resource Identifier for the work if specified by the author and/or licensor.

They actually link from the Creative Commons icon links back to a page on their own site, instead of the original website. I’m not sure why they did this, and it surely strikes me as odd.
Another weird thing is that the plugin is copyrighted for some reason, and not published under an open source license as is the case with most WordPress plugins. That’s their choice of course, and perhaps they are quite liberal about changes to the plugin, but there is no way to tell if you’ll get your arse suid if you alter the code…

I’m hoping the next version will fix these shortcomings though. For now however, I’ll have to resort to tediously crafting my CC attribution links myself.

(Picture “CC on orange” by yamabobobo, some rights reserved)

wheeee, it's up

Physical View of the Network by KryptykThe name servers are pointing to the new Linux machine from now on, and things are running smooth (so far).

The WordPress database issue was solved by upgrading to the latest 2.3.1 version, which required a DB upgrade anyway, and fixed the tables that where incorrect. I had manually fix the md5 hash codes for the passwords, but since only a few users have accounts here, that wasn’t a problem.

I have nice permalinks up again now, without that index.php thing in them even, so that’s even better than before. I’m using Dean’s Permalink Migration plugin to make sure old links from all over are still working, and not loose too much Google rank etc, though I doubt that all those http errors from the Windows machine did a lot of good for that.

While I’m at it, here’s a tip if you plan to migrate a WordPress installation any time soon. Then you’ve restored a database backup on a new system, the first thing to do is adjust the blog and site URL to the new location. While you’re at it, change the blog title as well.

WordPress has a habit of using those URLs a lot in redirects, and if you forgot to change those, you’ll end up being swung over to the site your backup is from. If you didn’t change your blog title there’s a big chance you won’t notice you’re now working on the live site, and might end up screwing things up.
Which ain’t fun.

You can find and change these parameters in your mySQL database in the wp_options table with the values (option_value) “home“, “siteurl” and “blogname“.