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

[Jess Planck]

After a week vacation in Orlando avoiding everything Internet. This was a great email to read. 

Yes, there are many plugins storing serialized domains. I may have done it without thinking myself. It is the biggest  stumbling block doing manual DB transfers. 

Jess

On Oct 30, 2011, at 7:25 AM, "Dion Hulse (dd32)" <wordpress at dd32.id.au> wrote:

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