I am developing Drupal sites sometimes. This development involves writing custom module and of course lots of configuration work on the admin interface.
I keep track of my custom module using SCM (git of course..). Unfortunately the configuration of all the drupal modules is even more important and fragile. These settings are spread in the database and therefore cannot be easily kept track of.
I create backup of my development DB on a daily basis, but having realized that something went wrong it is a pain to compare the backup with the actual state to hunt for differences.
Do you have any best practices or suggestions how to do it professionally? (I still use Drupal 6 if that matters, but I'm interested in new features of the 7 and 8 versions as well) I read about the Feature module that is very promising, but not exactly what I need.
My first ideas were (1) a module that would store all the settings in files that can be tracked with SCM easily, or (2) some automatism that would export the tables into files every time something changes
More and more configuration can be moved into SCM as time goes by.
At the state of Drupal 7 some people start developing their sites as an installation profiles. E.g:
http://walkah.net/blog/every-drupal-site-install-profile/
Features are another way of tracking changes and usefull to change configuration over time, e.g. when several people working on a site and want to share their configuration which they build on their local dev machine. The usability of features can be enhanced using ctools and drush (See Drush CTools Export Bonus module as if you take that route).
For quick import/export of Node types, Taxonomy, User, Field API fields and Field groups http://drupal.org/project/bundle_copy seems a good option.
Here is a good blog post about the different options: http://palantir.net/blog/multi-headed-drupal
With Drupal 8 we'll see a big shift in configuration management as configuration export will be built into core. There are several core initiatives and one is the configuration management initiative. A backport of some of the functionality is available as a Drupal 7 module.
Besides this a way I like to handle things when working is to note the things I have changed with my time or in the issue tracker of the projekt I am working on.
Related
I'm very new to Drupal, so please don't be too mad in case I have any major misunderstandings :) I've tried searching for a similar problem, but is just couldn't find a suitable solution for my case.
We're currently setting up a Drupal 9 project, which will perspectively have a shared development environment and a production environment as well as a local instance to develop on. I'd wish to have a way to synchronize those instances to have the same configuration, content types and optionally even content.
At the moment, I'm developing a theme locally, which means I have installed a Drupal instance inside a XAMPP server. That theme is versioned by git, so it is migratable to another developer without a problem.
For migrating the structure and content (which is obviously saved in the database), I tried using Backup & Migrate, but there were two issues I was facing: The D9 version is not fully supported yet, so an installation via composer fails with default security settings, and there seems to be an already multiple times reported bug when trying to backup the entire site. You can workaround it by backing up the database and the files separately, but this is pretty inconvenient due to other issues (but let's keep it a little short...).
I also tried to export the whole database, which is actually working (after this little fix), but the overhead seems a little high for me. Especially when I just want to copy new content types from dev to prod environment without users, content and so on, for instance.
So, to finally come to an end, is there any best practice for this case? Or should I even consider to go a whole other way?
Thanks in advance!
I definitely wouldn't recommend using Backup & Migrate for this - that's so Drupal 7! Drupal 9 has better tools that are baked into core!
There are many possible ways to import/export Config and Content entities across environments, but I'll share what I believe to be the current best practices.
For Configuration, Drupal 9 has a built-in Configuration Management system that makes it quite easy to migrate Config across environments. It can be used within the Drupal UI, and also integrates with Drush (a command-line tool for Drupal).
Essentially, the Config system exports all Config settings as standardized YAML files, which can easily be included in your Git repository. This will make it incredibly easy to set up another Drupal environment that is identical in its Config settings.
More info on Configuration Management can be found here.
For Content, Drupal 9 has a built-in Migrate API, which facilitates migrations from any data source into a Drupal 9 environment. That means you could set up a migration that would allow you to migrate your Content entities across environments.
I've only ever used this for migrating Content (migrated from Drupal 7), but I believe it's also possible to use this to migrate Config as well.
If you decide to use the Migrate API, you may (depending on the setup of your content) need to install Migrate Tools and Migrate Plus.
More info on the Migrate API can be found here.
I have one Developer Portal in Bluemix API Connect for the Development environment, one for Testing environment and one for Production environment. I have made some customizations in the structure of the modules, settings and content and I would like to migrate them from one environment to the other.
I have a theme for the styles, fonts and images but there are settings and content that are not included in the theme. I have found some Drupal plugins to migrate tables from the database. However, there is a risk of overwriting tables related with the API, products, plans, etc.
I would like to know if there is a recommended way of doing this migration without having to do everything again manually.
There isn't currently a simple way to migrate that sort of configuration between portal sites.
There is a Drupal module called "Features" which can export / import capability but it doesn't support all configuration and isn't a process we have tested or documented, so you'd be using it at your own risk.
You presumably uploaded your custom theme to one site, so you can just upload it again to the second site - that bit is simple.
If its an extensive amount of configuration then you can raise a support ticket and ask Ops to overwrite the target site with the configuration of the previous site - but that's a one off process, it would completely wipe the target site. So that isn't really going to help with ongoing changes.
You can write a custom drupal module to make your configuration changes - then simply load the module on each site and it would make the desired changes. However that can be a lot of work. If you only have a couple of sites it's likely easier to simply redo the same changes manually.
Hopefully this will improve in the future.
(Full Disclosure: I am part of the API Connect development team)
We have several Drupal 6 sites. On most of the sites we will have some content editors, who will optimally log into a dev/test site and create content. Mostly just plain vanilla pages. What is the best method for migrating these newly created pages to the live server? I know there is the Deploy module and also Backup and Migrate. Are these the de facto standards? I was wondering if there is anything else I might be overlooking or if there is a better/easier solution. I am ONLY interested in moving content. We will be using GIT to move code and the Features module to migrate admin changes.
THANKS
In the past I've used node_export and recently I've found (in drupal 7) that the uuid module is invaluable. It means you can keep a track of content even if the nid's change as you move it over.
There are some legacy modules hanging around too that did an okay job but their functionality has really been surpassed by the modules you mention and the ones above.
If you're creating all your content using fields added with cck, you shouldn't have a problem. I personally use node_export along with features to allow easy importing and updating.
One gotcha you might want to look for on node_export is when importing on the new site, if a node is found with the same uuid (i.e. you're doing and update), the default is to create a new node. I prefer to create a new revision. Worth tracking down that setting (it's there in d7 so likely in d6 too).
EDIT: node_export doesn't currently export panels very well if at all - just in case.
It depends on the structure and diversity of the nodes (how many fields of which type, how many node types). My first try would be to generate a view with XML output (views_datasource.module or views_data_export) on the dev site and use the feeds.module for XML import on the live site.
The above XML export modules are avalable for D6 and D7. In Drupal 6 I used views_bonus.module for the XML export.
I'm working at a company that uses Drupal 6 to host documentation for it's SAAS products. The documentation is organized in various books using Book.module.
We have a Production Drupal site with the documentation for the production SAAS product.
Secondly, we have a "Preview" site, for the upcoming version of our product - the documentation is slightly different than on the Production site.
Thirdly, we have a "Development" site, which contains the unstable version of our product documentation. The documentation here changes frequently
Documents are originally authored on Development, moved to Preview, and then finally to Production.
It's quite unwieldy to manually update each Drupal site as our product evolves. I've looked at Deploy.module, and although it looks promising, it has limitations wrt books (ie: it can't handle the book structure/menus). It also makes for a solution that is quite complex with lots or moving parts.
I'm hoping that I've been over-thinking everything and some Drupal rockstar out there can point out an obvious (or not-so-obvious) solution.
(An obvious non-drupal solution would probably just be store the documentation pages as html in version control and update each site with the appropriate revision. But with this I lose the ACL functionality that Drupal is so good at.)
Thoughts?
Cheers
I've had good luck with the Feeds module to get one site to consume a certain view from another site when I choose or periodically. It will take some configuration work to get going but it's more flexible than a turn-key solution and it's less fragile than any SQL dump -> import of the node revisions table.
I was wondering how teams that develop sites using Drupal (or any other CMS) integrate version control, subversion, git or similar, into their workflow. You'd obviously want your custom code and theme files under version control but when you use a CMS such as Drupal a lot of the work consists of configuring modules and settings all of which is stored in the database.
So when you are a team of developers, how do you collaborate on a project like this? Dumping the database into a file and putting that file under version control might work I guess, but when the site is live the client is constantly adding content which makes syncing a bit problematic.
I'd love to know how others are doing this.
You are correct that this is an issue for Drupal--version control works fine until you turn the site over to your client or open it up to users.
Your question seems like a more specific version of this one, which touched on version control in the Drupal workflow. You may find some answers there that help.
For some projects, I have exported all of the views to code, using that feature of the Views module, and I have one project where all of the blocks have been exported, as well. (Although that was a development exercise and not a customary thing to do with blocks.)
Take a look at the work that Development Seed is doing to work around this problem. They are leading the development of the Context, Features, and Spaces modules that work together to store configuration data in modules (outside of the DB) so that it can be versioned with the code.
There is a Drupal group called Packaging & Deployment for discussing the various solutions that are being developed for this issue.
Right now there are a lot of efforts towards creating something that will handle the dev -> production difficulties with drupal in relation to the database. Features, that flaminglogos mentioned is one, but I feel that is more focused on creating stand alone projects, ie ones that would be installed on many sites.
For simple maintaining you dev and prod databases I'd take a look at http://drupal.org/project/deploy and http://drupal.org/project/dbscripts. They support syncing and merging db side drupal config data.
I can't guarantee they are ready for prime time though...
There is a lot of effort of shipping the next drupal version with configuration in code. That's is the key to have it in a version system.
For now you can use the features module, with that you can export things like content types, views, etc. to code, and then compare, version and revert it as you need.