HOSTING TIPS ARCHIVE
WordPress: hosting guides
Practical steps and checks for hosting, WordPress and performance. Browse a topic or use the dates to explore the experience behind the advice.
13 guides, newest work first.
Self-hosted WordPress: eight WP-CLI checks for speed and safety
Eight practical checks for WordPress on your own server: verify core files, run cron properly, find autoload bloat, lock down editing, use an object cache and update with a way back.
Running Varnish in front of a Redis page cache, without stale pages
Varnish and a Redis page cache can make WordPress very fast together, but only if they purge as one. The VCL and purge rules that keep both caches honest.
Move WordPress media to object storage and a CDN safely
How to move a site’s images to private object storage behind a CDN, rewrite the links, and only delete local copies once every file has been checked.
Caching a WordPress block means keeping more than its HTML
A block can register scripts, styles and interactive state while it renders. I need those effects back on a cache hit too.
Atomic deploys with automatic rollback for PHP and WordPress
Release folders, a symlink swap that is truly atomic, rollback when a post-deploy step fails, and the OPcache and permission traps that catch people out.
Deployment configuration needs one clear owner
Define which source owns each deployment configuration file, then test that old local copies cannot silently override an intended change.
Cron, wp-admin and the front end need to agree where temporary data lives
A site can have a persistent object cache and still repeat the same remote calls if some request types quietly keep transients only in memory.
Move large cache clears into a background queue
Clear large caches in bounded batches, keep the admin request short and show whether the job has finished.
Test the oldest PHP version your site actually runs
A clean local lint is useful, but I also check the runtime that receives the deployment.
A shared Redis service needs boundaries for clearing as well as storing
I make a site’s cache clear stay inside that site. Prefixing writes is only half of the job.
PHP in the browser and PHP in cron must agree on the cache
The same cache key is not enough. Every process that reads it has to understand the value written underneath it.
Keep a rollback route when moving PHP
I move the web server onto a separately tested PHP runtime, keep a clear route back, and check cron and background work as part of the change.
Check that scheduled WordPress jobs actually finish
Moving WordPress cron to a server timer can make the trigger more dependable. I still check the queue, the job’s progress and the result people see.
No guides match those filters. Try another topic or reset the filters.