How can I lock down an old wordpress install I don’t intend to update?

The question:

I am starting a new wordpress blog, and no longer updating an old one.
The old one still gets 400-500 hits a day, so I would like to keep it up for archival purposes, as people still link to its posts.
Obviously there is the problem that wordpress and plugins will be updated, and I have no desire to maintain it.
How can I lock the installation of wordpress down so I don’t need to maintain it?
I have seen someone suggest making a static version, which sounds like alot of work. A more reasonable solution I thought of was to disable write access to the database at the database user level. I’m fine with disabling comments from now on.

Feel free to share any thoughts or comments on this.

Thanks in advance.

The Solutions:

Below are the methods you can try. The first solution is probably the best. Try others if the first one doesn’t work. Senior developers aren’t just copying/pasting – they read the methods carefully & apply them wisely to each case.

Method 1

With a dynamic CMS like WordPress, there is no real way to “lock it down.” As the web evolves, formerly unknown security holes are discovered and patched in new versions. In reality, unless you’re always running the latest version of WordPress (currently 3.0.4), your site is in some way vulnerable. If you don’t intend to ever update it again, creating a static version is the best and safest option – not “crazy talk.

A strong possibility is to use a caching plug-in and set the cache to never expire. The plug-in will automatically create static versions of your pages as they’re needed. Your links will still work, and people will be directed to the static HTML versions of each post and page rather than the dynamic, database generated ones.

By generating a static version, you won’t need to worry about database updates, WordPress updates, plug-in upgrades, or new versions of themes. It becomes maintenance-free, but is also “frozen” in the sense that comments won’t work and you can’t add new content … which is probably fine in this case.

Another alternative is to keep things dynamic and outsource the task of updating your site. Have someone like host the site and point all of your links to that version of the site. The hosted service (particularly that one) will always have the latest security patches without any intervention from you.

Method 2

Howdy! I think your question is really of use as it represents a very valid and clear scenario.

The scope of your question is important:

  1. disabled write access to the database.
  2. I’m fine with disabling comments from now on.

The second point is not that important for my answer, as you could understand user content as “your” content probably.

As long as you are using mod_rewrite to display you blog (Pretty Permalinks is the catch-phrase in the wordpress world) you’ve got the power to do a quick finishing move while retaining your blog in full.

What I suggest is to make a static copy of your blog by using a very fundamental webhosting/php/static technique. It’s basically making use of the benefit of abstraction through webservers/HTTP: The Browser does not care if you’re running a webapplication any longer (here: wordpress blog) or the webserver is serving static pages only.

WordPress has this already somehow built in. It’s all working on the server level in httpd.conf or .htaccess:

The webserver checks if the file exists. If so, it will return the static file. If not, it will call wordpress instead. If you compare this to the standard setting of wordpress .htaccess for pretty permalinks:

RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]

You can see that it’s checked for an inexisting file and directory first. Now imagine that index.php would not just return the requested locations content but would while doing so, save the content as a file in the file-system, of which the previous checks would have returned TRUE to, so to serving the static file instead of calling the webapplicaiton.

So the magic is already in. Once existing, this is a “cache” that never expires until you delete the static files.

This principle by the way is a very old one. It’s known to be the “PHP way” by some. The first request generates the full page, the second request won’t probably even no longer need mod_rewrite. It’s nothing I’ve invented either, oh dude I loved this document by Ralf S. Engelschall dating back to December 1997, look for On-the-fly Content-Regeneration:

On-the-fly Content-Regeneration


Here comes a really esoteric feature: Dynamically generated but statically served pages, i.e. pages should be delivered as pure static pages (read from the filesystem and just passed through), but they have to be generated dynamically by the webserver if missing. This way you can have CGI-generated pages which are statically served unless one (or a cronjob) removes the static contents. Then the contents gets refreshed.


This is done via the following ruleset:

 RewriteCond %{REQUEST_FILENAME}   !-s
 RewriteRule ^page.html$          page.cgi   [T=application/x-httpd-cgi,L]

Here a request to page.html leads to a internal run of a corresponding page.cgi if
page.html is still missing or has filesize null. The trick here is that page.cgi is a usual CGI script which (additionally to its STDOUT) writes its output to the file page.html. Once it was run, the server sends out the data of page.html. When the webmaster wants to force a refresh the contents, he just removes page.html (usually done by a cronjob).

(quoted from the linked document, just search for it)

So basically with this approach you can solve your problem. If you get 100% URL coverage and therefore all your documents generated, you can even shut down the mysqldb. This is something I would aim for: A full, static version of your website. This makes it even very easy to migrate to an “archive” server, so some server that is just serving and job done.

How to freeze to static with WordPress?

Here is a little bit of code that is basically injecting “output to disc” into any PHP based application. Feel free to use it for whatever you see fit:

class htmlCached {
    static $instance;

    public static function bootstrap() {
        $file = $_SERVER['REQUEST_URI'];
        if ( '/' == substr($file, -1)) {
            $file .= 'index.html';
        $self = dirname($_SERVER['PHP_SELF']).'/';

        if ($self != substr($file, 0, strlen($self))) {

        $local = substr($file, strlen($self));

        // var_dump($file, $local, $self, $_SERVER);
        self::$instance = new htmlCached($local);

    private $_file = '';
    public function __construct($file) {
        $this->_file = $file;
        ob_start(array($this, 'callback'));
    public function callback($buffer) {
        $file = $this->_file;
        file_put_contents($file, $buffer);
        chmod($file, 0644);  // octal; correct value of mode
        return $buffer;

You might need this to adopt for wordpress a bit (as this is not from a wordpress install), but basically it has all you need:

  1. wp-config.php is a very first entry point, you can hack index.php for a more direct approach as well. Inject the class definition into index.php. Index.php is the so called front-end-controller for most anything worpdress.
  2. add a htmlCached::bootstrap(); in front. this will do the job. The job is the following:
    1. htmlCached will enable output buffering with a callback routine.
    2. the application runs as normal
    3. htmlCached sees when the application shuts down (that is, when wordpress has done everything, it’s a pretty stupid application, so you can do these tricks)
    4. On shutdown, htmlCached saves the server response to disk (next to sending it to the browser).
    5. On the next request, apache will serve the static contents.

So this is easy for the moment. What you need to double check with wordpress are CSS files, JS scripts and probably images / files (multisite!).

If you don’t run multisite nor complicated caching plugins, you might be already good to go.

Check which files / URLS have been requested over the lifetime of your site. Build a list, request all files once. Job done.

Then delete all .php files.

Kill the database.

You just freezed your site.

If your Permalink structure did not end to .html for all links, I would suggest to save all files as .html (.html added to the request) and then configure the .htaccess file accordingly. So to check for REQUEST-URL + .html for -f and if it does not exists, to run the htmlCached WP instance (which adds .html to the filename as well, if that’s not already in my example code).

Happy implementing. Backup first (as usual). For migration stuff, you can make your database read-only by setting the according rights for the MySQL user. I would do that in between, so you don’t need to hurry to implement this. E.g. finding out about all URLs that have been requested since 10 years or so can be challeging and might take some time.

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Comment