His question is the other way around: Live to dev.   Nancy  Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

________________________________ From: Earnie Boyd

This is a FAQ.  Try a google search for "drupal dev to live update" and you'll find many hits.  If that doesn't answer your question come back and ask again.

On Wed, Jan 25, 2012 at 5:54 PM, Ms. Nancy Wichmann <nan_wich@bellsouth.net> wrote:

His question is the other way around: Live to dev.

And back to live. -- Earnie -- https://sites.google.com/site/earnieboyd

I believe he's mostly concerned with new content and users getting pushed down to his dev instance. Option D: Use the Feeds module to pull down the new / modified stuff. I'm not sure how you get files that are not fielded.   Nancy  Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

________________________________ From: Benj Fredrick

this is an age-old drupal question, and there are many different solutions. The main problem is that site configuration is stored in the db alongside site content. 

Option A:Use modules like Features and Strongarm Option B:Use something like Backup and Migrate to only overwrite certain tables. Option C:Use Pantheon hosting and their slick UI tools. ;)

On Wed, Jan 25, 2012 at 2:12 PM, prothero wrote:

Hi. I am pondering the best way to modify and test my site without corrupting my live site. Currently, I ftp all of the files and db tables to my local computer and use MAMP to run my development site. But, since my live site is changing every day from users creating accounts, etc, how should I set this up so that when I upload my development site to the live one, it stays current?

...

Amazing and thanks for that though I must admit I had trouble keeping at all the info being thrown on to the screen. tony On Thu, Jan 26, 2012 at 12:19 AM, Sohodojo Jim <salmons@sohodojo.com> wrote:

Benj,

Assuming that you are keeping your codebases pretty current local and remote and it is mostly a database synching challenge, here is a screencast that shows a technique that I have used for years to work with local-sandbox and public-remote:

http://www.sohodojo.biz/sqlyog

I use a slick app called SQLyog -- there is a free version and a paid version. I've had the paid version for years and can't live without it. I believe the free/community version can do the technique I show in the webcast but I am not totally sure as I don't use that version.

I know lots of folks want a free tool and/or drush to do similar things. I just find that the multi-copy tactic I use as shown in the webcast has served me well, especially when you want to roll back and forth both within your local dev box and your public server.

BTW, this webcast was done as an entry for a SQLyog customer testimonial contest. I didn't win the iPad 2 grand prize -- they tended toward more highly rating the testimonials from database admins -- but it was fun putting this presentation together.

Hope it gives you some ideas about how to organize your daily routine.

--Sohodojo Jim--

From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Ms. Nancy Wichmann Sent: Wednesday, January 25, 2012 9:06 PM To: support@drupal.org Subject: Re: [support] Keeping dev and live site in sync

I believe he's mostly concerned with new content and users getting pushed down to his dev instance.

Option D: Use the Feeds module to pull down the new / modified stuff.

I'm not sure how you get files that are not fielded.

Nancy

Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

________________________________________ From: Benj Fredrick

this is an age-old drupal question, and there are many different solutions. The main problem is that site configuration is stored in the db alongside site content.

Option A:Use modules like Features and Strongarm Option B:Use something like Backup and Migrate to only overwrite certain tables. Option C:Use Pantheon hosting and their slick UI tools. ;)

On Wed, Jan 25, 2012 at 2:12 PM, prothero wrote: Hi. I am pondering the best way to modify and test my site without corrupting my live site. Currently, I ftp all of the files and db tables to my local computer and use MAMP to run my development site. But, since my live site is changing every day from users creating accounts, etc, how should I set this up so that when I upload my development site to the live one, it stays current?

-- [ Drupal support list | http://lists.drupal.org/ ]

-- *Anthony Stefan Maciejowski* *tony maciejowski** | analyst/programmer | websites | www.tony-mac.com<t_maciejowski@hotmail.com> * *Twitter: anntosh* | *Cell: 323.899.6206* | *Linked-In:* *Anthony Maciejowski* “Hope is not the conviction that something will turn out well, but the certainty that something makes sense, regardless of how it turns out.” --- Vaclav Havel

Tony,

...

Amazing and thanks for that though I must admit I had trouble keeping at all the info being thrown on to the screen.

[In reference to the webcast mentioned in a former note and found here: http://www.sohodojo.biz/sqlyog]... Thanks back for the comment. :-) The contest had a "soft limit" of around 5 minutes for the testimonials and most were "throw-away" quickie-comments folks did to just get in the contest drawing. I actually did want to do a real testimonial as SQLyog is truly one of the must-have apps that I use to make my development life more efficient and organized. Even with significant time-compression (fast motion) on the "live action" segments and diligent editing (Camtasia is _amazing_ and fun), I was only able to get my entry down to just over seven minutes. So, yes, there is a bit of "drinking from a fire-hose" dimension to that webcast. The pause and rewind button can be your friend in this case... :-) Perhaps, now that the contest is over, I'll do a "Director's Cut" version to provide a more relaxed presentation. And finally, so that folks don't think I am trying to push an agenda about using SQLyog which is a commercial app (although they do kindly provide a more-limited free version)... The strategy and tactics I describe in my webcast are _ideas_ and recommendations about how one might organize and manage a daily workflow with a dev/live Drupal site. While some of the fine-grained tactics might be more conveniently done with SQLyog, the 'big ideas' and most of the step-wise tactics are not dependent on that application. You can take these ideas and apply them with any toolset you might like. (Hint/nudge-nudge-wink-wink: I'm thinking that a drush script along these lines might be an awesome addition to our community if somebody wants to scratch that itch based on my webcast as a 'live use case' spec.) --Sohodojo Jim--

[Bill Prothero wrote:]

Nice video. I was trying to follow your presentation and found it a bit confusing. You talked about your "Sandbox" and I wondered what db was the sandbox db. Also, when you said you had a "Mirror" site, was this just a copy of the live site (and its db) or was it some kind of automatic mirroring system that kept them in sync?

[Jim replies:] By "sandbox" I just mean the version/copy of my public site that is running locally on my development machine (which is also my Wamp-based server -- I use Wamp because it has a scriptable config/mgt system that lets me configure on-the-fly virtually any combination of PHP/MySQL/Apache that I might need based on needing consistency with various project-based configs -- but that is another story (needing its own webcast, actually). On my development machine, the database that runs my local copy of the site is always named the same as the database that runs the live site. It probably isn't clear as you say -- but is obvious to me as I evolved this workflow and all this is automatic to me -- and that is, the X_dev and X_rem databases are "no touch"/"no run" copies of the database that, in effect, are pristine copies (never accessed other than for whole-database copying) of the database that support all the roll back and forth that are often a part of daily development. And while I didn't make this explicit, another good feature of this approach is that by definition you will have a very active and flexible set of back-up copies of your database, including your remote live database. Although it has been many years, I am pretty sure that one of the original motivations for my thinking this through and coming up with this routine was the number of times that my "unforced human errors" (you are too tired, too much in a hurry, or just not concentrating enough) have caused me more "gotcha" moments than any actual (hardware or data transfer, etc.) problems.

Thanks for the info. I use Navicat, which I like and seems to have much of the same functionality as SQLyog.

[Jim replies:] I used Navicat for a while, too, but let its maintenance/upgrade contract lapse long ago as I narrowed my personal choices for which tools to use. In that regard, the _two_ most must-have (and these are Windows-based) database commercial apps that I rely on daily are SQLyog -- it's pure "lean and clean" and would be the keeper if I had to choose only one -- and EMS' SQL Manager for MySQL -- it has truly amazing 'bells and whistles' features that I use for complex query development, ad hoc reporting, and other database prototyping, etc. Regardless of the specific tool of choice, as I mentioned, the general strategy and tactics can be applied in varying degrees depending on your need and interests. I hope this info helps clarify any confusion you may have. And thanks for your comments. I will use this thread of conversation to develop clarifying content to the article on Sohodojo.biz that points to the YouTube webcast. --Sohodojo Jim--

[Jim notes:] For those jumping into the middle of this on-going thread, our comments are in reference to a webcast found here: http://www.sohodojo.biz/sqlyog.

Jim: Thanks, I think I've got your procedure down. Makes sense. One thing you say in the video is that while you are developing, you are regularly updating changes to your live server. I think you mean to your -dev db, don't you? That way you don't put your ongoing work into the public server until end of day when you've got everything working.

[Jim replies:] That sounds about right... I'll have to give a closer listen and look to the video as I was under some time pressure to get it into the contest and, honestly, it was a "wing-it" (and my first Camtasia) production. More generally, your summary statement is spot on -- that the basic idea is to always grab a start-of-day copy of the database from the live server -- and this copy serves, first, as your back-up of the remote/live server and second, it is the 'seed' for your my-work-today local copy of the database. A couple things this helps you do so as not to be your own worst enemy are: 1. You have that today-fresh back-up of your live DB. 2. No matter how close together you _think_ your dev and live sites are DB-wise, don't assume. Because sure enough, there will be days where that assumption is not as good as you think and you end up in an "Oops!" moment. 3. By working against the latest version of your live data, you _significantly_ reduce the delta between your development version and your live version. This is a _big_ deal when you do end-of-day re-synchronization. You will be looking at a limited set of table/record differences that are limited to only several hours of activity. Any DB copy older than that and you can lose yourself in the mucky-muck of trying to figure out record-wise diffs as either 'important', 'not sure', 'toss-able'.

Just a suggestion: The diagrams with arrows and sequence numbers are very helpful. It would be very helpful, in your explanation if you'd give a quick overview. Like, for example: "What I do is make changes working with a WAMP local version where the db is the same name as the public version. Then, I keep 2 backups so that I have a recent public version that isn't touched, and a version that is saved from the previous day's work."

[Jim replies:] Good idea. In fact, since this was a PowerPoint slide show that I ran concurrently with the 'live action' stuff for the webcast capture, I can easily do static slide images and use them for a text-based annotation of the webcast.

I've done a bunch of tutorial work for students, and it helps to let them know the overall structure and philosophy before giving the details. That way any ambiguity might make sense to them.

[Jim replies:] Agreed. There is nothing like foisting some material on the uninitiated to reveal all the assumptions and holes in a presentation... Like, for a trivial-but-could-cause-an-international-incident example, I noticed this morning that I misspelled "Guinness" (as in Stout) in one of the thought bubble 'cheeky annotations' that I threw in -- I was not literally but figuratively drunk with my rapid learning curve of learning and using Camtasia features! :-)

Thanks for the video.

[Jim replies:] You are welcome! Glad it was useful to you.

Just wanted to through my two cents in: That was a fantastic look into one approach for sure. Thanks for sharing. I agree it would be a nice attempt to get a drush'ed version of this, some how, but even if you don't use SQLyog (or anything else) the set up that you had was interesting as well. It would be a wonderful presentation idea for an upcoming Drupal session - I know there's plenty of Drupal developers that struggle with this. Regards, Todd On Jan 26, 2012, at 1:03 PM, Sohodojo Jim wrote:

Tony,

...

...

Amazing and thanks for that though I must admit I had trouble keeping at all the info being thrown on to the screen.

[In reference to the webcast mentioned in a former note and found here: http://www.sohodojo.biz/sqlyog]... Thanks back for the comment. :-) The contest had a "soft limit" of around 5 minutes for the testimonials and most were "throw-away" quickie-comments folks did to just get in the contest drawing. I actually did want to do a real testimonial as SQLyog is truly one of the must-have apps that I use to make my development life more efficient and organized.

Even with significant time-compression (fast motion) on the "live action" segments and diligent editing (Camtasia is _amazing_ and fun), I was only able to get my entry down to just over seven minutes.

So, yes, there is a bit of "drinking from a fire-hose" dimension to that webcast. The pause and rewind button can be your friend in this case... :-) Perhaps, now that the contest is over, I'll do a "Director's Cut" version to provide a more relaxed presentation.

And finally, so that folks don't think I am trying to push an agenda about using SQLyog which is a commercial app (although they do kindly provide a more-limited free version)... The strategy and tactics I describe in my webcast are _ideas_ and recommendations about how one might organize and manage a daily workflow with a dev/live Drupal site. While some of the fine-grained tactics might be more conveniently done with SQLyog, the 'big ideas' and most of the step-wise tactics are not dependent on that application. You can take these ideas and apply them with any toolset you might like. (Hint/nudge-nudge-wink-wink: I'm thinking that a drush script along these lines might be an awesome addition to our community if somebody wants to scratch that itch based on my webcast as a 'live use case' spec.)

--Sohodojo Jim--

-- [ Drupal support list | http://lists.drupal.org/ ]

Obviously didn't read thread. On Thu, Jan 26, 2012 at 1:47 PM, Gordon Heydon <gordon@heydon.com.au> wrote:

Hi,

The easiest method to keep your local dev site up to date is to use drush http://drupal.org/project/drush

This is a command line tool, and if you set up your alias files you can sync you to dev to live in a couple of commands.

drush sql-drop drush sql-sync @site.live @site.local drush rsync @site.live:%files @site.local:%files

I do this will all my sites and makes my development so much easier.

Gordon.

On 26/01/2012, at 8:12 AM, prothero wrote:

Folks: Hi. I am pondering the best way to modify and test my site without corrupting my live site. Currently, I ftp all of the files and db tables to my local computer and use MAMP to run my development site. But, since my live site is changing every day from users creating accounts, etc, how should I set this up so that when I upload my development site to the live one, it stays current?

I'm sure this problem has been solved, but .... Regards, Bill William A. Prothero http://earthednet.org/

-- [ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

-- *Anthony Stefan Maciejowski* *tony maciejowski** | analyst/programmer | websites | www.tony-mac.com<t_maciejowski@hotmail.com> * *Twitter: anntosh* | *Cell: 323.899.6206* | *Linked-In:* *Anthony Maciejowski* “Hope is not the conviction that something will turn out well, but the certainty that something makes sense, regardless of how it turns out.” --- Vaclav Havel

More generally : From my very limited experience with the platform I have found, and would like to ask if you agree, that Drupal seems a somewhat slightly wobbly platform. It's either that or I just don't understand all of the ramifications of my doings in D. Thus a constant backing up in case something goes wrong seems advantageous. Is this why you back up several times a day? Tony On Thu, Jan 26, 2012 at 2:07 PM, Sohodojo Jim <salmons@sohodojo.com> wrote:

...

The easiest method to keep your local dev site up to date is to use

drush http://drupal.org/project/drush

...

This is a command line tool, and if you set up your alias files you

can sync you to dev to live in a couple of commands.

...

drush sql-drop drush sql-sync @site.live @site.local drush rsync @site.live:%files @site.local:%files

I do this will all my sites and makes my development so much

easier.

...

[Jim replies:] Yes, I believe that drush is the tool/means of choice for such things and these commands are very likely the 'core' of one aspect of what I was trying to describe in the webcast mentioned in this thread.

The more global aspect is "How do I organize and do the full-day workflow of creating and evolving a Drupal site?" And this gets into aspects of more than the core dev-local/remote-live sites. As I am not a drush user much less an expert, I suspect but do not know for sure how the workflow that I've described in my webcast (http://www.sohodojo.biz/sqlyog) could be fully 'drushified' from an automation standpoint to do both the local/remote stuff _and_ the iterative throughout the day development activity covered in my presentation.

I do believe, however, that what is described in the presentation -- taken as a user's spec for what would be useful -- would make for a great drush-based fully Drupal admin feature-set in a contributed module (which I would be happy to collaborate with someone to do).

--Sohodojo Jim--

-- [ Drupal support list | http://lists.drupal.org/ ]

-- *Anthony Stefan Maciejowski* *tony maciejowski** | analyst/programmer | websites | www.tony-mac.com<t_maciejowski@hotmail.com> * *Twitter: anntosh* | *Cell: 323.899.6206* | *Linked-In:* *Anthony Maciejowski* “Hope is not the conviction that something will turn out well, but the certainty that something makes sense, regardless of how it turns out.” --- Vaclav Havel