[wp-hackers] WP Development & Production Sites

Peter van der Meij peter at pjvdm.nl
Fri Nov 26 08:37:18 UTC 2010


Everyone keeps talking about a db dump...

My problem with this solution is that is you always have to find/replace all
the url instances in the db. 
Because of the slightly stupid way WordPress stores it url's 

That's also why a db replication doesn't work!

Met vriendelijke groet,

Peter van der Meij
e: peter at pjvdm.nl
m: +316 302 716 98

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com
[mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Ryan Duff
Sent: donderdag 25 november 2010 2:48
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] WP Development & Production Sites

WPEngine has a "staging" environment set up for their clients. Don't ask me
how it works but its possible.

http://wpengine.com/features/

Ryan


On 11/24/10 4:50 PM, Vid Luther wrote:
> Jacob,
>
> On Nov 24, 2010, at 3:36 PM, Jacob Santos wrote:
>>
>> The point of Development and Production is to keep them separate and 
>> if that is not the case, then you are doing something wrong. The 
>> point of development is testing. Once that is achieved, then you move 
>> over to production.
>>
>
>
> I think the thing most people want is a simple way to develop/test some
settings of a plugin and then be able to migrate those over to production,
easily.
>
> Sometimes, you want to take a live site and test a plugin with it, so you
want the latest data to go from live to staging/dev.
> This can and should be done with a simple export ->  import, but 
> individual plugin settings aren't exported, and sometimes a plugin/widget
that's on the live site is not exported either.
>
> A full blown SQL dump of prod ->  stage is the next option, which works,
but by the time you get done testing your new plugin/widget/theme settings
you have new comments on the blog, you have new posts on the blog, and doing
another db dump ->  prod is not the ideal situation.
>
> People are just trying to find one simple solution to export those
settings, as opposed to every plugin/theme having it's own export option.
perhaps we just do a mysqldump of the options table? I dunno.
>
>
>
>
>> Jacob Santos
>>
>> On Mon, Nov 22, 2010 at 7:35 PM, William Davis<will.davis at gmail.com>
wrote:
>>
>>> Also, SQL dumps are a pain in the ass. Why have WP-import/export at all?
>>>
>>>
>>> On Nov 22, 2010, at 8:33 PM, Ryan Bilesky wrote:
>>>
>>> that would get everything, even settings from plugins the user may 
>>> no
>>>> longer
>>>> have installed.
>>>>
>>>> On Mon, Nov 22, 2010 at 5:28 PM, Andrew Nacin<wp at andrewnacin.com>
wrote:
>>>>
>>>> On Mon, Nov 22, 2010 at 7:41 PM, Ryan Bilesky<rbilesky at gmail.com>
>>>>> wrote:
>>>>>
>>>>> what if there was a plugin that could backup the settings you've 
>>>>> set
>>>>>>
>>>>> from
>>>>>
>>>>>> one site (say a dev site) and import them to another site (say 
>>>>>> your production site).  Now I am not aware of any way currently 
>>>>>> to where a plugin can know what settings another plugin makes, 
>>>>>> but you could have a txt
>>>>>>
>>>>> file
>>>>>
>>>>>> with a list of option names like
>>>>>>
>>>>>> setting1
>>>>>> setting2
>>>>>> ect
>>>>>>
>>>>>> Go though the db and get_option for each of those, save it out to 
>>>>>> a file like
>>>>>>
>>>>>> setting1:value1
>>>>>> setting2:value2
>>>>>> ect
>>>>>>
>>>>>> Import that generated file into the production site that would 
>>>>>> step
>>>>>>
>>>>> though
>>>>>
>>>>>> that file line by line and update_option to move all settings 
>>>>>> from one
>>>>>>
>>>>> site
>>>>>
>>>>>> to another.
>>>>>>
>>>>>
>>>>>
>>>>> I believe they call that an SQL dump.

_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers



More information about the wp-hackers mailing list