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:
- disabled write access to the database.
- 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
Description:
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.
Solution:
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))) {
return;
}
$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:
- 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.
- add a
htmlCached::bootstrap(); in front. this will do the job. The job is the following:
- htmlCached will enable output buffering with a callback routine.
- the application runs as normal
- 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)
- On shutdown, htmlCached saves the server response to disk (next to sending it to the browser).
- 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.
