[wp-hackers] WP Development & Production Sites

[Andrew Nacin]

So the argument comes down to this:

In the red corner, WordPress should store relative URLs. Relative to what,
I'm not sure, as WordPress is often in a subdirectory, which means we'll
always need to process the content to then add in the rest of the path. This
introduces overhead.

Keep in mind that there are two types of relative URLs, with and without the
leading slash. Both have caveats that make this impossible to properly
implement.

As Peter points out, I'm not even sure how we'd detect URLs we need to now
append to. A placeholder perhaps? What better placeholder than the domain
itself? Were there to be this implemented, it would actually decrease
portability of your content, as your content must now go through a
non-agnostic filter to actually be useful.

You can't sacrifice stability for perceived portability. Read that back.

In the blue corner, WordPress should (and does) store absolute URLs. This
requires no pre-processing of content, no overhead, no ambiguity. If you
need to relocate, it is a global find-replace in the database.

Really, what you should do, is reverse the deployment process, as Otto
suggests. Don't work off http://localhost/example/ then try to deploy to
example.com. Rather, have your install believe it is the live example.com,
then fake it to work on your staging environment. If it breaks on live, you
have a problem; it it breaks on staging, well, that's not much of a problem,
is it?

How? Personally, I edit my hosts file. Yes, this is how WP.org does it, but
no, this is not incompatible with clients (as has been suggested -- I
believe at one point I was called "out of touch" for suggesting this). Let
me explain.

Say your live install is perfect. Your staging install is local, and perhaps
you set it up so you modify your hosts file. But then you can also
creatively use the WP_SITEURL and WP_HOME constants, along with an extremely
simple output buffer, etc., to have the staging site reside at
staging.example.com. Again, the creative hacks should be on the staging
side, not the live side.

Now you have a development environment that you can link a client to, no
hosts file editing required. If an asset accidentally pulls from the live
site, then you're going to be fine. The reverse, of course, is not the case.

It's honestly trivial to properly set up a development environment that fits
the needs of both you and your client. I would just advise you that you look
at it from the production environment to the development environment, rather
than the other way around.

In the end, ultimately, what you have are thousands of developers all with
their own techniques. Over time, many of you will tune and perfect your own
techniques to match your own deployment cycles, processes, and requirements,
but notice the key words there: "your own". These techniques will likely
converge into neat categories, but it is largely a to-each-his-own issue.
This doesn't affect the vast majority of users. (And, may I add, that those
who are affected by it, generally have the added and convenient benefit of
knowing how to write code.) As Jacob just wrote, this is quite the esoteric
issue.

Regards,
Nacin