This is a humbling experience.
I was inspired to compile these because of @justintadlock‘s tweet.
I went back to oswd.org, the birthplace of my HTML debut. I built all my websites from 2002ish to 2006 in Flash (which sounds like a REALLY long time now). My introduction to HTML and CSS coincided with open source web design very nicely. Unfortunate for the Internet, though, I released seven simple HTML/CSS designs in 2006. Soon thereafter I found WordPress.
Five years later I hope I’m doing better.
Also … ugh … they’ve been downloaded a combined 79,644 times.
When you enqueue CSS or JS files WordPress will append the current WordPress version as a parameter … an attempt at cache busting.
The process by which sites or servers serve content or HTML in such a manner as to minimize or prevent browsers or proxies from serving content from their cache. This forces the user or proxy to fetch a fresh copy for each request. Among other reasons, cache busting is used to provide a more accurate count of the number of requests from users.
This type of parameter on your static resources is semi-useful. When you upgrade your version of WordPress returning visitors will be served with a fresh copy of your files. But what about all those changes you made to your style.css in between WordPress upgrades?
I use Beanstalk as my SVN repository host. Their coolest feature is automated and manual deployments. Simply commit your changes locally and watch them deploy to your staging/production server within seconds. No FTPing (and no accidents). Beanstalk puts a single file in the root directory of wherever you’re deploying to called .revision. It contains a single integer which is the latest revision that was deployed. You could manually update a file like this if you don’t use deployments.
So this function below grabs that revision number. You can then place this function in your enqueue call to replace the default WordPress version parameter with the latest SVN revision number … busting caches when they need to be.
I needed a way in my multisite setup to have multiple environments that shared the same database, but used different domains.
… each of those would point to the same database. This is easy to achieve in a standard WordPress install using
define( 'WP_HOME', 'http://server1.example.com' ); and
define( 'WP_SITEURL', 'http://server1.example.com' );.
When you add multisite to the mix it breaks.
The problem is that the
wp_blogs table defines the domains too, so I needed a way to define them in the config file.
UPDATE: A more complete solution: https://github.com/developdaly/WordPress-Skeleton
Taking @chrisguitarguy‘s advice, I used sunrise.php to intercept the host and spoof it so that WordPress uses domain I customize to load the site content.