Settling the WordPress Absolute vs Relative URL Debate

WordPress is somewhat notorious for using absolute URLs in its linking to images and other posts within content. Many have argued for both sides.

It’s quite simple for me: relative URLs are easier for development, absolute URLs are smarter for live websites.

There’s a compromise to be had.

WordPress should add these shortcodes to core:

  • [home_url]
  • [uploads_directory_url]

This enables the user and the WordPress editor to insert links to other pages and media on the site while maintaining its given site domain and path. Developers would no longer have to find and replace all instances of the home URL when importing a local database to another environment.

When linking to another page on the site, WordPress could insert [home_url]?p=203, maintaining a lifetime of environment changes and domain moves without broken URLs.

Or, when linking to an image: [uploads_directory_url]/2013/01/example.jpg. Actually, I think linking to media needs to be completely rethought (i.e. [media id="100"] would render whatever image path was associated with that media ID. This would allow you to update an image in the media library and have the image update everywhere it exists on your site).

Update: I wrote a proof of concept plugin for media being inserted into posts with shortcodes to ensure portability.

We all started somewhere, right?

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.

1

2

3

4

5

6

7

Theme revisions and WordPress cache busting

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

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.

WordPress network in multiple environments with a single database

Problem

I needed a way in my multisite setup to have multiple environments that shared the same database, but used different domains.

  • server1.example.com
  • server2.example.com
  • example.com

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

Solution

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.

Revisiting my development environment

Below is a graphical representation of what I’m proposing as a new development process/environment for my larger WordPress sites. I want your feedback.

This doesn’t include all the details. For instance, WordPress configuration files have to be customized for each server, database usernames should be specific to each environment, etc. But should this flow work?

WordPress Development Process