This is a re-write of my drupal.org forum post at http://drupal.org/node/424154 . I figure it would be better discussed here.
How do I get configuration updates out to "pre-configured" sites? I'm currently using install profiles to "pre-configure" drupal sites, but they offer no way to "update" the profile on an existing site when a new version is released.
I am creating install profiles and custom themes targeted to the Acquia Drupal distribution. The idea is to make it as easy as possible for end users (small business owners) to create and maintain a "plug and play" Drupal website targeted to their business needs. All one will have to do (to install or update) is download Acquia Drupal and a profile/theme combination (what I call a "website package"), and they have a complete website ready to roll (including custom views, cck fields, associated template files, ect...). Updating the whole thing could be just as easy. That's what I am hoping for. The next step in getting Drupal adopted worldwide.
But what happens if I, as a profile and theme developer, want to update an existing profile's configuration? What if the distribution has a new module available, and I add a configuration for this module to an existing profile? What if I add a new "view" or content type to an existing profile? How do existing site owners get these new configurations? In this particular case, where I'm developing "pre-configured" websites, my end users are going to be able to receive updates to my theme (at http://drupal.org), and the Drupal distribution (at http://acqua.com), but profiles don't have version numbers to speak of, and they cannot be used except to first install a new website. So no matter what version of the install profile is newest (would be released with the theme that goes with it), the existing site "configuration" will be locked into whatever version they installed with. Any new configurations will have to be added by hand on a "per site" basis. They might not want to, or be able to make these modifications themselves. (They're probably not interested in diving "under the hood")
Can we get installation profiles to run on an existing site? Configuring a site is what installation profiles are really good at. Seems like we should be using them for initial configuration AND configuration updates as well. Is this possible? Of course this brings up the issue of making sure one has permission to run install.php, when the site already exists. This file (unlike update.php) does not check for permissions. Also we would need to get the script (install.php) to NOT re-install Drupal itsself, but just add certain (new) configurations. Seems like we could set this up using the "task" calls built into the install profile system. By calling variable_set('install_task', $task) , some time before the update procedure (where $task is a "check for updates" part of the profile) we could jump straight to the appropriate task, and bypass the core installation. Seems like this could work, but is it the best way?
How do I get configuration updates out to "pre-configured" sites? Any relevant discussions or work done on this topic? Are these needs this on anybody else's radar?
Thanks,
M.M.
P.S.
My first post to this group. Looking forward to more.
Install Profiles, and "pre-configured" websites are the future of Drupal.
At least for me.
Comments
To answer your question: nope
Install profiles are ... install ... profiles :P So, to straight up answer the question posed by the title -- no, install profiles can't update existing sites.
For pushing out later updates, one way you can do it is include a module that holds your update codes. You can run config changes on the whole site using this method.
There is a coming wave of work around import / export, packaging, and deployment (in fact, there is even a packaging and deployment group).
Install profiles, ideally, will evolve to be a wrapper around a set of packages that happen to run at install time, with package updates allowing updates / config changes after install.
Features
In packaging and deployment group, make sure you check out "Features module quick demo" - we've started to use features on production sites and it's a great time saver, even for projects that don't have a complex deployment plan:
On your dev environment:
drush features update event_sectionsvn commit -m"I just updated the event section." event_section
On your staging site:
svn update event_sectionhttp://www.twitter.com/lxbarth
Thank you ... so what do I do right now?
Thank you both for your valuable feedback.
Boris, I am currently using your API to build install profiles. I've found it to be a wonderful asset, but I 'm now wondering if this a wave of the future, or just a stop gap? As soon as I realized that configuration "updates" are not deliverable in the "install profile" format, I started to wonder how I could better create my "website packages". Your idea of a custom module is intriguing. My template site and theme are already built. I could export the configurations to a module instead of an install profile. I'm not sure of "best practice" on how to "execute" the configurations in the module (in an "update function" or on a "settings page"?), but even more concerning for me is that I don't know what tools will be the "recommended" ones down the road.
I want to build using tools that will be around a year form now, even if they work differently. I want to be able to "update" whatever packaging tools I use to export, install, and update my website packages. I'm kind of stuck right now, at such a wonderful time of discovery and invention, because I really don't know which road to follow.
Alex, I read your post and saw the screen casts. This has inspired me and confused me all at once. I see this as a wonderfull solution. From the site developer and administrator point of view, it's just the thing I want. Better, even, than anything I've seen yet. But is this "module based" solution the new direction drupal will be going? Does anybody know that?
I visited this post in Packaging and Deployment group yesterday, and gained real insight : Notes from BoF. Here's what I want to know ...
I'm just a freelance website developer. I'm a user of the tools that y'all are putting such great efforts into. I've joined these groups to gain perspective on this new and changing tool set. Thank you all for contributing your time and efforts in making Drupal a better platform. And thank you for sharing your insights.
Best,
M.M.
Re: custom module
Features /features-like stuff is the way to go. Follow Alex :P
You can still use a custom module to do updates in the interim -- you're not ditching install profiles (which do installs just fine, today). You create a custom module, which, when you update the config of a running profile, applies those changes via its update function. So, to apply updates, people just install the new version of your name_of_profile.module helper module, plus associated updated modules, and the helper module makes the changes using the core update functionality. Make sense?
Is install profile API the wave of the future? Nope, it is a stop gap, because the dirty secret is that those functions should be in Drupal core (or in the contrib module itself). Whenever you have to do a db_query in an install profile, then the module you are trying to work with hasn't correctly exposed a so-called Data API so it can be driven programmatically.
Updates over time might ALSO be delivered by something like the wonderful Deploy module.
You say you are "just" a freelancer ... well, in my book you are a smart freelancer :P Time you spend investing in a tuned install profile is more time in a proven, evolved solution for your clients. Invest in a great install profile, and it takes you less time to get "the basics" done, and then go on to customization for each client. Don't forget to charge for your expertise -- that install profile is valuable, and you've sunk time into it up front.
Even better, share it with others and evolve it together :P
Solve packaging problem first
The key is solving the packaging problem. Once you've got updateable packages (think: set of modules + configuration), you don't need to make installer profiles update anything. As I said before I'm working with features module which attempts to solve this problem.
The key paradigms of features is a) keeping configuration in code (rather than scripting updates for config in DB) and b) dependency detection. Check it out, try to roll your own feature.
http://www.twitter.com/lx_barth
http://www.twitter.com/lxbarth
check out my new module...
I built a tool that helps you create hook_update_N() functions by capturing changes through the web interface.
I setup the module as a collection, the first and so far only module tracks form submissions using macro.module, and stores them as a serialized array per hook_update_N.
http://drupal.org/project/custom_module_tools
Documentation page is missing images for the time being... here's some screenshots of the interface: http://drupal.org/node/439352
I personally think this is the way to go for things that don't already export easily, like views, panels, and CCK.
There are many modules that store their own data in their own way, and creating specific deployment APIs for all of them is unlikely to happen anytime soon.
This way, you can replay any form submission on a live site, and have your custom module's version number track which ones have already been executed on the live site.
It's a brand new concept... I'd love to hear what you all think about it :)
Jonathan Pugh
CareerNerd Industries
www.careernerd.com
Jon Pugh
Founder & CEO
THINKDROP
open source consulting
http://thinkdrop.net
Profiles can carry .install
Profiles can carry .install files withupdate functions in d7. so this is a solved issue going forward.