regarding:
http://drupal.org/node/17473

for easier upgradability I should drupal users should be directed to install contrib modules in sites/default|/modules instead of modules.

1) it allows users to get a better view of which modules they have from contrib.
2) Its really easy to copy the sites folder to an upgraded drupal install.

It isn't a solution to major upgrades where modules need to be upgraded as well, but would make the bug fix upgrades easier for most users.

Does anyone know if sites/default/modules gets loaded for all sites sharing the same codebase? I couldn't really tell browsing through the code today. Just thinking of ways to make the upgrade path easier.

Comments

sepeck’s picture

sepeck commented

-1 contirb modules should be in a named sub directory of modules (e.g. modules/image/image.module). This makes them available to all sites in a multisite install and identifies them as contrib modules. Individual modules under default or other sites directories are for modules that are custom or not to be generally available.

boris mann’s picture

boris mann commented

Actually, I partially disagree, sepeck.

For single-site installs, this is a great solution, and does indeed separate all of contrib nicely from core. It's probably worthy of a best practices write up specifically for single sites.

Kobus’s picture

Kobus commented

How about just creating a folder *inside* the modules folder, say, "contrib" and put all the modules in there? Drupal is able to read through a directory structure to detect modules placed in there?

Regards

zirafa’s picture

zirafa commented

Alternatively, how about putting all the core modules in a 'modules/core/' directory if you want to distinguish contribs from core?

dopry’s picture

dopry commented

For easing administration it would be nice to have contrib modules in their own tree. Whether it's in modules/contrib or sites//modules isn't important to me.

What is important is the ability to readily recognize what needs to be moved to an upgraded installation.
I don't want to simply copy a new version of drupal over an old installation, because it leaves me without an easy regression path. I can always pull backups, but thats too time consuming.

I setup applications on my webserver like:

/srv/www/apps//application-x.x.x
/srv/www/apps//public_html -> application-x.x.x

Currently my upgrade process for drupal goes something like

untar new drupal in
copy sites to new version
go through the modules directory looking for contrib modules and copy them individually to new version..

I run into situations where users have installed modules in the modules dir instead of a sub dir, so I can't effectively list the directories and copy them over. I have to do it by hand....

If there were a unique tree for users to work in I could grant them permissions to only their part of the tree as I do with the sites tree in current shared drupal installations. As it is I have to give them write permissions to modules to install new modules which also allows end users to edit core code without letting me know they plan to.

I don't want to create a discrepancy between official documentation and how I tell end users to manage their drupal installations. That will just lead to confusion. Maybe this is a theory with greater scope than documentation.

Regardless I've always considered it good practice to keep customizations seperate from a core distribution, that depends on upstream for updates and fixes.

Just some thoughts for file system layout and usability.
rip apart, flame away, disagree, correct, maybe partially agree they're all welcome.

.darrel.

sepeck’s picture

sepeck commented

http://drupal.org/node/22283 - http://drupal.org/node/17473
Current and past practice has been to advocate each contrib module in it's own sub directory in modules. With the addition of multi-site capability the ability to have site specific modules was added. Other than mention in the install.txt, no real updates have been added on 'standards and suggestions'. I like the flexibility we currently have.

How about you add a child page to the original reference for your more complex site file management and I pull from that and add a link to it to an expanded file management update of the best practices section with the explanation of consistency. The most important part to drill into people is consistency in managing their contrib vs. core modules after all.

It had not occured to me to allow people to add their own modules on sites I host. Where you allow users to add modules, then under their sites directory seems to be the best place. I need to retest that scenerio under IIS again, last time I did something wrong and if I had duplicate modules anywhere, then I had problems.

dopry’s picture

dopry commented

I like the currently flexibility we have, but I think with a little thought it can provide an easier approach to administration, and a more flexible/modifiable/stable multisite installation without impacting performance.

Take your duplicate modules problem as an example. In a multi-site setup this should be a problem. If a module is in the sites directory it should be loaded in place of the general module, allowing for site specific configuration to override the base distribution/shared configuration. It would allow site to have customized core modules and contrib modules that won't butt heads with the stock modules. *I'll pitch the idea on the dev list and make sure this hasn't already been addressed, if it gets a few +1's someone may make it so, or I may make it so*

It opens a whole new can of worms for developers who want to jury rig stuff or drop in a module for testing, also allows end users to jink with the code of a module without messing up the overall operation of a multisite installation. Just some loose ideas...

But the real goal is to stress a consistant handling of contrib modules... regarless of the boohooey I keep yammering on about. I'll find the time this weekend to make a write up. I have to finish up a demo for another app that I have to demo on monday.

.darrel.

rivena’s picture

rivena commented

I am looking at old issues to see what can be closed.

This one talks about putting contrib modules in the sites folder. I saw a similar recommendation published in a Drupal Newsletter... is that sanction enough to put it in the install modules page?

Speaking as the person who wrote the install modules page, dang, that's a lot of words... It needs an update.
http://drupal.org/node/17473

Anisa.

Amazon’s picture

Amazon commented

I would certainly relabel the page installing Drupal modules in 4.6 and earlier. I'd then make a new page tagged 4.7 with the same title and make this page a child page.

Kieran

robert castelo’s picture

robert castelo commented

I took Amazon's suggestion and renamed the page, tagged it for 4.6 or older, and created a new version tagged for 4.7.

I've also updated the 4.7 version of the page, and will work a bit more on it over the next few days to explain the new install process.

Tresler’s picture

Tresler commented
Assigned: Unassigned » Tresler
Status: Active » Fixed

Marking as fixed:

The aforementioned childpage was created for 4.6 and before.
The current page addresses 4.7 and 5.x
This was obviously highly addressed in the 5.x upgrade, and we now have something similar with the divide between /modules for core, and /sites/all/modules fr contrib global, and /sites/mysite.com/modules for site specific

Re-open if we need further discussion.

Anonymous’s picture

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