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/
On Wed, Jan 25, 2012 at 4:12 PM, 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?
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.
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.
drush sql-sync and drush rsync are your friends.
On 25/01/2012 23:54, Ms. Nancy Wichmann wrote:
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.
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 http://drupal.org/project/features and Strongarmhttp://drupal.org/project/strongarmto get as much of your configuration into code as possible. This can then be versioned and pushed to new servers without touching the db.
Option B: Use something like Backup and Migratehttp://drupal.org/project/backup_migrateto only overwrite certain tables.
Option C: Use Pantheon hosting and their slick UI tools. ;)
There are probably other options I haven't thought of. Option A is my personal preference. I only pull the db backwards from live -> dev. Code obviously goes the other direction. A custom module with hook_update_Nhttp://api.drupal.org/api/drupal/developer--hooks--install.php/function/hook_update_N/6() functions can help a lot.
-Benj (benjf)
On Wed, Jan 25, 2012 at 2:12 PM, prothero prothero@geol.ucsb.edu 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
-- [ Drupal support list | http://lists.drupal.org/ ]
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?
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?
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/ ]
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--
Jim: 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?
Thanks for the info. I use Navicat, which I like and seems to have much of the same functionality as SQLyog. Bill
William A. Prothero http://earthednet.org/
On Jan 26, 2012, at 10:03 AM, 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.
[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: 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.
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."
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.
Thanks for the video. Best, Bill
William A. Prothero http://earthednet.org/
On Jan 26, 2012, at 11:05 AM, Sohodojo Jim wrote:
[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--
-- [ Drupal support list | http://lists.drupal.org/ ]
[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.
So you were happy with Camtasia? How much does it cost? And compare to Adobe's product, whose name I forgot. Sort of off topic so maybe reply privately to me. Thanks Tony
On Thu, Jan 26, 2012 at 1:42 PM, Sohodojo Jim salmons@sohodojo.com wrote:
[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:
You have that today-fresh back-up of your live DB.
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.
- 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.
-- [ Drupal support list | http://lists.drupal.org/ ]
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/ ]
One concept developed in the webcast that I am not familiar with is that of schema and data synchronization. Heretofore, I have only copied full DBs. Can you provide any links to discussion of these topics?
Thanks. -WK
On Jan 26, 2012, at 10:03 AM, 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/ ]
Hi Bill,
I actually wrote a post about how I did a big module/core update of Drupal Mill a few days ago. It includes all the steps I took and might give you some ideas on how to use the backup and Migrate module to do this. See http://www.drupalmill.com/blog/tsvenson/2012/01/quick-guide-manually-updatin... for the post.
Thomas Svenson My Blog http://www.tsvenson.com | Twitter http://www.twitter.com/tsvenson | Google+ https://plus.google.com/u/0/103859217787354138363
On 25/01/2012 22:12, 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
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/ ]
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/ ]
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--
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 usedrush http://drupal.org/project/drush
This is a command line tool, and if you set up your alias files youcan 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 mucheasier.
[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 -
Benj Fredrick -
Earnie Boyd -
Gordon Heydon -
Hans Langouche -
Ms. Nancy Wichmann -
prothero -
Sohodojo Jim -
Thomas Svenson -
Todd -
Warren Keuffel