[documentation] [Documentation task] Installing new modules
Amazon
drupal-docs at drupal.org
Thu Jun 15 16:09:30 UTC 2006
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: Amazon
Status: active
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
Amazon
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.
------------------------------------------------------------------------
Fri, 19 Aug 2005 21:52:24 +0000 : sepeck
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.
------------------------------------------------------------------------
Sat, 20 Aug 2005 05:30:58 +0000 : dopry
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.
------------------------------------------------------------------------
Thu, 15 Jun 2006 16:03:43 +0000 : rivena
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.
More information about the documentation
mailing list