Tue Apr 20 23:23:57 UTC 2010
to cause more issues, for more people, than relative URLs would, and as
such, relative URLs gets my backing.=20
I also hate that going from DEV to LIVE requires DB changes, it's not
smooth or fluid by any means (The HOSTS file trick obviously won't work
for Enterprise style setups, with separate DEV, STAGING and PRODUCTION,
We've had this discussion on this list many times before of course....
From: wp-hackers-bounces at lists.automattic.com
[mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Otto
Sent: 26 November 2010 21:58
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] WP Development & Production Sites
On Fri, Nov 26, 2010 at 2:21 PM, scribu <mail at scribu.net> wrote:
>> Thus breaking all your RSS feeds?
>> Your content is not consumed solely through your website, you know.
> I never understood why feeds are brought up as an argument against
> The content as well as any other URL related attributes can be
> as well for both HTML and RSS.
If you're going to filter everything, then you're adding a lot of
processing time and overhead, aren't you?
Look, I don't like shortcodes as is. As I see it, the content in the
database should stand alone, without anything that requires
post-processing in order to make it have a format viewable by the
reader. I should be able to just splat the thing out there and still
have it readable and proper. The content should be capable of being
displayed in any medium and still be at least interpretable, if not
However, we must have markup of some kind, because content often does
have formatting. HTML is a relatively good way to do markup, because
it can be parsed by whole lots of different things as is, without any
need to do any server-side processing.
So I see the need for shortcodes, in that they allow plugins to
arbitrarily modify content in specific user-specified places. I avoid
them as much as possible, but they serve a purpose. However, they do
affect that basic purity of the content. Now you have content that is
no longer independent of the site itself. This is a bad thing, it
breaks that vague separation of presentation and content barrier.
Regarding links, relative links have the same problem. They're
relative to the presentation. They're relative to the location.
They're not fixed. They make things harder when you change the format
of the site because they change along with it. Your content now has a
dependency based on where the content is being viewed.
Absolute links don't have this problem. They're absolute. They're not
supposed to change. If you have to change them, then you're either
doing some kind of extreme re-working of the whole site, or you're
doing something wrong.
So that's my basic thought process here. You're corrupting your
content by making it incapable of standing alone, and this sets you up
for problems down the road. And if you're frequently having to do
things like change your links to fit with content you're moving from
site to site, then you're doing the whole thing wrong in the first
If you want to setup a local installation and have real content on
there, edit the HOSTS file. Make yoursite.com appear to be at
127.0.0.1. Then you can have your test site use the actual real URLs.
When you move the content, it will still have those actual real URLs.
If editing HOSTS files is too onerous for you, use a program to
automate it, so you can switch between a dev hosts file and a live one
by clicking a button. There's several programs that can do this out
I use this exact process for making changes to wordpress.org. We have
sandboxes for the whole site. I can make any changes I like on my
sandbox, and when I go to wordpress.org in my browser, it goes to my
sandbox instead. Nobody sees my changes but me, because I have my
hosts file pointing wordpress.org to my sandbox. When I want to switch
it back to live, I click a button, hit refresh, and now I'm on live.
Easy. Works great.
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers