 |
 |
||
|
 |
|
 |
|
|||||
|
|
Tuesday, September 4, 2007
Announcing Migraine, a Drupal Site Migration ToolThanks to Noosphere Networks, I’m releasing a script that helps developers of web sites built with Drupal to maintain separate development/test and production sites, pushing changes from test to production as needed. This is challenging with a stock Drupal installation. Changes to PHP code are no problem, because it lives in the filesystem and can be copied or committed to a revision-control system like Subversion. But a lot of Drupal’s configuration work take place within its web administration interface and is saved to the database, where production content such as user accounts and comments is also stored. The desire to do this frequently comes up on Drupal’s forums, and the typical workarounds have some large drawbacks (involving some combination of extended downtime on the production site, duplication of work, and the loss of content, comments, and user account changes made in the interim). This small script attempts to solve that by categorizing Drupal’s tables and moving only the right ones at the right time, while handling details such as merging sequence numbers. It also dumps Drupal’s databases to disk in a format that works well for checkin to a revision control system. This is free software, licensed under the GPL. There’s a more ambitious project called AutoPilot that aims to do this and more in the future, but its ability to merge test sites into production without losing production content isn’t available yet, and I needed something now. Be warned, though, that this is an alpha release, intended for those with familiarity with MySQL and Drupal’s table layout. If you have CCK fields, there may be some manual work required when you modify your field layout because CCK tends to change your database schema, and Migraine does not currently attempt to automate all of those changes. It will detect them and warn of the problem, however. See more information at the Migraine project page. 4 Responses to “Announcing Migraine, a Drupal Site Migration Tool”Leave a Reply |
||||||
|
|
|
||||||
|
|
|
||||||
|
|
|
||||||
 |
|
 |
|
March 19th, 2008 at 10:10 AM
This is exactly what we were looking for!
But how do we contribute back with categorized “unknown tables”? And eventually find other contributed categorizations?
I’ve got the following reported as unknown currently (Mostly from E-Commerce, OpenResort and i18n):
accommodation_availability
accommodation_bed_types
accommodation_inventory
accommodation_price
accommodation_rooms
accommodation_types
accommodation_units
business
business_ammenities
business_ammenities_node
business_ammenities_ptype
business_hotel
business_section_node_types
business_taxes
business_terms
business_terms_relation
business_terms_sections
client
client_system
content_type_business
content_type_product
content_type_recipe
content_type_story
content_type_unit
ec_address
ec_anon
ec_attribute
ec_cart
ec_coupon
ec_credit_card
ec_mail
ec_paypal
ec_product
ec_product_attribute
ec_product_base
ec_product_file
ec_product_parcel
ec_product_tangible
ec_recurring_expiration
ec_recurring_product
ec_recurring_reminder
ec_recurring_schedule
ec_region
ec_region_configuration
ec_renewal
ec_role_discount
ec_roles
ec_subproduct_pricing
ec_tax
ec_tmp
ec_transaction
ec_transaction_address
ec_transaction_coupon
ec_transaction_misc
ec_transaction_product
ec_useracc
ec_useracc_confirm
ec_variation
fckeditor_role
fckeditor_settings
i18n_blocks
i18n_blocks_i18n
i18n_node
i18n_profile_fields
i18n_variable
location_fax
location_phone
menu_per_role
recipe
recipe_ingredient
recipe_node_ingredient
recipe_unit
taxonomy_context_term
taxonomy_context_vocabulary
I’ll attempt to categorize these in the next few days and report back my suggestions for categorization.
A welcomed feature would be to be able to override the tables’ categorizations in the ini-file and let the categorization in migraine.py stand as defaults only. For instance, not everyone categorizes “menu” as configuration since it may be constantly manipulated by designated moderators on the productions site etc.
Also, this would allow easy testing of unknown tables categorization locally before attempting to commit that to your subversion repository.
June 29th, 2008 at 10:25 PM
It’s very information and useful for migraine management.
To complete migraine treatmeent,
you might need to have two free bonuses of ebooks: Healing Food and Pennasia Sleep Therapy (Pleet).
Visit at PennasiaNormalization.com for further.
I also get two free bonuses of ebooks when I enter forum. Have a nice day!
January 29th, 2010 at 6:00 AM
Thanks Andrew for the wonderful script.
The script works for Drupal 5 but cannot be used for Drupal 6 as the database implementation has changed. The Drupal 6 version of the script can be found at http://www.blisstering.com/migraine-synchronize-your-development-staging-and-production-sites-databases-drupal-6
June 7th, 2010 at 10:54 PM
Been trying to use Migraine, but have a few questions, coming from using the Drupal 6 version:
I had hoped this would help me in the place I need help, getting content from the devel/staging server put on the the production server while at the same time maintaining new content that users have put on the production server.
My situation is this: on the development site, this is when we add tons of new pages of content for users to view, for when our site goes to a new version. Also, we use different content nodes for various things, from email templates (our site sends various emails to users based on events, such as when they submit a project proposal for others to view, and they need to have translation ability) to tip and tricks, to FAQ entries, etc.
So, I was hoping Migraine made it so these nodes mentioned aboved could be merged with user nodes, such a blog entries. Is that not the case? Can’t it export rows from the node table that match, say, type=”faq” or type=”email_template”, but leave the other types alone? Of course, this brings to question how it would handle content types made from custom modules (which mine are, such as the email templates) that have fields in their own database table as well, such as my emails having a “Subject”, “Default From”, “HTML/text” fields.
Is this possible? I would prefer to set up all site content on the devel/staging servers, then get this, as well as settings/configuration updated on the production server. Please let me know how this can be done.
Thanks