Talking about the state of module management in drupal has got me thinking..

http://drupal.org/node/105182
http://drupal.org/node/105191

6.0 seems the better place to put this, so I’ve switched the versions.

Ultimately, the module system would work best for me like this:

1) I choose the module I’d like to install on drupal.org.

2) Drupal.org makes a note of my choice, adds the module to my tracker and then notifies me of any updates (preferably my drupal install will also check daily to see if there are updates to modules and let me know)

3) I point my web-based admin panel to the file I want (either by node/project number or as a full url)

4) My drupal checks the dependency system and notifies me (ala redhat/centos rpm install) that there are more packages I need to install before this one. ** Does this for me, downloads dependency check those, etc etc. **

5) My Drupal admin downloads the file ala webmin module system and unzips if needed, adds, asks to install, and installs. (ie, no files on my local hd – drupal manages version numbers)
I agree a lot of the comments in the forum recently that the new versioning system is no good. Every new release needs to have a number (no more dev / 1.x / head).

6) Module page comes up to reflect my new addition. Notifies me of any issues.

7) *new module has a special div* something to indicate at a glace that this is the one I chose, these are the ones that were added automatically. Brighter colors, etc.

8) The name in the module listing links to the primary settings for the module. From here I can single-click to get to the page to set up what I need. If there is more than one page of settings everything is in tabs. For me this is key. The module page should do more than just turn on and off. Theres no reason to have me hunt for the category that the setting goes into, task-based work might make sense to some, but what really needs to happen is a direct link to “I installed X module” = “Click X (name of module) to configure”.

9) The new *features * of the module go into the description and are hyperlinked. (ie provides calendar [link to create content / calendar]) This should look like the dependency listing that’s there now, only be hyperlinks to real new functions.

10) Drupal logs/ status system is updated to include an entry for my new module. If I ever need to submit a bug I include the output of this status page which lists

• all the module I have on the server,
• which ones are active,
• whether or not I have visited the default settings page for each
• what the version of each module is
• and detailed info about my drupal / php / apache etc install

11) (yes there is more) This module below is somehow extended to extract the "features" of the module. It finds all the new functions and lists them in a central help repository.

http://drupal.org/node/66983

From here I can see a list of what each module provides in function (since the module will read the comment-code that describes the new function). I’ll be able to call these functions from my php wherever in the site, or create new modules that use these functions directly.

Think a live local wiki / code test. Something to test the module to make sure its working, the functions – function, and show what it does and what to call to use it.

--

I know this is a lofty list, but I'm so friggen impressed with 5.0 I want to make sure I get my $2.00 (forget .02) in on 6.

-v

Comments

BioALIEN’s picture

BioALIEN commented

Impressive post. While I agree with the general scheme, some things mentioned are a little over the top or require extra complexities. Most site administrators are paranoid by nature. I see a relation between an admin's desire to enable the drupal.module and the desire to have their server communicate with drupal.org to fetch version numbers etc. So the step you've outlined could be linked into the drupal.module.

Your comments regarding version numbers: A few module maintainers are still getting this sorely wrong, but the new versioning system is definitely an improvement.

As for the logs, I don't think its feasible to generate a full list of all modules on the server, active/inactive, whether I visit settings etc as this is what the Module overview page is for. For support, screenshoting this page and it will get the point across rather than waste database space collecting useless logs. PHP, Apache etc versions are all found in the Status page and that's already available for D5.x

So in essence I will have to:
+1 the idea of choosing modules to subscribe to on drupal.org so that you can receive notifications if you are a site admin (ala security tracker but per module).
+1 the idea of uploading a tarball for module installation - this will make life easier for admins who are on the go.

Not sure about any security implications, but its all basis for discussion.

chx’s picture

chx commented
Version: 6.x-dev » 7.x-dev
Priority: Critical » Normal
ñull’s picture

ñull commented

I would like to see another feature related to modules:

At the moment there is a simple dependency system based on names, but sometimes or more often modules don't only depend on each other in name, but also in version. May be module developers should be forced to follow more the Drupal core policy related to version numbering and compatibility, but at the same time I can understand that in the excitement of development this was sometimes overseen or some bugs simply need a correction that could make depencies fail. I would therefore extend the dependeny system that you can indicate the minimum version number of the dependent module. Especially useful when a module is still in an instable development stage.

ultimateboy’s picture

ultimateboy commented
Status: Active » Closed (duplicate)

There is a lot of work going on in terms of module selection and installation for d7. For now, lets focus on that http://drupal.org/node/336743