I have a pet peeve with WordPress. (Actually, I have a few, but we’ll get to the rest later.) This one, I’ll admit, is limited to those of us who develop with WordPress. In short, WordPress hard-codes domains in its database. Worse-still, some parts of WordPress (and a few plugins) save the server’s full internal filepath as part of their operations.
The average person who just installs and starts using WordPress right away won’t ever see this. It’s only when you try to move the installation to another domain name (such as if you moved your blog from “www.mysite.com” to “blog.mysite.com”), or if you move to a new service provider (and the internal file paths change) that it becomes painfully visible.
And, although I do love you WordPress, this is something that’s gotta change.
Maybe it’s years of having application transportability being drilled into me (and drilling it into others), or the fact that I develop things on temporary URLs (often patterned on “http://localhost…” or “customersite.[my company’s domain name]”, and in a few cases on some wacky TCP port that’s not 80. In any of those cases, WordPress remembers what I did.
Don’t believe me? Delve into the wp-options table in your WordPress database. You needn’t go any further than rows 1 and 37 (bearing the option_names of siteurl and home
). That URL is used by WordPress to fully qualify every page in your site. Change those values (or change your hosted domain), and the site stops working.
Now, don’t get me wrong, WordPress, I know why you do that. I just think, especially given how you’re positioning WordPress to be a more serious small-scale CMS competitor, you might want to take developer approaches into account. It would make life a little easier for those of us using WordPress as a solutions framework. And frankly, if you’re providing your own extensive instructions on how to move a blog, you might want to rethink the approach.
(And before anyone starts harping on how WordPress isn’t sufficient to the task, and I should be using a proper CMS like Drupal, Joomla, Sharepoint, Interwoven, bla bla bla, I stand by WordPress as a perfectly valid option for simple, small needs. It’s simplicity and limitations are an asset when you don’t want to worry about the larger needs of a full-featured CMS.)
But.
It doesn’t need to be this hard. Really. It’s not like this information isn’t freely available through existing PHP methods. The $_SERVER is filled with this information — it is trivial to initialise global variables using that as a base, eliminating the need to store that information in the database (and worse, hard-code it to all the URLs).
And while we’re at it, create a global variable listing the base filepath for the install. Again, this is easily handled through something as simple as dirname(__FILE__).
Am I being naive? Maybe. I’ve done enough reading to suggest that perhaps I’m missing something. But on the same note, I haven’t seen anything to suggest a concrete reason why it’s the way it is.
For now, though, I’ve found an interesting workaround (dare I suggest, “hack”?) that overrides WordPress’s database settings in the config file. A far better option, at least in my opinion, because you just sometimes can’t get to the database easily, and having to rewrite the SQL import by hand just seems so very, very wrong. I haven’t tried it yet, but my next foray into WordPress development will be putting it to the test.
I now return you to your regularly scheduled day…
