Update: See Distribution packaging now fully supported on Drupal.org for details of new functionality.

3281d Consulting is very pleased to announce that a new era on drupal.org has begun: Drupal distributions (also known as "installation profiles") can now be automatically packaged with Drupal core and all of their required dependencies. When you download the distribution, you just unpack it into a web root directory, visit install.php, and you're done. This should vastly lower the barriers to getting a new Drupal site up and running. Please read on if you've ever considered installing a Drupal distribution or if you maintain one on drupal.org.

Changes for end users

Mostly, the only change for end users is that installation profiles are actually useful now. If you're viewing the project page for an installation profile, and you scroll down to the "Downloads" section, you'll see a table that looks something like this:

In the "Recommended releases" table, find the entry for the version of Drupal you want to install (for example, 6.x). If you click the "Download" link, you'll immediately get a .tar.gz archive (.zip files are coming soon, stay tuned!) that includes Drupal core, the installation profile itself (which defines the modules and themes to enable and can configure your new site), and all of the required modules and themes that the distribution depends on. If you click on the version string or the Notes link, you'll see the full details for that release of the distribution:

The first table lists all the available files you could download. The top file, ending in "-core.tar.gz" is the one you would download directly from the project page. The one ending in "-no-core.tar.gz" includes the installation profile directory and all of its dependencies, but not a copy of Drupal core. This would be useful if you were setting up a multi-site installation and you just wanted different profiles in different site subdirectories, for example. The final option, just ".tar.gz" includes only the installation profile directory. This would only be useful if you were planning to build the whole site yourself with drush make, or if the installation profile wasn't updated to the new system and didn't provide a fully packaged distribution.

The second table lists all the components included in the distribution. This table is aware of all available releases on drupal.org, much like the Update status module included in Drupal core. If newer releases or security updates are available for any of the components of the distribution, the release notes will look more like this:

That's a warning to you that the distribution maintainer hasn't updated their releases. If you still go ahead with installing the distribution, you're going to have to manually update the components that are marked in red as "Not secure". If the latest release of a distribution is missing security updates, the table on the project page will instead look like this:

If you see something like that, think twice before installing, and be prepared to update some of the code to make sure your new site is secure.

Changes installation profile maintainers

If you maintain an installation profile on drupal.org and you want it packaged with core and all of its dependencies, you need to write a drupal-org.make file that will be read by drush make. Detailed instructions are available at the How to package a profile on drupal.org handbook page. Please read that. Really. :)

Issues

If you find a problem with the new system or have a suggestion on how to make it better, please search for issues with the packaged install profiles tag and see if the issue has already been reported. If not, you can submit a new issue for the Project module -- just be sure to add the "packaged install profiles" tag.

Credits

This whole system was built by Derek Wright (dww) and Chad Philips (hunmonk) of 3281d Consulting.

The work was made possible by the generous sponsorship of Deproduction and Quiddities, and matching funds from the Drupal Association. For more background on the effort and information about the sponsors, see Install Profiles Packaging on Drupal.org - Funding obtained, feedback welcome.

Thanks go to Dmitri Gaskin (dmitrig01) for building and maintaining drush make, and to Adrian Rossouw (adrian) for co-maintaining it and helping debug various things during development. Thanks also to Earl Miles (merlinofchaos) for help with some of the more crazy Views integration for all these update status tables, and to Roy Scholten (yoroy) and Bojhan Somers (bojhan) of the usability team for help reviewing the UI on the project and release pages.

Comments

Jon Nunan’s picture

This should really increase the use of installation profiles. I think people trying out Drupal for the first time were scared of the extra setup they entailed. Now this is no longer a problem, great work!

websule’s picture

Congrts,

We are finally at the point, we always wished we were a long ago.
This will let "drupal - out of the box solutions" be a reality now & a pretty famous reality.
This will not only help the drupal stores show their expertise with installation profiles & back-end development, but also help the drupal users to be the biggest beneficiary, by obtaining ready to use drupal solutions.

We would like to hear back from you guys. So, please submit your votes to the drupal package you would like to be released first of all: http://groups.drupal.org/node/37422

We are all ready to make our first release public by the codename of 'W3CMS - Premium Drupal CMS ' following the series by W3cart, W3Social, W3blog and many more.
We are very excited to have it in action :)

stephthegeek’s picture

Huge congrats and thank you to everyone involved! As someone who has never actually taken action on putting together an installation profile, I can say that this definitely tips the scales for making them vastly more useful (and motivating to actually do something about it).

thomjjames’s picture

Great work everyone involved! Congrats.

______________________________________________
https://tomswebstuff.com

rjdempsey’s picture

This is awesome and makes install profiles truly accessible.

NetSage’s picture

This not only makes it easier for new people to adjust to Drupal (I may make one actually because this :P), but also makes the lives of people who already use it much easier.

JayNL’s picture

Congrats, this is very good.

seutje’s picture

awesomeness, I love how it tells you when a profile ha out of date components, but will this affect performance on d.o in general, or shouldn't I worry about that?

also is it possible that this

<a href="/node/647374"><img width="220px" src="/files/distro-release-with-insecure-code.png"/></a>

should be

<a href="/files/distro-release-with-insecure-code.png"><img width="220px" src="/files/distro-release-with-insecure-code.png"/></a>

seems a bit silly to link to the page ur already on :P

dww’s picture

All of the fancy views stuff is built on denormalized data. So, it's a bit more expensive now whenever people create a release node, but viewing these tables should actually be faster than it used to be. That said, these download tables are cached (even for authenticated users) so it wouldn't matter that much either way.

And no, the link from the thumbnail was fine. I wanted it to point to the article so that when you're on the front page and just see the teaser and the thumbnail, if you click on the thumbnail, you come to the story, not a large version of an image... But, now that you mention it, I just took that thumbnail out of the full text view, since the large version appears lower in the post, anyway.

___________________
3281d Consulting

seutje’s picture

oh my bad, I just saw a down-scaled image that linked so I clicked it expecting a full size, didn't notice the full size was just a bit lower on the page, my apologies

zzolo’s picture

Thanks for the great work everyone for making the world and Drupal a better place.

--
zzolo

Steady’s picture

Hi All,

I think this is useful, but folks, it is still far too complicated for beginners!!!

I have been using drupal for over a year and most of the above is gibberish to me.

Basically, what I am looking for is faster drupal installation with all the common modules such as views, cck etc already included.

In other words, we want to quickly create a "standard" installation for people/clients that only needs minor modifications and one or two new modules if any. i.e. All the main useful modules already added to an initial installation.

Is this what an Installation Profile is?

If so, where do I find any of these "standard" installation profiles?

Where do you see what is included in each profile?

I'm afraid the language/nomenclature used to try and explain this has really confused me.

Is there any simple documentation anywhere on this subject.

I know enough about drupal to believe this may be what we need, (need to create/build over 50 very similarly structured sites).

However I don't yet speak the "lingo" to know whether this is what we need to help speed up our site developments.

Please help and clarify how this works.

Many thanks,

Confused Sam ;-)

rcross’s picture

yes, this is exactly what you're looking for. installation profiles are what enable these pre-built packages.

there will be many different use cases, so there will not really be a "standard" installation profile outside of core. You will have to choose which one fits your "standard" usage best.

Look at the table on the project page for what's included in each profile.

Nomenclature can be confusing, but this nomenclature has been in practice within the drupal community for many years now. Its important for you to get familiar with it if you want to work with the community. If you do not want to spend the time to learn this material, then it would be wise to consider hiring a Drupal professional who can advise you.

Read the rest of the documentation for more information as suggested in the article.

Elijah Lynn’s picture

Drupal Gardens and Buzzr is the solution for people that really want a nice, easy entry into Drupal.

-----------------------------------------------
The Future is Open!

aac’s picture

Thanks for the great work!!

---~~~***~~~---
aac

Sree’s picture

good initiative!

-- Sree --
IRC Nick: sreeveturi

Aniara.io’s picture

Great job!

Pasqualle’s picture

I remember Dmitri playing with drush make this summer, and now it is deployed on d.o.. That kid is a genius, and the Drupal community is just simply the best. I will definitely use this in the future.

alex_b’s picture

This is a great day for packaged Drupal distros! A big thank you to everybody involved in making this happen.

dugh’s picture

If it doesn't auto-update to use the latest modules and so forth I don't see any advantage to this, it requires a lot of extra work.

It's still much easier to just take a local customized drupal install, dump the database, and zip up everything.

Can installation profiles store settings/configurations and nodes and uploaded files easily? No.

Just take a drupal install, customize it, then zip it up after dumping the database. Boom. Done.

NetSage’s picture

This isn't only meant for people making multiple installations of Drupal. It's also for those new to it who are more used to Wordpress or something that is a lot more user friendly out of the box.

dww’s picture

"If it doesn't auto-update to use the latest modules and so forth I don't see any advantage to this, it requires a lot of extra work."

vs.

"It's still much easier to just take a local customized drupal install, dump the database, and zip up everything."

A .zip file of some static code and a database dump doesn't auto-update itself, either. And, working with a fixed database dump has a lot of problems that an installation profile solves for you.

Also note that building a "local customized drupal install" is also a lot easier using the tools we've made available to support this system. If you maintain an installation profile on drupal.org, you can also automate the task of finding the most recent set of all the modules included in your distribution whenever you want to make a new release, which is clearly explained in the documentation.

That said, the place to solve auto-updating is not in the packaging system for what users download. That's a job that needs to be solved by something included in that initial package they installed. Luckily for everyone, the thing I was working on before implementing this whole system was the Update manager in Drupal 7 core:

http://3281d.com/2009/11/03/d7-update-manager

Once Drupal 7 is released and people start releasing packaged distributions based on D7 core, it will be incredibly easy to keep your site up to date. All you do is visit a page that tells you what you're missing, confirm you want to update those parts, and you're redirected to a form to provide your file access credentials (FTP or SSH password) and Drupal will securely update all of the contributed modules and themes your site is using.

"Can installation profiles store settings/configurations and nodes and uploaded files easily? No."

They can both store settings/configurations and also prompt the user for them during installation. They can create nodes, too. Try the drupal.org testing profile for an example of both. Furthermore, it sounds like you're talking more about the problems of staging vs. production sites, data migration, etc. All of which are real problems, but which aren't solved in core at all (yet), nor by the initial package you install to get started. That more what tools like features are trying to solve. And, having a way to automatically package a feature and all of its dependent modules is also important to the usability of the features approach. This whole system lays the foundation for being able to host fully packaged features on drupal.org, too.

That's the point. ;)

Cheers,
-Derek

___________________
3281d Consulting

Pasqualle’s picture

dump the database, and zip up everything

Wake up. That's not an install profile, it's just a dump..

you should read the comments on this famous article:
http://www.lullabot.com/articles/5-step-drupal-distributions

Elijah Lynn’s picture

Hi Doug!

If the profiles do not update automatically I would think that would be a plus, since you would know that that combination of modules has been tested and known to work well together. If the profiles were updating themselves all the time there may be more potential for things to break as the amount of modules in the profile increases.

-----------------------------------------------
The Future is Open!

Elijah Lynn’s picture

Why do I have to create releases for my profile every time a module or theme in my profile does it's own release? Can't it just automatically re-package their latest releases for my release?

While this would be convenient from the standpoint of making profile releases, it would be a nightmare for support. Imagine that the code for your 1.0 release that somebody downloaded Monday might not be the same code that somebody else downloads on Thursday -- how would you know what code everybody has? Freezing the code in a point release is a fundamental principle of the release system for exactly this reason. On the plus side, there is no obligation to create a new release for your profile just because one of it's related modules or themes was updated -- it's only critical to do this when there is a security release involved.

http://drupal.org/node/642116#faq

-----------------------------------------------
The Future is Open!

te-brian’s picture

Great work guys,

This is a huge step in the right direction. When combined with the ever-expanding powers of installation profiles in Drupal 7, we are getting real close to packages that really do work right out of the box. Also, to those naysayers pointing to the lack of auto-updates, keep in mind that Drupal 7 is making updating your modules easier than ever with the plugin manager and authorize.php.

I see a 'WorDruPress' installation profile on the horizon (along with a Drubrick theme) :)

websule’s picture

Someone in the comments above made a very good point about having the included contributed modules & themes update themselves automatically from the project itself. Please implemented this feature asap possible, as this would be another freaking point for developers maintaining the Project.

Where to provide more suggestions and feedback?

dww’s picture

One of the other major projects I worked on the recent past was teaching Drupal 7 core how to update itself:

http://3281d.com/2009/11/03/d7-update-manager

I'm tackling this problem from all sides. It should be easy to get started, and it should be easy to keep up. I can't retroactively fix older versions of core, so "easy to keep up" will depend on the next version. But we can (and did) retroactively fix making it easy to get started...

___________________
3281d Consulting

OsterD’s picture

+100000000 !!!! :-D

Carl Johan’s picture

Some distributions might not support the latest versions of certain modules - so automatically updating is a big no-no.

It's up to the distribution maintainer to keep their distributions updated, no? I wouldn't want to download a distribution just to end up with a broken install.

kreynen’s picture

When we were originally discussing this problem we asked for the option of indicating a specific version of a module or the currently supported version of the module. Committing updates to modules is already time consuming. We didn't want to have to go back and re-roll the install profile after every update.

dww made the smae case then... that trying to support specific versions of the profile would be impossible then. We still weren't convinced, but the progress on Plugin Manager and Drush Make really make testing module updates and rolling new version of a profile trivial.

We are really happy with the direction of the .make files for both module versions as well as supporting for third party code for developers comfortable with running Drush locally. This really is a much better solution than dealing with an issue queue that requires users to report every module version with every issue... I'm running version 1.1 of Open Media with version 2.5 of Date, Filefield 3.2, Image API 1.6, Location 3.1-rc1, etc., etc.

The process for updating the version of modules included in an install profile will simply be to update the modules in a test environment and run tests on that specific mix of module versions. If everything works, run "drush generate makefile" and commit the new .make to the profile.

NonProfit’s picture

Wow, great work!

sumitk’s picture

Great job guys! awesomeness

tjholowaychuk’s picture

profiles are stupid. Drupal just needs a proper package management system, then you can just have a small manifest describing the "profile". Wrong way to go, you guys should really learn from other languages and projects.

NetSage’s picture

I don't really understand why they are stupid. Or, what's wrong with the package management. Besides a package management system wouldn't allow you to have preconfigured settings like install profiles would.

moshe weitzman’s picture

Everything in Drupal is stupid. It is a work in progress. It gets better over time. And then parts still suck. You can help make it better or you can sit in the back of the room and throw spitballs. You can't go from nothing to apt-get in a single try. It takes years of iteration.

Folks who want to help with package management might want to read up at this oldie but goodie

adrian’s picture

that's exactly what this is.

you write a small manifest in the install profile ( a makefile) that gets packages generated for it.

drush make is also recursive, so when you include another package as a dependencies, all it's dependencies are also resolved.

duntuk’s picture

Profiles are meant to help those that may not be very familiar with Drupal--yes you can make the argument: not knowing is in some sense similar to the harshly worded statement 'profiles are stupid'.

Nevertheless, I think packages are good for people who are new to Drupal. If you're a veteran, then you'll probably just copy over all previously used modules from an existing site that has similar desired features.

Plus... I'm also curious to see how fine grained the selection of modules will get, because it's going to be very difficult to create packages that are going to have all the desired modules for everyone, and no unwanted ones, for whatever purposes.

mikey_p’s picture

Well, looks like the old way of doing this is officially deprecated. Awesome!

OsterD’s picture

People WE ROCK!!!!!
This will definitely downsize the time needed to produce a working drupal site.
If we can now sort out the dependencies of the modules it will be amazing.
Meaning :
On the download section of a module, we can have a list of dependencies that this module needs to operate and download them.

Thanks guys!!!

HongPong’s picture

Just one question springs to mind: where does the name '3281d' come from?? It must be deep &/or mysterious. I looked on the site to no avail :)

Seriously though this is really good, I will try to get a good profile up on it if I can. To be nitpicky I'd say the Drush_make project page needs a better descriptor, but yea!

Summit’s picture

This is super! So now views/panels/fckeditor/autopath/weblinks possible out of the box in a installation profile!
Greetings, Martijn

betz’s picture

AWESOME!!

visigraphic’s picture

it makes faster installation with express setup profiles.
thanks for the hardwork.

rhouse’s picture

The Drupal home page has a nice boxy with links for modules, themes, etc., but no link for profiles. What gives? How are beginners supposed to even find this feature or the list of profiles already developed? I sure can't find any mention of it on the home page (the current topical story excepted).

dww’s picture

This infrastructure just went live a week or so ago. There currently aren't enough useful distributions to make it worth prominently featuring them on the home page (yet!). I hope and expect that will change soon. Once the distribution maintainers really start taking advantage of the new system, we'll definitely consider making these a lot easier to find directly from the home page. For now, you just click the "Download" tab, and then click on "Installation profiles". See also #656986: Add info, filter (and default sort?) for projects that have packaged releases. All this will change via the drupal.org redesign, anyway...

___________________
3281d Consulting

Elijah Lynn’s picture

I wonder if anyone has the initiative to make up a "DrupalPress" install profile so people can make a nice switchover!

-----------------------------------------------
The Future is Open!

melwyn.s’s picture

Just one question ..... Is this an installer package ? something like the Bitnami Drupal Installation package ?

What is the difference between the two ?

From what i understand its just a drupal installation package , you unpack it directly in your root directly ..and your set to go ..

In bitnami...Everything is setup including apache, php, mysql, phpmyadmin...

Are there any plus benefits ?

Jon Nunan’s picture

The Bitnami package is everything you need to get a bare OS to run core Drupal. That is it installs a webserver / php / DB and the basic Drupal.

Drupal Installation profiles are for when you already have the hosting environment setup and want to use Drupal to make your site. What the install profiles do is give you a major headstart in terms of installing and configuring Drupal modules for the kind of site you want to setup.

Say you wanted a blog, a blog install profile would probably include SEO modules, image galleries, anti-spam, subscription/notification modules etc...

Where a corporate site install profile would probably include SEO modules, Workflow modules, document management, etc.

willieseabrook’s picture

Looks great guys. I'm looking forward to checking this out.

----
Willie Seabrook

David Latapie’s picture

Too bad I did not see this earlier. Well, maybe for Drupal 7 installation, but not sure, I do like my present setup.

I think it is still worth taking a look at my meta-distribution idea I posted on D7UX a while ago. It is sort of an uptream consideration

http://drupal.org/node/516878

I partially paste it here for convenience:

First the basic install itself. It is pretty common (download, fire up your FTP server, upload, go to the install page), but still could be made easier. How? Well, the French blogware Dotclear has it: the one-minute install file (basically a server-to-server install, although you still need to open up a FTP client—I imagine it would be easy to not even have to use a FTP client, but then major security issues would arise). Geez.
IRI in today’s Drupal: none

Second, choosing your language. Drupal welcomes you with English instructions. I don't care English is the lingua franca for the internet. Take a look at Apple: they have it right with Mac OS X. OS X’s very first install screen is made up of the language names in the language (Install in English, Installer en français…). This is intuitive, this is short, this is good. One gives only one first impression and that's definitely a good one. For the sake of simplicity (no configuration file, external call…) the default installation page in every language should be built in Core, of course. I'm considering a small piece of CSS hover (no need for JavaScript here) to tell how far this language is translated in Core—so that you can choose accordingly.
Further improvement: default language is guessed from browser language
Further improvement: default language is top-level
IRI in today’s Drupal: none

Let's say that Drupal comes bundled only with English—this is fine enough for me, since English is the reference language for Drupal development. If the user wants another language, Drupal will need to install a language pack accordingly. This will require some FTP access and some technical speech. Since so far nothing can be installed (we did not even set up a database), these instructions too should be built in Core. Much like the aforementionned one-minute install, one should be able to auto-install the right package (the present way not only is cumbersome but is also ambiguous: on a Mac, similar folders are deleted, not merged—and the user should not have to know that its remote server will merge, not delete).
IRI in today’s Drupal: /install.php?profile=default&amp;localize=true

OK, Drupal speaks in your language. Now, we can go technical. Here should be a profile-choosing page (“what do you want to do?”). I suggest nested levels of choices over one-page per choice. Why so? To keep the amount of required step down to a minimum without overcomplexifing the pages. So, a mix of nested level and multi-step. This “crossroad page” will then direct you to various profiles. Some examples (( ) is a radio button):

.... ( ) default install
.... ( ) custom
........ ☐ blog
............ ( ) single user
............ ( ) multi user, family (around 1-10)
............ ( ) multi user, farm (100+)
........ ☐  wiki
............ ☐  MediaWiki-like*
........ ☐  enhanced security
........ ☐  whatever

I suggest no more than three-level depth in this page. Less would lead to multiplying the pages, more would lead to too much complexity. This should be called "Step 1" (technically, this is step 2 or even step 3, but to for the sake of ergonomy, it should be step 1). Asteriks or links may be used for further explanations—here, “MediaWiki-like” means a bundle of revision, diff, wikitools, flexinode, talk, edit_section and table of contents modules (and probably others, too).

Then, depending on what you choose, the next page will ask you several questions. Answers will trigger (or not) the installation of various modules. This can be one module (like pathauto) or several (like WYSIWYG plus FCKEditor). I suggest a predefined number of steps so that Drupal can say "step x/y" - like step 1/4, 2/4, 3/4, 4/4), then arrange the various steps so that it fits in the framework.
IRI in today’s Drupal: none

For the sake of simplicity, let's assume now that we chose the default install.
IRI in today’s Drupal: /install.php?profile=default

Finally, some more juggling with files is required, again (duplicate /sites/default/default.settings.php as /sites/default/settings.php and give write access to it, create /sites/default/files/ and give write access to it). Once again, automate this!
IRI in today’s Drupal: /install.php?profile=default&amp;locale=<var>xx</var>

The install works, woohoo! Oh no! More lemmings FTP juggling

Now, you are suggested to remove the write permission on /sites/default/settings.php (Drupal doesn't check for /sites/default/, althoug he asks you to). Well, automate this too (it seems to be automated-it just doesn't work on my SFTP-only server).

OK, default installation is done. Could be harder, but could be simpler too.

Of course, it is not that easy. I go to the administration panel, as invited to and there it goes again. Issues.

  • HTTP request issues: Drupal can’t access some pages, I don't know why
  • no update notification from Drupal.org. May be related to the previous one
  • cron doesn't work (fixed with Drupal 7). So far, I'll use poormanscron

OK, this is a first draft. Your call!

wb54321’s picture

I wouldn't use any of the profiles. Not a single one looks like it's ready for production. Maybe I am missing the intent: are these meant to be used as sandbox installs to play around with?

Most come with extraneous modules; anyone who has built a few drupal sites would do a better job just adding the modules they need.

Maybe when the profiles mature to true Beta or Production release status they will have become usable. Meanwhile, I advise any beginner to avoid them.

studio77’s picture

Very good news - it is closer to the Drupal box from the store!