[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