For many of the same reasons that we eventually decided to put modules in their own directories (which was long long overdue, and has opened up a great many new opportunities for more modular code), install profiles should be directories too.

Most importantly, especially to hosting providers such as bryght, is that not all install profiles should have the same sets of modules / themes.
Each install profile should have it's own modules / themes directory, allowing site hosters to have different configurations.

This is very easily used to build various pre-configured levels of sites, for different clients. etc. through the use of symlinks. The only other
alternative to this would be symlinking every single module that every single install profile should have access to to each individual sites
directory, and practically that is a nightmare.

I was fairly 'distraught' to find that we didn't even think of saving what profile was being installed with. That's very useful information.
Hence the patch also takes care of this.

an additional case is the administrator configurable defaults and overrides : http://drupal.org/node/25745

Currently, install profiles use variable_set to configure the initial site. However, in this situation, the 'reset to defaults' button will reset
the variables to the drupal default, and not the profile default (and this is a real concern when building install profiles).

What would be preferable is a profile.inc (or something) , that gets loaded which just has the $default['variable'] = 'value'; lines.
Additionally, these could be constructed from an already running site incredibly quickly using var_dump.

Additionally, there is the dependency work being done, with the aim of introducing .meta files into drupal, which are simple text files
that allow us to process information directly on the server. This would for instance be used to have the install profile 'requires: ' all the
packages it needs to ship with, and drupal.org could automatically package drupal-blog-4.8.2.tar.gz2, drupal-ecommerce-4.8.2.tar.gz2 , etc.

CommentFileSizeAuthor
#9 patch_831.96 KBmoshe weitzman
install_profile_directories.diff3.89 KBadrian
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Status: Active » Reviewed & tested by the community

i did an install and clocked around the admin pages with this patch installed. seems to work, and code is fine.

as an aside, i really wish we would use the term 'distribution' instead of profile. the profile word already has meaning for user profile pages and the profile.module for managing those profile pages and forms. not for this patch though.

adrian’s picture

adrian CreditAttribution: adrian commented

actually i think changing it to distribution is a fabulous idea.

Chris Johnson’s picture

Chris Johnson CreditAttribution: Chris Johnson commented

+1

Yes, this is a good patch. Without it, one would have to put all the modules into the full site view or symlink to each site directory.

I also favor changing the usage of "profile" to "distribution" as soon as possible -- maybe even in this patch, if Adrian wants to re-roll it.

adrian’s picture

adrian CreditAttribution: adrian commented

I didn't roll the patch. chx had to help me. =)

Plus there's a lot of stuff to change. Including the file suffix etc. I'd prefer we just get this patch in first, since renaming them
has little to do with putting them in directories. Although

Dries’s picture

Dries CreditAttribution: Dries commented

Can someone provide some concrete use cases of why you want to put modules in the profile directory? What is wrong with putting them in the modules directory?

eaton’s picture

eaton CreditAttribution: eaton commented

Dries, I can think of two specific cases:

  1. A drupal hosting provider wants to offer several pre-built drupal packages built around specific combinations of modules and themes. Users will be able to turn them on or off, and some will be pre-installed while others won't be, and they'll be able to add modules to their own sites/foo.com directory, but the 'core packages' involved shouldn't be editable by the users. This makes that possible without using piles and piles and piles of individual symlinks.
  2. A specific distribution of Drupal for a particular audience is developed and packaged. Let's say, Drupal For Bloggers. Keeping modules, themes, and the profile setup script for that distribution in a single directory (separate from user-added modules OR core modules) makes support and subsequent updates much simpler. It also makes installation simpler for the end-user, who only has to download the packaged 'distribution' or 'installer profile package' with modules, themes, etc, and drop it into the /profiles directory.

Figuring out how profiles will actually work in the real world has been a hot topic of conversation, and I think this patch helps us move things much closer to a usable system for custom profile packages that are friendly to the end-users in addition to the developers.

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Reviewed & tested by the community » Fixed

Eaton, that makes a lot of sense. Thanks for the clarification. Committing ...

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Fixed » Needs work

I'm marking this active again. Eaton explanation is really valuable and not necessarily obvious. It would be good if this was documented in the code. Maybe the system_listing() PHPdoc could be extended to provide a little more background/rationale about why it does what it does?

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Status: Needs work » Reviewed & tested by the community
FileSize
patch_831.96 KB

looks like adrian's patch got committed... here is a patch for system_listing() docs. feel free to keep improving it.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Status: Reviewed & tested by the community » Fixed

Committed to HEAD, with editing for line length and capitalization.

sanketmedhi’s picture

sanketmedhi CreditAttribution: sanketmedhi commented

I don't understand why symlinking appears to be such a nightmare to most.

How about having a /modules directory for keeping all the modules and then having a separate sites/example.com/modules/ directory to store symlinks for each module that is enabled.

For example, there will be a whole bunch of modules in the /modules/ directory, and each site can enable a particular module by creating a symlink to that module in its own /sites/mysite.com/modules/ directory. The web interface can be used to do this.

This is somewhat similar to the runlevel structure of GNU/Linux systems, and feels quite worthwhile to me. Please correct me if I am going wrong somewhere. I am still a beginner :D

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

Symlinks are not an acceptable requirement. People who do not have shell access to their server might not be able to create them, I've never heard how well that pattern works on WIndows servers (I assume it is fine), and it creating another barrier to getting Drupal running. (I personally use symlinks in my Drupal installs all the time, nothing is stopping it.)

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)