[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

[Dion Hulse (dd32)]

So I've remained quiet on this issue so far, but there's 2 separate things
being battled against here:
 1. Outputting relative links
 2. Transferring between multiple hosts using different domains.

Now, #1 is what people are suggesting is the "best" way to combat #2, that
being said, It's not the only method (Infact, there will be at least 4
different ways, My way, Your way, John Smith's way, and something which
no-one has yet thought of) and may not be the best or correct option.

To solve problem #2 above, most of us have been using such scripts which do
search/replace, the dumb scripts have always had issues with serialised
data, the smarter ones simple replace s:x:domain; with s:xx:longerdomain;
first, which works around the serialised issues.  That has "solved" the
issues related to transferring installs between domains.. But when it's not
a scripted migration, that type of search/replace is a somewhat cumbersome
process for some, and deemed too complex.

WordPress itself avoids storing the URL in the database *except* when used
within the post content, and the site/home url options obviously, AFAIK,
the domain should not be stored within the options table at all by
WordPress itself. So much so, that some images receive a url dynamically
generated upon post save and/or display (captions) so that value in the
database is irrelevant to the page display.

So now, we have 2 solutions:
 1. Output Relative links
 2. Search/Replace upon migration

Now lets look at the actual results with relative links, and what they give:
 * Url's become domainless
 * Url's still contain the path

This is a benefit to those who use dev.site.com, and site.com.
but it doesn't help those that use http://localhost/client-site and
client-site.com/  infact, if anything, it makes it harder.
If Relative url's are stored, now they're replacing /client-site/ with /..
Which at first doesn't seem like a huge problem, but then, when you broaden
your mind, you realise it's a much less strict search and replace, it'll
cause conflicts in more locations when the dev path is a common string..
which can be even worse when the "client-site" slug is used in the sites
content for more than just the url.

Relative links solve one problem, in one way, while having a knock on
effect to others, This is why I don't expect to see relative paths, such as
those being floated here, become the defacto storage for url's. Absolute
url's are just that, It's absolute as to their meaning, and easy to process.

So, moving on, Someone mentioned using a domain the same length, This
simplifies the search and replace methods, as you don't need to worry about
the serialised data.. but it's yet another work around.

We now have 3 different methods to solve the problem.  3 different methods
which will work for 3 different people.. but might not work for 3 others.

Now, I personally have never had a problem with the Search and replace
method, as the only location I ever have absolute url's to the current
site, is within the post content itself. no serialised data to deal with,
etc.

*So, a question*: Those of you who battle this out, where are the url's
that you have to alter, and that cause you so much apparent grief?
Is it Serialised data? (If so: Why is there a URL being stored anyway?
WordPress generates url's dynamically, and so should plugins/themes,
They're doing it wrong if they're storing a url in most cases..)
Is it Post Content?
Is it somewhere completely different?
Is it the WordPress Dynamically generated URL's on each page?


If I was dealing with a dev->staging->production setup, I know the exact
configuration I would have: ( NOTE: I'm NOT suggesting this for a simple
site-to-site transfer)
 * wp-config.php which dynamically loads wp-{$domaincontext}-config.php,
Allows me to have different Database details and WP_DEBUG etc based on the
context of the site being loaded
 * WP_SITEURL and WP_HOMEURL defined in above config files, You want to
specify what site is being loaded after all.
 * If multisite, there'll be a sunrise.php file in there to normalise the
hostname into the production hostnames to allow for correct domain lookup,
this shouldn't affect the links output by WordPress, rather just the domain
query process (Note: I haven't had to do this part, I know it's possible,
but I've never done it myself)
 * I'd be storing production url's in the database content, no mucking
around:
    * On insert on dev|staging: replace staging|dev url's with production
    * On retrieval on dev|staging: Replace production url's with
staging|dev depending on context
    * On insert on production: Nothing.
    * On retrieval on production: Nothing.
   This leaves the extra processing to take place on non-live servers,
somewhere where you can afford lower performance.

But there's a 2nd option as well, Instead of altering url's like that,
replace the urls on dev|staging|production:
 * On Insert: replace WP_SITEURL with [url] (a shortcode, remembering that
the constant is dynamically set depending on the current context)
 * On retrieval: Do nothing (Well, in the admin, you might need to apply
the shortcode manually for the editor..)
 * On Display: [url] shortcode is expanded to site_url()

That has the obvious downside that the shortcode needs to be processed on
the production server, on every page load, for every url in a post,
Congratulations, You've just solved a problem by including the production
server in the equation.. Whereas, with the previous suggestion, you're
offloading all extra processing to the development servers - where the
problem you're attempting to solve actually is.

*tl;dr:* Don't generalise problems, one solution will not fit the bill for
everyone, I've just gone over 5 different methods for site transfer, 2 of
which are specific to a staging environment, which will not work for
general site transfers, but vice versa, a general site transfer process is
also not aimed at a staging environment, they're 2 very different processes
which require different solutions.

I'm not trying to restart an opinion war, rather, I'm trying to gather
information, on why this specific implementation of relative url's is the
bee's knee's golden bullet which is going to solve every migration problem
people have, when In my mind, it solves a tiny fraction of the problem, for
a certain server environment, whilst leaving many others out in the cold..
I also didn't touch on SSL-ness of the request deliberately, things such as
the Google Pagespeed apache extension can kick in here, you can use
mod_substitution, or you can use extra processing power on your production
servers to replace http://domain with https://domain in your post content
before your caching layer kicks in (which, does support ssl/non-ssl caching
buckets right?)

On 30 October 2011 22:04, Mike Little <wordpress at zed1.com> wrote:

> On Sat, Oct 29, 2011 at 20:48, Rafael Ehlers <rafaehlers at gmail.com> wrote:
>
> > Mike Little wrote: "(with a character count exactly the same length of
> > the live domain)"
> >
> > Aw c'mon, no offense to Mike, but that's just ridiculous, please,
> > seriously, just use this script:
> >
> >
> >
> http://www.interconnectit.com/wp-content/uploads/2011/05/searchreplacedb2.zip
> >
> > It's an easy process:
> >
> > 1. Change DB Connection in wp-config.php
> > 2. Upload all WP files from local to production (and searchreplacedb.php
> to
> > root file of wp)
> > 3. Export DB from local to production
> > 4. Run searchreplacedb.php
> > 5. Log in to WordPress -> Settings -> Save Permalinks (to regenerate)
> > 6. Profit!!!
> >
> >
> > Seriously, use that script!
> >
> >
> Seriously, you still have more steps than me. I do this day in and day out,
> and it's never a problem. Such things are bread and butter to me.
>
> Besides, when that script first came out it wasn't good enough, it didn't
> cope with all situations (e.g. nested arrays). I'm sure it's lots better
> now (I've worked with and for the author on a number of occasions), but
> I've not bothered to look into it. I had a working solution before it came
> a long and a still working solution now.
> The other thing I don't like is the giant security hole that opens for the
> length of time that script exists on your server (or maybe that's fixed
> to).
>
>
> Mike
> --
> Mike Little
> http://zed1.com/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>