In standard php or source code based projects we easily keep all of the code in SVN and each developer can checkout their own copy and collaborate on the same code.
When developing a Drupal site however, much of the work is in "setup". Besides the theme and modules you don't really have any "source code". How do you run multiple instances of the same site so developers can all work at the same time yet share their work?
Example Scenario:
We launch an initial version of a Drupal site with content type "X" created. We also initially launch a view on the site that lists all the nodes of type "X" in chronological order. The client starts using the site, add content, menu items etc.
The next release is planned to add user search ability to that view. The setup for that is contained in the database though. We can copy down the production database to our development version to get the latest data while we work on changing the view. During that time however the client can still be updating the site, making our dev database out of sync. When we are ready to push the new view to production, is there an easier way to do it other than manually repeat the steps to set it up on the production install?
Version Control API is the system that drives all of Drupal.
The Drupal open-source software project and community organizes itself into projects; most have an associated source code repository. Changes to the source code are tracked using the Git revision control system, and we use GitLab software to provide a web interface to Git and other features.
There are three different types of Drupal modules – core, contributed, and custom. Core modules are included with your original Drupal download and can be turned on or off without the need to download any additional components. Contributed modules must be downloaded independently and added to your website.
I think a good strategy here is to use the install profile API. With install profile API you can do most things that using the Drupal admin tools do. Most core forms simply set variables in the variables table. To be able to sensibly version your non content database contents i.e. configuration it is wise to use update functions.
On my site we have on module "ec" that does very little apart from have it's ec.install file contain update functions e.g. ec_update_6001()
Your main install function can take care of actually running the updates on any new installs you make to bring your modules up to date.
function ec_install() { $ret = array(); $num = 0; while (1) { $version = 6000 + $num; $funcname = 'ec_update_' . $version; if (function_exists($funcname)) { $ret[] = $funcname(); $num++; } else { break; } } return $ret; }
A sample update function or two from our actual file now follow
// Create editor role and set permissions for comment module function ec_update_6000() { install_include(array('user')); $editor_rid = install_add_role('editor'); install_add_permissions(DRUPAL_ANONYMOUS_RID, array('access comments')); install_add_permissions(DRUPAL_AUTHENTICATED_RID, array('access comments', 'post comments', 'post comments without approval')); install_add_permissions($editor_rid, array('administer comments', 'administer nodes')); return array(); } // Enable the pirc theme. function ec_update_6001() { install_include(array('system')); // TODO: line below is not working due to a bug in Install Profile API. See http://drupal.org/node/316789. install_enable_theme('pirc'); return array(); } // Add the content types for article and mtblog function ec_update_6002() { install_include(array('node')); $props = array( 'description' => 'Historical Movable Type blog entries', ); install_create_content_type('mtblog', 'MT Blog entry', $props); $props = array( 'description' => 'Article', ); install_create_content_type('article', 'Article', $props); return array(); }
Effectively this mostly solves the versioning problem with databases and Drupal code. We use it extensively. It allows us to promote new code which changes database configuration without having to reimport the database or make live changes. This also means we can properly test releases without fear of hidden database changes.
Finally cck and views support this approach. See this code snippet
// Enable CCK modules, add CCK types for Articles in prep for first stage of migration, // enable body for article, enable migration modules. function ec_update_6023() { $ret = array(); drupal_install_modules(array('content', 'content_copy', 'text', 'number', 'optionwidgets')); install_include(array('content', 'content_copy')); install_content_copy_import_from_file(drupal_get_path('module', 'ec') . '/' . 'article.type', 'article'); $sql = "UPDATE {node_type} SET body_label='Body', has_body=1 WHERE type = 'article'"; $ret[] = update_sql($sql); return $ret; }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With