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.
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 
