@madpilot makes

I’m a professional web developer, so it goes without saying that I’ve seen my fair share of off-the-shelf open source web applications. I’ve also seen my fair share of web design companies take these applications and modify them up the wazoo to fit with clients requirements… Well, sort of. It is probably more likely that the sales staff have managed to convince the client that their requirements should fit in with what the open source project does. On behalf of all the web application developers out there who get lumped cleaning up the mess: STOP IT.

Modifying open source software seems like a perfect solution to managers – the solution is almost done, so surely it is just a matter of a few tweaks here and there, a splash of paint and Bob’s you uncle. Yeah – nah.

Here is somethings to think about before modifying an off-the-shelf to your next client.

1. You can’t guarantee the code. Unless your developers has spent A LOT of time working with the application, they aren’t going to know the code. For them to become familiar, they are going to have to spend a lot of time getting to know it. This doesn’t save time, it wastes it. “But they will know it for the next client!” I hear you cry. Don’t bet on it. Unless you are doing the same mods for another client, they are going to have to spend the same amount of time investigating it next time.

   • Making core changes to a system is just asking for trouble – I hope the time you saved by using the system is re-allocated to testing the FULL application – you have no idea what you will break.

   • Skinning pre-built applications sucks. Trying to modify some else’s CSS is worse than someone else PHP. Just like modifying core code libraries and hoping for the best, it is really hard to know what you will break. That is of course assuming the application isn’t a spaghetti of tables, and includes that have little structure (Xoops, osCommerce, Joomla – I’m looking at you).

   • Open source developers are very narrow minded – their contributions are to suit their specific need, which means every developer will try to include their feature, and unless the leads are ruthless, you end up with a application that has everything that opens and shuts, but that doesn’t really open or shut very well. Not only that, you end up with a situation where there are thousands of different modifications that do the same thing. osCommerce is the perfect example of the mess this creates – I had to find a gift voucher module – and found at least 12 different variations of the same plugin, none of which worked. If I see YMMV on the end of one of these modifications I’m going to hit someone.

     • As soon as you modify software, forget about updating it. If there is a security fix, or a new feature, you will basically have to spend a similar amount of time re-patching the new version with your changes. If you wrote your own application, you can add a feature much more easily.
     • “Modules” are a misnomer, I am yet to see a decent module system for anything but the most basic feature – they all involving modifying code to work, which is you ask me, isn’t a module.
     • The documentation will never be up to date. On of the selling points of open source software is that you have thousands of developers at your disposal to fix and add features quickly – unfortunately, the documentation never keeps up. You better get used to reading source code.
     • Open source apps are hacked not engineered. Design by committee never works, design by ad-hoc anarchy REALLY never works – if the project doesn’t have a clear leader who has a vision and is ruthless in implementing it, you are going to end up with a mess.
     • Support. You don’t get any. Budget time for your developer to scour the ‘net for an obsure german forum where someone has found a solution to the similar problem you have had that may or may-not actually work.

     So when is open source the right thing to use? If the system does exactly what you want, then go for it. Want a blog? WordPress is an excellent blogging system, but it isn’t a content management system, so don’t expect it to work like one.

     Let me state that I’m making a big differentiation between applications and frameworks or libraries. I encourage the use of frameworks and libraries, because you can still control your code. You are leveraging low-level code, which is the boring stuff (for some) and you are left with building a system that your client actually wants.

     So please, continue using Rails or PHP or Apache or MySQL, but leave osCommerce and Xoops at the door. If you still want to use the latter, make sure you give your developers enough time to work through the issues you will have – about the same amount of time that you would have quoted on a custom solution in the first place should suffice.

WordPress has the ability to generate permalinks, which is great for Search Engine Optimisation. But what can you do if you need to change between them? Changing them in WordPress isn’t a problem – you go to the “Options” tab, click permalinks, and select a new one. However! If others bloggers have linked to your posts, or a search engine has already indexed your blog, their links will break.

With a little bit of .htaccess trickery you easily* change between the different options without breaking your old links!

Why the star next to the “easily”? If you have a lot of posts, it could take a while, but read on….

Out of the box you have three options (There is a fourth, but if you use that option, you probably don’t need this guide!):

In terms of SEO, The best option is Date and name based – having the title of the post should give a higher ranking. Next best is Numeric, but only because it gets rid of the &p=123 part from the URL. Luckily moving from Default and Numeric to Date and Time is easy!

If you are moving from Default to one of the other options, then there is nothing else to do – WordPress automatically responds to this style of this URL regardless of what option is selected.

There are two ways of moving from the Numeric Option to one of the other options – the quick way and the right way!

The Right way

The right way uses a permanent redirect (using Apache’s mod_alias module) for each blog entry – this will tell search engines that the page doesn’t exist any more and that they should index the new page instead. Unfortunately, this doesn’t update links of other peoples pages, so you will need to leave the hack for the life of the blog.

Open up the .htaccess file and add the following BEFORE the # BEGIN WordPress line:

<li class="li1">
  <div class="de1">
    RedirectPermanent /blog/<span class="nu0">2007</span>/<span class="nu0">02</span>/<span class="nu0">05</span>/this-is-my-blog-post /blog/?p=<span class="nu0">123</span>
  </div>
</li>

<li class="li1">
  <div class="de1">
    RedirectPermanent /blog/archive/<span class="nu0">123</span> /blog/?p=<span class="nu0">123</span>
  </div>
</li>

<li class="li1">
  <div class="de1">
    <IfModule>
  </div>
</li>

You will need to dig into the database to find what ID number corresponds to each post. This is tedious even for a small number of posts, so I prefer the quick way. The IfModule line check to see if the mod_alias module is installed. The first RedirectPermanent link shows an example of changing from the Date and Title option. The second line shows how to change from the Numeric option.

The Quick way

The quick way uses Apache’s mod_rewrite module to rewrite the URL – as such it will only work when converting FROM numeric mode. If you need to convert from Date and Name to numeric, you have to user the Right way. Drop the following code BEFORE the # BEGIN WordPress line:

<li class="li1">
  <div class="de1">
    RewriteEngine On
  </div>
</li>

<li class="li1">
  <div class="de1">
    RewriteBase /blog/
  </div>
</li>

<li class="li1">
  <div class="de1">
    RewriteRule ^archives/<span class="br0">(</span><span class="br0">[</span><span class="nu0"></span><span class="nu0">-9</span><span class="br0">]</span>+<span class="br0">)</span> /blog/index.php?p=$<span class="nu0">1</span>
  </div>
</li>

<li class="li1">
  <div class="de1">
    <IfModule>
  </div>
</li>

The IfModule line makes sure mod_rewrite is enabled, the next link tells Apache to turn mod_rewrite on. The RewriteBase line tells apache to automatically prepend /blog/ to all rewrite tests. The second last line is the meat and potatoes: it tells apache to rewrite any url that looks like /blog/archives/[one or more numbers] to /blog/index.php?p=[the numbers].

I would highly recommend using the Date and Name option – thankfully converting to that option is the easiest to do!