[wp-hackers] WP Development & Production Sites

[Ryan Bilesky]

I don't see what the problem is, now either I don't know any better (which
very well could be the case) or i'm not explaining this well (also very
possible).

If you have a blog at website.com/blog and one fo the paths stored in the
database for an item is website.com/blog/hello/world, store just
/hello/world in the db, store website.com/blog in a wp-config contant and
put the two together.  Move between environments just change the constant
and you're in business.

Now it's true you can just use hostfile, this is what I currently do, but
its not so clean,. especially if I have to goto my live site, I have to
remove the entry in my hostfile and restart.  Now I am sure if I looked I
could find a method that does not require a restart to switch sites, even a
virtual machine one with the modified hostfile would work.

But IMHO I think that's too much.  Why can't their be a clean simple method?


On Mon, Nov 29, 2010 at 2:18 AM, Andrew Nacin <wp at andrewnacin.com> wrote:

> 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
>  _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>