Anyway, I figured I might as well move the entire thing to an open CMS project that I’ve heard some good things about and already implements everything and more that the customer could ever want. That’s CmsMadeSimple.

Converting the old website to the new one was trivially easy. Copy/paste the stylesheet (first mistake), edit the basic template with a menu section, create the pages (copy/paste, copy/paste).
After fixing the html errors that were in the source the page looked like a pixel-perfect copy of the original.
Except for the places where the HTML errors were fixed that is. (the center class now actually worked for instance)

However, when adding the print links I ran into an interesting issue.
Adding print links is also a trivial thing, simply put {print} somewhere in the template, and possibly add some options to show an image instead of a text link etc.
However, the links were kinda broken, they gave empty pages. So I figured “duh, the print template still needs to be fixed”. However, as soon as I added the {content} tag to the template, I got a nice internal server error. WTF.

Checking the logs I could only find nice reports of this:

Well… .I expect nothing less from php. Pleuris-hoere-product. But how the heck… just because I added content to the print page? What’s so special about that?

After digging around (enabling logs etc) and enabling fopen for php (which I had disabled for security), I noticed this:

AHA!. Apparently the printing module fetches the content (or at least, tries to) from the webserver, fails, and then segfaults php. Excellent code guys!
The reason for the failing is obvious from the logs here, I require authentication for the website since this is a test location that shouldn’t be public. Quick fix, allow the server to skip the login (vhost config):

Problem solved. (Hint Printing Module: render your own shit, don’t cheat with fopen/curl)

Oh yeah: CmsMadeSimple rocks for these simple websites where your customer wants to “change some texts and add a picture”. If they can handle word, you can make them handle this (but show them how!).
Give them permissions to add pages and nothing else, write a decent template for them, done.

Anyway, suphp is still nice to have for simple sites that don’t get many hits or don’t need to be very fast. Therefore I wanted to have both options available. Here’s how.
I started out with the Slackware packages for php and apache, but soon found both to be inadequate. Php lacked some modules that some site wanted, and apache didn’t even bring suexec along.
However, the slackware layout is good enough so I altered the slackbuild script a bit and built my own apache. You might need to install some packages as dependencies though. For instance I didn’t have ‘expat’ and ‘db44′ installed.

Now edit the slackbuild file so it compiles with your compile flags. My changes were:
1. Changed VERSION to 2.2.14 (was 2.2.13)
2. Added these to the configure flags (to enable suexec) around line 103:

Compile and install it. Note that the suexec part requires root permissions, so I did this as root.

PHP and suPHP

Note that since php is a pleuris product it will ignore the DESTDIR variable that usually works for creating a package. If you want a nice package for php, consider using the slackware build script instead. (I was too lazy for it this time). Next suPHP:

That went smooth. PHP could learn something from this. Now we still need to configure suphp. To do this we create 2 files and alter httpd.conf a little.
First suphp.conf:

Personally I left most to default, but I did change the log path and the docroot.
Next we need to enable it in apache, but to keep module stuff in their own section we put this in mod_suphp.conf which we include in the httpd.conf.

That should be enough. Now for sites that you want to enable suphp, simply add a few lines to their vhost config like this:

Now you should have a working suPHP installation (provided that you restarted apache etc).
If something fails, check the logs, especially suphp.log and of course the apache error_log.

FastCGI

To get this running I loosely followed this blog post. It pretty much worked like Brandon explained, after I recompiled my apache for suexec support that is. Thus a summary:

Install FastCGI

Now for the magic part, enabling it in a vhost.
First we need a php wrapper script:

Note the -d apc.shm_size=64 option. This specific option is to set the cache size for APC, but this way you can give php custom settings per vhost. Neat huh? If you want to give this vhost its own php.ini you can add this to the script:

PHP will check for a php.ini in that dir. Make sure to check the permissions on these dirs though, especially on the wrapper script. Your users might do stuff you don’t want if you let them alter these things.
Finally to enable FastCGI per vhost, add something to the vhost configuration like this (make sure to disable suphp on that vhost!):

Restart apache and you should see stuff like this in the process list:

APC

Now for some speedup. Let’s see apachebench on that magento vhost without APC and FastCGI:

As you can see it takes more than a second to get the page to load. Well, 0.8s mean across all, but 2.5s per request.
Let’s install APC:

Restart apache and voila. Time for a new benchmark.

W000t…. that’s a lot quicker, almost 4 times as fast. Nice

I felt like updating my shit today. Somehow I enjoy updates so I do it whenever I see interesting stuff.
So glancing through the slackware changelog I noticed a new Apache2 version (2.2.12 with a bunch of security updates). Meh, not my favorite piece of garbage to upgrade, but local upgrades were easy enough and also the remote (slackware 11, custom builds) ones went without hickups.

Then there was a new version of Irssi - 0.8.14. Fine, updated that too. Good to see it didn’t break my scripts

Meanwhile I checked out if the apache upgrade broke my notes, but it didn’t. While on the notes page I decided to write this little snippet,
and found out that also WordPress had a new release – 2.8.3. More security stuff.
And the codecolorer plugin that I use for the code snippets also had an update.
Updating wordpress was easy enough btw, just go to admin – tools – upgrade and hit the upgrade automatically button. I like features like that in a product.
Note that this failed at least two times because of a 60 second timeout on the download. Guess they need to invest in faster servers
“Download failed.: Operation timed out after 60 seconds with 1226456 bytes received”…. too bad they don’t give me other options when that happens.
And while I’m moaning about their ‘automagic upgrade’, how about some ajax progress indicators etc guys?
In case you also run into the timeout issue:
Don’t bother downloading the file yourself and putting it in the /your/wordpress/path/wp-content/ dir. Hitting the button over and over will
only swamp their servers even more and won’t make it any better either.
I tried increasing the php timeout on the sockets, but that didn’t seem to help. Pity guys, real shame… in fact, it angers me. *grumble*morons*grumble*
You might as well go for the manual upgrade.

At some point I got pissed enough to grep and read through the source for half an hour (AAARGH MY EYES) and distill this patch:
Edit wp-admin/includes/file.php with your favorite editor and change line 448 so it has a more reasonable timeout, I put it to 300:

Now it finally worked

While on the update tour I also updated my MPD to version 0.15.1, although I’m running the git
version of course, but that went fine (through slackbuild.pl of course).

Well, that’s enough updates for today. Time for some coding on slackbuild I think

To allow Rewrite stuff in the .htaccess file, put ‘FileInfo’ and ‘FollowSymlinks’ (or SymLinksifOwnerMatch) in AllowOverride.

(of course putting the rewrite stuff in the vhost config is faster than the .htaccess stuff, but who cares)