[drupal-docs] [task] Installing new modules

[sepeck]

Issue status update for 
http://drupal.org/node/29180
Post a follow up: 
http://drupal.org/project/comments/add/29180

 Project:      Documentation
 Version:      <none>
 Component:    Installation
 Category:     tasks
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  dopry
 Updated by:   sepeck
 Status:       active

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.




sepeck



Previous comments:
------------------------------------------------------------------------

Fri, 19 Aug 2005 06:46:45 +0000 : dopry

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.




------------------------------------------------------------------------

Fri, 19 Aug 2005 08:21:09 +0000 : sepeck

-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.




------------------------------------------------------------------------

Fri, 19 Aug 2005 08:25:57 +0000 : Boris Mann

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.




------------------------------------------------------------------------

Fri, 19 Aug 2005 10:19:26 +0000 : Kobus

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




------------------------------------------------------------------------

Fri, 19 Aug 2005 10:44:23 +0000 : zirafa

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




------------------------------------------------------------------------

Fri, 19 Aug 2005 19:46:36 +0000 : dopry

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.