Skip to navigation | Skip to content
WordPress has famously low-level basic server requirements. However, most projects I deploy—because of plugins I rely on and other aspects—usually need a little more for “ideal” hosting.
Someone else used to maintain a really good “ideal” WP requirements page, but it seems to have vanished from their site. I thought I’d start my own, for my reference, to point potential clients to, and maybe of use to others.
I just had to come up with a quick bit of .htaccess code to very basically protect PDFs on a client’s site from being downloaded by people who aren’t logged into WordPress. I thought I’d share the code, specifically to highlight the way to detect if someone’s logged into WP through Apache’s directives.
mod_rewrite is a notoriously fiendish chunk of software, almost legendarily so among web developers. I’ve got by with snippets in my .htaccess file, stuff that makes sure there’s no “www” in the URL, and managing holding pages. I absorbed a lot of how it works, but I couldn’t readily construct my own rewrites.
Until tonight.
I was forced to solve a situation involving a WordPress site which had some legacy flat HTML content. Way back when, I hacked it to use .html suffixes on the WP URLs, so we didn’t lose any search engine juice for the old URLs. This necessitated changing core WP code—always a bad idea—and thus blocked any automatic WP upgrade process. Which is a pain.
So, I’ve removed the .html hack, and tried to pull flat HTML content in for the old stuff, under the guise of smooth new .html-free URLs.
I recently got an Asus Eee PC 1000H. For writing, travel, and learning Linux. I wanted to get Ubuntu working on it (a friend recommended it), the Apache/MySQL/PHP trinity (essential for work), and ColdFusion (not essential for work these days, but a few little apps I’ve written—for use locally—use CF).
There’s been a whole series of hoops to jump through. I’m no tech novice, but Windows and occasional Mac use has been my staple thus far. Of course you can’t do much in web development without knowing a bit of Linux at least; still, wrangling with various desktop issues can be a chore.
The web, or Google (if there’s a difference) is your friend. Finding a comprehensive tutorial that covers your precise situation is rare if not impossible; you need that familiar net skill of cobbling together varying perspectives and bits of advice into something that works for you. That said, I’ll point to this ACME Guide up-front as a fantastic source of information on getting web development stuff going.
I also picked up the O’Reilly Linux Pocket Guide. It’s a good little intro to the Linux environment as well as a useful reference point.
Anyway, here’s my summary of what I’ve learned. Hope it’s useful for you! (As ever, this information is used at your own risk. I can’t support you if stuff goes wrong—but do let me know if you know for sure I’ve, for example, mis-typed commands!)
NOTE: I’ll leave the information here for reference as it’ll probably still be useful to some. But for anyone using WordPress who wants a convenient way of putting up a holding page without confusing search bots and without blocking yourself from using the site while it’s “down”, I’ve just found the very neat Maintenance Mode plugin. Seems to work like a treat. 14/2/08
Ever wanted to have a system in place that allows you to easily “switch on” a holding page for the whole of your site for when you need to do some maintenance? Well, that’s relatively easy to do; but what about bots? Even if you’re only down for 10 minutes, what if your luck is such that Googlebot makes its random rounds at precisely that time? Depending on how you’re holding page works, it might register a load of “404 – Not Found” errors, or replace your indexed content with your holding page… Who knows? Not I.
I’m building this site with WordPress 2.1, which has some great new features (such as post auto-saving and draft pages). I’ve heard there are significant teething problems with upgrading from a previous version – for instance, the new draft pages system means that pages are now flagged with the database field post_type being used instead of the post_status field being set to static. Much more logical, but it may break some of your page-related plugins.
Anyway, for new installs it seems like the way to go, with a few caveats. One involves the potent but potentially tricksy .htaccess file for Apache server configuration settings. If, like me, you prefer to maintain control over the file yourself instead of having WordPress automatically generate it, you might run into problems when 2.1 tries to “fix” it.
If you suddenly get a HTTP 500 error (Internal Server Error), it’s often due to slip-ups in .htaccess. If you’re using WordPress 2.1 and get this, download .htaccess and see if WP hasn’t slipped its mod_rewrite rules in at the end. If you’ve adapted the default mod_rewrite code, WP 2.1 thinks it’s not there at all, and slips the default in at the end again.
I’ve not found a way to stop WP doing this – there was a suggestion to change the write permissions on the file to stop WP accessing it, but you’d have to switch them back every time you re-uploaded the file. Pain in the arse. I’ve just reverted to keeping the default WP mod_rewrite at the end of the file, exactly as WP intends.
Welcome! I build websites - mostly based on the brilliant, free & open 