I would like to disable user access to the administration during updates, such as bugfixes and additions of new content-types etc. I'm not completly sure on how to achive this. What would be the best solution, setting the site in maintaince mode is not an option.

  • 5
    This is exactly what maintenance mode is meant to do. May I ask why it isn't a viable option? Mar 8, 2012 at 17:29
  • This is really a duplicate of stackoverflow.com/questions/730138/…
    – paul-m
    Mar 8, 2012 at 17:29
  • @paul-m I'm not sure how this is a duplicate?
    – Chapabu
    Mar 8, 2012 at 19:03
  • You want to maintain as many users as possible while updating the site. That's called 'deployment.' There are many best practices for this, and many are listed on that other question. The first is that you don't muck around with your live site; you make changes on a different server and then deploy the changes.
    – paul-m
    Mar 8, 2012 at 22:19
  • @paul-m - I make changes on a different server and deploy everything to a live environment, but the users also use the same server to add, remove, edit content. Mar 9, 2012 at 4:57

2 Answers 2


It sounds like you're running into a common deployment issue with Drupal: the fact that content and configuration reside in the same database. This generally puts a kink somewhere in most deployment strategies, as you start to run into issues whenever you have to merge existing user content (often a moving target) with upstream configuration changes.

Depending on how else you may have things set up, this may or may not involve drastic changes to your workflow, though this is the generally recommended solution for such issues. I'm not sure how much experience you have on these topics, so I'm going to break it down piece-by-piece for the benefit of anyone running into similar issues.

Dev/Test/Prod Workflow

Generally speaking, we have at least three servers in an optimal workflow. A "Development" server where our main version control repository lives (if you're not using one already, I highly recommend it!), a "Staging" server where we run our last rounds of acceptance testing and start adding default content, and a live "Production" server where everything is served to the end user.

Dev/Test/Prod in Drupal

As mentioned above, the fact that the database contains both content and configuration makes things quite messy. It's difficult to check a database into revision control, it makes configuration much less portable, and most attempts to decouple content and configuration are met with frustration (as with locking out certain privileges while making major updates to the site).

The adage "configuration moves forward, content moves backward" through the dev/stage/prod workflow still holds true as best practice with Drupal. We want to put as much configuration into code as possible, removing it from the database in an effort to decouple the two. This way, we can push features forward through the workflow as normal, and then take content from the live site and pull it back to dev when needed, without getting in the user's way.

Moving Configuration to Code

How do we move configuration to code, though? The Features module allows you to export the configuration of most popular modules to code as "feature modules"--in fact, anything that implements CTools Exportables is fair game. You could even add your own hooks to these exported feature modules and bundle them in an installation profile for one-click deployment (they're still just modules!).

In the rare cases where you can't achieve the desired functionality using Features alone and absolutely must hack at the database, you can do so through a custom module or an existing exported feature, using hook_install() and hook_uninstall(). hook_update_N() can be used for incremental updates, but remember to update hook_install() to reflect the same changes as well!

Moving Content

If required, content from staging can also be pushed to live using a solution like the Deploy module. This way, you can push updates from dev to staging, and then use maintenance mode on staging only when polished functionality is being pushed forward from Dev. You could also use it to push content from your live site back to the Dev server, to ensure that you always have easy access to the latest live content.

That said, now that configuration has been stripped out from the database, it becomes much easier to just move the database around as a content store, rather than a hodge-podge of content and configuration.

In Closing

This is a difficult and long-standing problem in Drupal, and doesn't have a quick fix, though I've used the above workflow on several projects with a high degree of success. I'd be happy to clarify any parts of my answer.

  • I have the following setup: A dev server for testing, a master server for updates and a production server. Everything (including the database) can be deployed between these three servers. In other words I may clone the database from master to dev and then for instance make updates to the theme and then deploy everything back to the master. Mar 12, 2012 at 6:11
  • 2
    That setup sounds perfectly reasonable. If I understand the current workflow and the question, the issue is keeping the databases synchronized (making sure users are not generating new content, etc.) while updates are being made from dev to master, is that right? If so, the best practice here is to sidestep the issue of keeping the databases synchronized as much as possible, by moving your own changes to code instead. That way you can keep your bug fixes in a revision control system, and simply revert your Features to the new defaults and run update.php when necessary. Mar 12, 2012 at 15:41

Depending on how complex your roles are, you could have a restricted role which all restricted users are moved to temporarily whilst the updates are made, then returned to their regular role once the updates are complete.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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