-1

I am new to Drupal, but have learned a lot over the last two or three months. I am still fuzzy and perplexed about how to migrate new functionality and/or content from development to production.

I have turned off the Comments module because it really doesn't make sense for my site, but visitors can create a login ID. I will add the ability to subscribe to a newsletter soon. This means that I have to identify which tables and/or files are changed when a new login is created so that I don't destroy them when I migrate updates to the site from my local Win 7 computer running Acquia Dev Desktop.

I have learned that:

  • Drupal uses a MySQL database to store not only content, but also settings information such as those pertaining to the Backup & Migrate module.
  • In addition to the database there are LOTS of files with settings information, php statements and/or HTML.
  • The Schema module's compare function tells me which tables are used by a given module.

According to Is there a module that lists which tables are created, owned or modified by a particular module? all well written modules should create tables only using hook_schema, and should not alter tables in other modules.

If you suspect that other tables got changed, you can find this in the .install file for each module. Look for the database layer calls like db_add_field or even db_create_table.

With the above in mind, Schema gives me the tables a given module creates in the database. In my case, User is apparently the module that handles loginID's. Since it is a core module I assume that it is well written and that I don't have to go looking in its install file.

It appears that there is no enforcement mechanism in Drupal 7 that would prevent module developers from not using hook_schema.

I discovered the Backup & Migrate module a few days ago. It works smoothly, but does a wholesale restore which would wipe out new logins.

The Data Export Import module (https://www.drupal.org/project/data_export_import) seems like it will work well, but I can't find a video or documentation.

There is lots of useful information at Drupal cross server workflow. From that I got the following:

  • The Features module seems to apply to developers, not me because I am not writing modules.

  • Drush appears to be overkill as well and yet another learning curve.

  • GIT appears to be overkill and another learning curve for a one-man shop.

I seem to be left with a manual export/import of the database using phpMyAdmin to prevent wiping out the login ID's. As I move forward with more functionality this task becomes very cumbersome. I am hoping that the only thing I have to fret over is the database so that I can just use FileZilla for files uploads without having to worry about what files may have been changed by activity on my site.

Please tell me which assumptions I've made above that are incorrect. Also, I'd appreciate any additional advice you can give.

Sorry this post is so long. I wanted to be thorough!

0

Short answer would be: For Drupal 7 use Features module for deployment.

It is not only for developers, it is mainly for site-builders who create new content types, views, install and configure modules.

Main idea is that you extract all required configuration data from your development DB and put it into the code. Then you only need to move this exported features files to your production site - and no more need to synchronize DBs (which could be tricky if you want to keep content from production DB).

Here is a good introduction into using Features.

By using Features, Strongarm and Features Extra modules you can migrate almost all configuration data.

And a few words about Git - even if you are working alone you should use it. When you export all your Drupal configuration into the files, Git will help you to manage versions and keep history of all changes you did and why you did them (which is even more important).

The next step would be using Git to deploy code to the production instead of using FTP.

Note regarding Drupal 8 - it has built-in support for managing configuration and using Features module is no more necessary. here is a good overview.

| improve this answer | |
  • Thanks for your ideas and suggestions. I really think that Drupal is the way to go for web sites, but what a learning curve! I think I read somewhere that Drupal 8 significantly improves this issues of migration. Is that so? – Sam Stamport Jun 17 '15 at 17:33
  • Yes, Drupal 8 stores all the configurations in the files, so makes deployment much more easier and straightforward. Here is a good overview drupal.org/documentation/administer/config – Eugene Fidelin Jun 18 '15 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.