New module administration page with many new features

Nice work, Earl! Looking good so far.

However, I don't think that the modules listing has been broken up enough. IMO, one of the biggest benefits that we need to see from a 'modules page' rework is a reduction in the number of modules that the user sees on the page at any given time. Breaking it up into 'enabled' and 'disabled' pages is a good step in this direction, but I don't think it's enough. The listing also needs to be broken up according to category.

I have considered two possibilities for achieving this break-up using the menu hierarchy, but I don't think that either of them will work very well. The first possibility is to have all the 'categories' as second-level tabs, beneath 'enabled' and 'disabled'. Considering the number of categories that will probably exist for modules (the Drupal.org module categories page gives us a rough idea), this will result in way too many tabs. The second possibility is to change 'enabled' and 'disabled' from tabs to normal menu items (i.e. menu items that appear in the navigation tree), and to make the categories appear as normal menu items beneath them. Don't think that this would be terribly good from a UI perspective either.

I have another idea, which I think will provide a better UI experience than using more menu items and/or more tabs. We could remove the 'enabled' and 'disabled' tabs, and instead, we could provide a filtering form, similar to the one found on the 'admin/content/node' page (formerly 'admin/node'). The form would look something like this (sorry for the 'ASCII mockup' - it's easier than doing a graphical mockup, especially with the select box options):

"Show only modules where:

Status is: [(select) enabled | disabled | installed | uninstalled]
Category is: [(select) required | core | ecommerce | uncategorized | etc]

[(button) filter/refine] [(button) undo] [(button) reset]"

We could set it to have a default filter of status 'enabled', and category 'core'. What do you think?

One comment on the screenshots - I believe the "install" and "disable" links should be buttons. I believe the html spec says that only buttons should be used for operations which impact the server.

In addition to being "what the spec calls for" using buttons prevents problems with some browser extentions. Certain web "accelerators" will follow all links on a page which has disasterous consequences for pages like this.

The only other bit of input I have is the use of the word "enable" in place of "install". It's a subtle difference, but if I "install" pathauto for the first time it does actually install it, and then I can disable it. It looks like your screenshots would then allow an "install" of pathauto when all that is really happening is "enabling" it. If we actually had "install" vs. "enable" vs. "disable" vs. "uninstall" as distinct operations under the hood (which may make sense at some point) then I think the wording would be clear. But from a user perspective right now I think that the tabs and the wording on the page reflect the concept of "enabled" and "disabled" and therefore the "install" link should be changed to "enable".

And...LOOKS GREAT! This seems to me like a definite improvement over the current screens.

"Actually, I do in fact plan to use install vs enable" ok, then I guess that works great.

And buttons don't have to take up a lot of space. Just the default size makes them take up lots of space.

To be honoust, I'm not very fund of the buttons and would be much happier to see the links-like approach. That way it's easier to theme them, and would even improve the look-and-feel of our administration area.

It is also much more consistent with the rest of the administration because mostly, we have links in the 'operations'-rows instead of true submit buttons..

1) I love how everything is laid out but I think that the headings need to be clear and consistent throughout the administration interface. See the admin headers for an idea of how the different sections could look. I'm guessing that somethings like this is in the works, as that was your patch after all.

2) If you are going to be doing the buttons think that they should be somewhat symmetrical. The install button looks small to me.

3) Is it just me who thinks that module names should be capitalized? It makes sense in my mind and would make modules look less wimpy, if that's a good description.

4) How are the sections going to be made? I am currently guessing that this will be based upon the directory structure. If so, are you planning to have nested directories within this structure? This could be a worthwhile feature in my opinion - I'll use the E-Commerce module as an illustration. If this project were to group related modules into folders sorting everything would be much clearer. Payment gateways, product types, shipping calculators and pricing modules would be grouped together nicely.

5) Building off of the last point, is the new block administration system going to address dependencies? If so, this could be done by parsing the directory structure as well. For example, for the ecommerce system to be considered functional core modules plus one payment gateway and one product type must be active. In my opinion, the status of the entire package should be evident in the blocks section for maximum usability. Maybe there would be a small message under the category listing alerting the user that the module package has dependency issues.

Hopefully I didn't go too far with the ideas, scope creep can be a killer. I'm guessing that a lot of this is redundant for those in the know anyways. Thanks again for the mockups.

To chime in on the categories vs. packages debate, I'm definitely in the packages camp. Earl gives this list which I think is bang on:

"enabled, drupal core, contrib, views, ecommerce, cck, links, organic groups"

What I propose is this exact categorization with one (and only one) more level of nesting for particularly large projects to break things down further. Top level packages should be distinctly marked while sub-sets of packages should maybe be given a bold header Here is what the structure could look like, with views in the contrib folder to spice things up:

drupal core
- list
- modules
- here

contrib
- views
--- views rss
--- views core
--- views ui
--- views theme wizard
- webform
- tiny mce
- img assist

cck
- content
- date
- text field
- number
- user referance

ecommerce
- core
--- store
--- cart
--- payment
--- shipping
--- product
- product types
--- auction
--- custom
--- service
--- tangable
- payment gateways
--- PayPal
--- WorldPay
--- COD
--- Linkpoint
- shipping
--- shipcalc
--- ship basic

organic groups
- modules
- here
- etc...

I think everyone gets the picture.

Please don't change the title as it affects the whole issue.

@merlin it looks great to me!

@stefan - while links may be more consistent inside drupal, they are not consistent nor very safe for internet use in general. Most of the time in drupal admin interface a link to take an action will link to a confirmation page - the confirmation page will have a button. For example, admin/comment/list/approval has links to "edit" or "delete" but either of those links takes you to a form with a submit button.

In this case I think buttons - themed to be skinny - are more appropriate.

So far the patch looks good.

There is an issue with the sorting on the disabled page...

The 'required modules' key of packages is empty and throws a bug in the foreach on line 1289 of system.module.

I kind of prefer the old checkbox method for enabling and disabling modules. Merlin and I talked about this in IRC... Its technically more clicks with the checkboxes, but I see it as more round trip time to the server...
I'm more concerned about page requests than clicks.

I also see buttons as more prone to accidental clicking.

merlinofchaos, expressed the argument of a rarely used feature after install as a justification for removing the batch capability of the checkboxes. I think the rarely used after install feature should indicate that this thinking is flawed to some degree. If I install e-comm or cck... I've suddenly got a bunch of round-trip page requests to wait on... If I just installed drupal... My first impression of drupal is a bunch of round trip page requests to wait on while I enable modules.... on those rare occasions that I disable or enable a single module after the upload is the two clicks + submit and harder than 1 click + submit...

I also think refining interfaces shouldn't particularly require a slash and burn approach as it involves a change in the expected ui for experienced users, and additional learning curve on upgrade.

I think we can accomplish the same goal of expressing dependencies with less impact on the user interface, without losing the batch operations features by using check boxes and the disabled attribute, and allow on activation setup through the settings link ++ newly installed module indicator or batching the configs for each module into the follow page using fieldsets.

I almost think it would be nice to see uninstalled modules on the second tab, and eliminate the disabled tab. Depending on the checkboxes to indicate enabled and disabled status.

However, the dependencies and groupings that are being included in this patch are far more important than my personal opinions about checkboxes vs buttons. I can form alter to get the ui I want for myself... ;)

so in the end a +1.

I'm submitting this patch to hear your comments before I get too carried away with it.
This patch includes all Earl's previous changes.

Please find the new meta descriptors for testing this patch here: http://drupal.org/files/issues/meta.tar.gz
Comments and suggestion on the descriptors are being followed in this thread: http://drupal.org/node/76549

Progress:
We've implemented Steven's file parser and moved away from .ini files.
Added drupal version checking which is implemented to validate from major version numbers downwards. eg. if the module specifies version 4.7 and the drupal version is 4.7.2 it will succeed. If the module is only written for 4.7.2 then it has to be stipulated as such.
Bug fixes corrected and code has been cleaned up to ready for cvs commit.
When disabling a previously enabled module and it's dependencies you were not able to uninstall it, this is now fixed.
To start prettifying the screens I've placed all the packages in one table to keep the spacings the same. The package header class="modules-header" and the table headings class="modules-heading" can be styled separately. Please give feedback on this.

As per usual your feedback and comments will be appreciated.

Darrel: I agree with you on the multiple round trips to and from the server. You also mentioned the ecommerce set of modules which I experienced in the past if you do not enable all 5 the required modules at the same time that it messes up your whole installation.

The buttons work well and they are very descriptive about the action you are taking. Someone has suggested in the past that we could use javascript to simulate the actions and have the form submitted in one submit.

This will require the dependency checking to move down to the client for you to be able to enable the dependents. The dependency system is much simpler now and this might very well be possible. Setting hidden variables and prompting the user to save unsaved data before submitting. Possible but is it viable?

As far as ui changes are concerned I think its brilliant. Every release should give you a brand new experience. You can still do everything you could with your previous release and the fun part is looking for the screens as you experience the new release that is obviously different than the previous one. It shows that progress has been made and gets me, personally, very excited to discover the new features I've been promised. YMMV

I'll say it again... I'm new here please excuse me. *blush*

Theming to remove hard coded html tags.
Proof of concept for a patch on theme.inc to be able to identify a table's cell as a header. Please have a look and give your comments and suggestions.
Thank you in advance...

This patch replaces all previous patches.

Patched again without overwrite typing mode. *blush*

@merlinofchaos

Why not a hook_meta()? Similar to hook_info(). I think it's much easier to handle.

Missing protection of .meta files from prying eyes.

New patch as per changes on head.

Fixes:
Removed all tabs and only patched additions and changes.
Typing mistake in variable name fixed
Buttons have classes added for styles sheets
Formatting and coding standard cosmetics

Tested with new head install drupal, enable disable uninstall of modules seems working please test and give your feedback.

Your suggestion and comments will be valued.

Style sheet patch for drupal.css to prettify the modules table.

You will also need these descriptors: http://drupal.org/files/issues/meta.tar.gz
Unpack into your modules directory.

Reapplied to latest HEAD.
Great work guys. The only thing that bothers me are the operations buttons. I would preffer if they were positioned closer to the module name.

by request, here are the 2 screenshots from safari 2.0.4. first, the enabled page.

and here's the disabled page, same browser.

This looks awesome! Can you really *uinstall* modules? Just comment to track this thread for now, hopefully more thorough review later.

Tested working looking great. I think Earl has incorporated all the feedback and ideas from the past into a master piece that everyone can happily accept and enjoy.

Lets move this along before HEAD runs away from this patch again. +1 RTBC

I absolutely love this functionality. LOVE IT!!

Some comments:

1. It needs to be made WAY more clear than it is right now that uninstalling modules is totally destructive. By playing with the interface, I managed to delete all of my primary links and menu customizations, all comments on my entire site, all the taxonomy terms and vocabs I had setup, etc. It's just a test site, so I don't care. :) However, an new user randomly clicking stuff to see what it does is going to be in for a world of hurt.

Ideally I see this happening like:

1. I go to uninstall the Taxonomy module
2. Drupal checks to see if I have any data in the affected tables.
3. If so, Drupal pops up a confirm_delete form that says:

Warning! You will lose the following data if you uninstall this module:

[insert table containing stuff ... probably like (pseudocode):

foreach ($affected_table):
$results = SELET * FROM $affected_table LIMIT 30
theme('table', $results)

]

Are you sure you wish to continue?

[confirm] [cancel]

2. Stuff in the variable table remains in the variable table for uninstalled modules. Not sure if this is a big enough thing that it's worth bothering with, but figured I would point it out.

3. At the DC training we did a couple weeks ago, one of the students pointed out that one of the biggest challenges to getting around Drupal is that "stuff" for each module is everywhere. While this patch goes a long way towards solving that problem, there are still other places you conceivably have to go. For example:

• Does this module define permissions? If so, it should show a link to access control.
• Does this module have a help page? If so, show a link to it.
• Does this module offer settings on the node settings form? If so, show a link to content-types configuration.
• Does this module provide a "view" interface, like tracker? If so, show a link to that.

Obviously, this will get really wonky if the perms continue to be displayed like:

administer, settings, blah, blah

So I'd suggest making them into a bulleted list or something, displayed vertically. Then they can be added to at any time.

4. I see that in the .meta file it defines said links. Just curious, could the same thing be done by parsing hook_menu() , or is it better for it to be created dynamically?

That's about all I can think of for now. Excellent work on this patch. :D

I don't know exactly what's up here, but when I go to either admin/modules/enable or admin/modules/disable, I get no table of modules. I suspect it has to do with:

  foreach (array(t('Required modules'), t('Drupal core modules')) as $key) {
    if (is_array($packages[$key])) {
      $top_array[$key] = $packages[$key];
      unset($packages[$key]); # by the time this finishes, $packages is empty because I only have required and core modules.
    }
  }
  if (!$packages) {
    # so it stops here.
    return t('<p>There are currently no modules that you can enable.</p>');
  }

@webchick the test for (!$packages) caused the problem. Changed to (!is_array($packages))
Try the new patch.

Yep, that fixed it!

Now onto the review stuff. :P

Here's a screen of an improved interface.

I moved the links below description, this makes sense, they are *not* operations... operations is really only disable/enable/uninstall ... a link to admin isn't an operation.

It's not 100% polished but I think it works out better. Thoughts?

Here's another screen shot, further improved. This one changes the focus to the actual links, instead of description. This makes more usability sense, the description should be supplementary, the links more of the focus.

Added $confirm and information messages to hook_uninstall on all modules that have drop db queries.
Added variable_del to these as well.

Here's an updated patch. A few things:

- all meta files are now part of the patch; no need to download those separately
- lots of CSS cleanups, more tweakings to the interface
- a couple tweaks to the outputted HTML and links

Note, this patch uses a custom system_links to work properly. This patch shouldn't really use this-- http://drupal.org/node/65151 is the real solution, but that needs to be commited. Depending on when that is commited we'll update this patch or that one accordingly. Shouldn't hold up this patch though.

Here's a screenshot of what the new interface looks like with the above patch.

Updated patch, cleaned up a few more formatting issues.

Just occured to me, if anyone else tries to make a patch they will have to hack their CVS/Entries to include the meta files too. To save everyone the hassle, here is my drupal CVS folder zipped up. Just extract this, run cvs update -dP, modify files and create patches with cvs diff -N to add those new files in.

Ok, possibly becaue I'm stupidly tired, I couldn't get the above install to work (kept saying mysqli_something_something was not defined), so here is attached my meta.tar.gz with updated links.

What I did was:

1. Added all of the "main" links to each module. For example, news aggregator=aggregator to aggregator module (but not aggregator/feeds because that's accessible from aggregator). The idea behind this is that currently, when you enable a module, there are approximately 80 gabillion places you need to check to see what the module changed, unless you are proficient in reading hook_menu(). My goal is to put all of these "jump off points" in one spot.
2. I took out references to "content type" settings. These can (and should imo) be generated programmatically instead, as manually it is too error prone.
3. The spacing of the = in links was inconsistent (sometimes it was name=link and sometimes it was name = link), so I went with name=link across the board to save about 12 bytes. :P

So basically, links: is just a list of kind of "oddball" links that can't be parsed out programmatically (and believe me, I tried ;)).

To be done:

1. Roll a patch for "add X" links for node types.
2. Add back in the aforementioned "content settings" links. They should appear for any node type.
3. Something else that would be *really* cool (don't know if it's possible currently) is create a link for any module that alters the node settings form (comment, upload) to the content settings page as well.

I don't know if I'll be able to work on either of these before the code freeze. :( I hope someone else can pick up the chain here in case I can't. It would be a tremendous usability boost for Drupal.

New patch including the new meta files from webchick.
Added .install files for hook_uninstall on modules that have variables.
All variables can't be cleaned up properly as we have variable variable names but this should not be an excuse to keep this patch up. ie:
upload.module

      '#default_value' => variable_get('upload_extensions_'. $rid, $upload_extensions_default),

amongst others...

Fixed a bug that sidestepped the programatically retrieved links help and permissions.
Moved help and permission to the front of the list, seems more aesthetically pleasing.
Changed heading because there are no links on the disabled page.
Major code cleanup and comments.

I want to urge again please give your attention before HEAD runs away from this patch again.
Lets move this forward... any comments? RTBC?

Screenshot teazer for you guys who just want to comment and add your +1

You will need to follow these instructions :
http://drupal.org/diffandpatch#comment-147010
if you want to create a new patch against HEAD and also include the new files in the patch.

Taking my first look at this. http://drupal.org/files/issues/s2.png

Good overall. What I think improves the usability -

-- Merging "enabling" and "administering" into a single place. Having to turn on a module and then find its settings somewhere else is a pain.

So let's keep going in this direction.

What I believe not a good change (because it would not matter to me as a normal "clueless" admin) -

-- The grouping of "required" modules with "core" modules (and I assume there will be other groupings). Instead, how about if all enabled modules are in a single list, but the ones that are "required" just do not have a Disable button - instead a piece of text with says "Required"?

I know this is what it is like today - in my view, today is better in that regard.

Perhaps as a compromise, a way to sort the modules - default is by name but if someone wants to sort by the last column (or sort by a new column called "Module type"), then you have groupings the user can control. (Being able to group by version could be very useful, too.)

Also, one thing that is not clear to me yet - what happens when you "enable" a module - it SHOULD go to the admin or settings page for that module, instead of returning to the list of modules. After you are done with the admin screen, then you should return to the listing.

But overall, this is a great improvement. It surfaces an interesting issue - what is the difference between "administer" and "settings"? When you bubble up features like this, it makes those subtle differences more important.

Great work buddies. The new module page looks awesome!

A few suggestions to make it better....

1. It would be great if we can have links pointing to the module's web page and/or documentation page
2. If possible, using AJAX for editing module permissions, settings, etc. instead of another page
3. Categorization of modules like on the Drupal.org/project/Modules/category page

These are just suggestions. It depends on the devs to decide what is feasible and practically possible to implement.

Thanks a lot for this great patch!

New feature request as possible fix to issue razed in
#63 problem deleting variables in uninstall with variable variable names
(that's the last time I'm going to say variable variable *dang*)

http://drupal.org/node/79792

This is more than a good patch -- it's an important patch. As Drupal is dependent on modules for almost all of its functionality, a clean interface for managing them is really, really important. For those who haven't been keeping track, it brings us the following:

1. A dependency system, so modules can announce what other modules they depend on
2. The ability to completely uninstall a module, along with all of its tables. This is very useful when trying out assorted modules; right now, it's easy to end up with dozens of tables, stray settings, and so on littering the DB.
3. Visual grouping of different module packages. CCK modules, eCommerce modules, Links package modules, and so on could all be grouped easily.
4. Links right from the modules page to relevant settings/configuration pages. Many people have complained about the difficulty of figuring out where a given module's configuration options show up after installing it. This provides easy pointers the moment you install.
5. A much cleaner user interface, where installing is a straightforward action rather than a 'state' that a module can be in (checkboxes, boo)

I've taken it through its paces installing, disabling, enabling, uninstalling, configuring, etc. It's important.

There are some minor UI tweaks I think could help it -- I'd rather not see the 'required modules' list ever shown, because they are effectively baseline drupal features that *happen* to be implemented as modules, but that's a minor nit to pick. I'd also like to see a more explicit page title saying 'Enabled Modules' and 'Disabled Modules'; it took me a minute to realize that the list was so short because the enabled/disabled tab had been added. But that, too, is a nit to pick with a patch that is very, very important and very broad in its scope. Arguing about those finer details is something that can be ironed out in a subsequent patch, as people figure out whose aesthetic tastes are better.

This patch needs to be committed; 4.8/5.0 is getting major improvements in almost every area, administration being a major one. This is an important part of Drupal's growth into a truly user-friendly (AND powerful) CMS.

This patch is RTBC.

Thank you eaton.

This post is probably not necessary anymore but it just dawned on me that I can patch the patch. If you really do want to patch some more on this you can do this cvs patch to your patched cvsroot to create all the entries for new files. Redundant information #65

I'm happy to see the day that this patch is going to lie down and rest with the other great patches in Druplicons warm belly in the sky...

No, I think patches-on-patches would just complicate this excellent addition. Things like hiding required modules, etc are minor quibbles and really should be left until after the core functionality is committed. Even the *ability* to cleanly hide required modules is something that would be aided by this addition.

Also, one thing that is not clear to me yet - what happens when you "enable" a module - it SHOULD go to the admin or settings page for that module, instead of returning to the list of modules.

We can't really do that... not all modules have admin or settings pages, and some have both. Also, if you want to enable several modules at once, it would get very annoying to have to keep clicking back to the modules list in between.

If possible, using AJAX for editing module permissions, settings, etc. instead of another page

I think that's out of scope for this patch, but could possibly be added in as a later improvement.

It would be great if we can have links pointing to the module's web page and/or documentation page

Yep, this happens in the most recent version of the patch -- each module gets a link to its admin/help page, if found. nickl fixed a problem with it displaying.

Oops, too slow. :)

Not only that, but now I'm off to work on the JQuery patch. Hopefully that will hit too... then we can spice up the admin page with some nice and useful effects, maybe even some AJAX-y too.

BTW, any existing changes are cosmetic; at this point I want to hold off on making them, and create a second patch of cosmetic improvements. I'd like to get the core of this patch in.

I vigorously agree.

Here's an updated patch with some more CSS fixes, along with fixing the problem of long descriptions squishing everything else.

Just tested out this patch, and it works very nicely for me.

One problem that I noticed: forum depends on taxonomy, but this dependency is not specified in forum.meta. The dependency should be defined. AFAIK, this is the only case of a core module depending on another (non-required) core module.

Another problem: this patch should be removing all instances of 'admin/settings/modules#description' in hook_help(), and instead using the description from the meta files on the modules page. If I'm not mistaken, the patch ATM is leaving duplicate copies of the description text in both these places.

Jaza you're right, plus Nickl says we are missing some install files now too. We need to address both of those issue first.

Updated patch. Includes those missing *.install files, along with removing 'admin/settings/modules#description' references in each module file.

Only issue, you can't translate that text unless you edit the meta file. Can we throw t() in there? Probably left to be discussed in another issue.

subscription

Add this line to forum.meta (see #79):

dependencies: taxonomy

Question. If the data in meta files is used at install time for determining dependency and such, why is it not just in the .install file?

Updated patch with Jaza's one liner fix in there.

1. What is the difference between "administer" and "settings"? For people new to Drupal, the distinction won't be clear. We should optimize this page for those people.
2. Personally, I think there are too many links. It starts to ressemble an airplane cockpit. Rather than focusing on the task you accomplish directly after installing a module, it now seems to become a central hub for all administrative tasks (an alternative dashboard). I'd prefer if we'd enforce good practice and consistency. I feel that we haven't put enough thought in this yet, and that we're trying to rush the UI. Let's keep in mind who we are writing this force and how we prevent that module maintainers add their kitchen-sink to the list of links.
3. Incorrect use of tabs: tabs should be actions, and tab names should start with a verb. Consistency is important. If we don't enforce guidelines in core, then who will care about them?
4. "Related Links & Description" should be "Related links and description". Again, we don't capitalize each word in a sentence.
5. Why are dependencies shown in red? I thought something was wrong while in fact, everything was fine (eg. I already had the taxonomy module enabled). Why do we show dependencies to begin with?
6. The 'version = SYSTEM' stuff is weird-ish and wasn't intuitive.
7. The meta file parsing is ugly. Why can't we use PHP's ini functionality? That seems to be 5 times cleaner. If there is a good reason, please document it in the PHPdoc because virtually any other developer will ask the same question. If there is no good reason, use PHP's built-in ini functions.
8. The '!$confirm'-tests in each _uninstall hook are weird-ish.
9. Please don't use the term package. Drupal uses modules, not packages. If we introduce the concept of packages we'll soon find ourself in the camp where we have both plugins and mambots. I think this is a particularly dangerous term to introduce. Personally, I'd prefer to leave the package-stuff out for now. If not, we should rename it to something else (eg. 'category').
10. It's possible to launch XSS attacks through the .meta files.
11. Where does the meta file start, and where does it ends? For example, why on earth do we embed the links in the meta file? Traditionally, we use hooks for that. What makes that this stuff go into the meta file and other stuff not?
12. In general, the user interface needs a bit more work before this can be committed. It's dangerous to say that "we'll fine-tune the UI later". First, look what happened to the installer -- it works but it is far from perfect and currently there is no strong incentive to make it better. Secondly, the UI and underlying mechanisms go hand in hand.

(I decided not to review this patch until this late because I'm scouting for developers that make for potential core maintainers for the next branch. While you all do a great job writing code and making this better (really important and good work!), I'm somewhat disappointed by the quality of the reviews, and the fact that no one really questions important design decisions. Pointing out programmer mistakes is one thing, thinking about the overall architecture is another. It's an important quality I'm looking for.)

This patch is going to be a big step forward and I'm confident that it will hit core. It just needs a bit more work, IMO.

To briefly address #2, since that was directed at my input to this patch:

Rather than focusing on the task you accomplish directly after installing a module, it now seems to become a central hub for all administrative tasks (an alternative dashboard).

The reason I advocated for this is based on Lullabot's experience doing the Drupal 101 training in DC and walking newbies through enabling modules and watching their reactions to navigating the Drupal admin interface (which is of course second-nature to all of us so we're immune to this). To be frank, it confused the living crap out of some of them.

To break it down step-by-step (which is what you have to do when you're showing newbies how Drupal works), when enabling a new module, there are no less than 3 places you have to check in order to configure it:

1. access control, to see if it added any permissions.
2. admin/something/something, to see if it added any administrative interface.
3. admin/settings/something, to see if it added any settings that need to be configured.

And often times there are more. These don't apply to every module, but they apply to enough that you may want to check those too:

1. help, to view information about the module and how to use it.
2. content type settings, to see if the module added anything to the node settings form (I can't begin to count the number of "event module doesn't do anything!!" posts because of this).
3. other?

And finally, there's "everything else", all the totally unpredictable paths that a module can add to the system. a lot of them are intuitive, but others are not... for example, tracker.module adds "recent posts" Others are not directly visible in the navigation menu (such as "blog" to view all blogs), and thus people might miss functionality.

Short of reading hook_menu, there really is no way for someone to know all the things a module does when they enable it, other than doing this click-through excercise.

On the topic of bearing in mind who we're writing this for, the kind of "inspiration" for this came from a question by one of the students in the class:

"Well... but wouldn't it be better if you had just one page that showed all of these so you knew where to go?"

And I was very hard-pressed to disagree with him. ;)

@webchick: I don't think that the links are a bad idea, but I do to think they do not belong where they are now. It looks cluttered (IMNSHO) and the fact that the fontsize of the links are bigger than the module description is - when you ask me - even worse..

What I suggest todo is remove the links from the table, and put it into some drupal_set_message().

So, when a module is enabled/installed we get a message like this:

drupal_set_message("The blablabla.module has been enabled on your site succesfully.\nTo make advantage of the features, you should proceed to the access control panel and check for the right permissions. After that, make sure to visit the blablabla configuration page to setup it's options.");

As some nitpicking asshole, I do still think that links for install/uninstall/enable/disable are better inside the 'operations'-column.. ;-) The more buttons are displayed, the more cluttered it feels.. Just see the difference between these two screenshots here:
- http://drupal.org/files/issues/modules-disabled.png (which looks real clean!);
- http://drupal.org/files/issues/modules-disabled-buttons.png (which looks a little scary, by having so much submit-buttons)..

I say this because I remembered some article about usability which says that users *think* forms are scary.. IMO it would make it's userfriendlyness better..

Last suggestions is to make sure you have helptexts for all the admin-pages. ATM it is quite inconsistent in core. A lot of pages have page descriptions/helptexts above the page, while quite a big group of pages are missing them..

Please I do like the functionaly this patch carries with it, but the standard is impressively high these days.. This patch is very nice already, but it just needs to have a little more userfriendlyness...

I can't comment about the meta file related questions (XSS included), but I'd like to quickly explain the reasoning behind my support for this patch. As of a couple weeks ago, when it was in its early stages, I didn't like it. I didn't like how things were divided up, I didn't like what I felt was 'more clutter,' and I didn't like the idea of providing links for each module.

There were a lot of refinements to the UI over that period, and the folks working on the patch paid a lot of attention to other CMS packages' module/plugin installation pages. Gallery2 in particular was a helpful guide. The amount of time they put into their plugin management UI, and the expert assistance they received, gave Drupal some good work to piggyback off of. The only piece that I've said was 'something that could be patched later' was whether to show the list of required modules; that seems to have turned into a religious/opinion issue with this patch, and the simplicity of changing it suggested to me at least that we shouldn't spend as much energy on *it* as we do on the overall system.

Regarding the buttons for installing/uninstalling/enabling/etc, rather than links: On principle, forms rather than links should be used to initiate actions. We break this a lot in core, but I think it's worth pointing out that it is the 'proper' way to do things. Second, it makes it clear that a user isn't just toggling a setting but initiating an action. Our old way -- using a single checkbox -- was deceptive once we started utilizing .install files, as it could mask the fact that a module's setup code had been run, even though the module was disabled. This makes it very clear what steps are being taken and mirrors the UI used by Gallery and other systems. It's quite possible that we need to add some CSS styling to the buttons to make them more attractive, but I think they are the right choice.

Regarding the use of links, I'm torn. I was opposed to them at first and felt they were both unecessary and cumbersome. Then I actually installed the patch, expecting to pick it to pieces. I realized that it was really, really, really nice. As webchick noted, it's hard to argue with the logic of a user who asks, "Why not just put those links in one place?" We spend a lot of time hammering out the right placement for config screens based on task-oriented administration, but it seems to me that 'configuring an installed module' is a helpful and useful way to get a user to the right screen without a lot of hunting. Many many times I've missed features that were 'hidden away' by modules because I had missed one screen tucked into admin/content or something like that.

Using drupal_set_message() for that purpose is not going to work. It's extremely transient. If I click even one of the links in that message and return to the screen, the message is gone. If I enable two modules, I only see the message for the second. And so on. If there is really a LOT of opposition to the links, perhaps a hook_module_status() could be used to allow modules to inform users of a single configuration step that still needs to be performed, error conditions, etc. upload.module, for example, could use it to notify the user that the /files directory needs to be created.

That hook could, I would imagine, be used both here and on an overall dashboard page.

my two cents. are there lots of links? surely there are. Is this a problem? nope. the arrangement of the links make it crystal clear.

is this an alternative dashboard? the question implies that "alternative dashboard is bad!". I do not feel so. One can say that there are different ways to think about a problem and this simply supports another way of thinking.

I like the links, I like the buttons - but I really get an uncomfortable feeling when they are both on the same page, because the links are for managing the settings of your site, and the buttons are for breaking your site and are dangerous (and the buttons should only be available to #uid=1 or users with 'install modules' permissions)

Maybe the latest screenshots of the enabled modules without the operations column are a good alternative for a general 'administration portal' or maybe in an 'about modules' page.
- I'd really move the installing and enabling of modules to a 'modules installation' page and make that page do one task only: install and enable modules -

Wow. I really like that idea.

That would provide a "jump-off" interface for all users with above-average privileges. Or even all users (though that would be kind of weird for them being exposed to individual modules like that.

That brings up another question -- are the links parsed from .meta files checked for permissions?

Updated for HEAD with the the "description and links" part fixed correctly.

Also new page title for enabled and disabled pages so it's more clear where you're at.

And for a 100 and per request of Earl, here is a zip of my hacked drupal CVS so you can use this patch and also generate updates (which will include all new files and etc.).

Instead of using m3avrck's whole drupal cvs archive you can use this patch http://drupal.org/files/issues/new_files_cvs.pacth to update the CVS/Entries and be able to add the new files in your next roll...

*blush* I swopped new and old around the new being the old and visa versa. Tested against old and deleted all my entries.

Try this patch in your cvsroot:

patch -p0 < new_files_cvs_x.patch

It updates the CVS/Entries and you can reroll against cvs:

cvs -z6 diff -NuF^f > new_roll.patch 

The -N is required to add the new files to the new diff.

• I'd still prefer to use PHP's ini functionality. The only valid argument is that ini-files can't have entries that span multiple lines. We don't need that functionality right now.
• Remove the package functionality for now. We can tackle that in a separate patch once there is agreement.
• Consider to remove the dependency system; it needs work IMO and is likely to hold this patch up much longer. We can tackle that in a seperate patch.

1. php's ini parse function does too magic. I know you dislike regexps. Get over that, please!
2. the package functionality is an integral part of the new page. it is much needed, even.
3. huh, same for dependency.

in a more general context, there seems to be a new ongoing debate between patch authors who see a basket of features as one patch and the core committers who would like to see smaller patches.

But keeping up with three patches is more work than keeping up with one.

But that's a separate issue.

php's ini parse function does too magic. I know you dislike regexps. Get over that, please!

This adds no value to the discussion. Please explain what is wrong with php's ini functionality, and how that negatively affects this patch. Thanks.

the package functionality is an integral part of the new page. it is much needed, even.

No, it's fairly easy to leave the package functionality out of this patch. And it is fairly easy to add it later on.

Dries, why not to use parse_ini_file(): http://drupal.org/node/76549#comment-120240

Also, I've had bad experiences with depending on PHP's built-in parsing functions (e.g. highlight_code() used in codefilter) which tend to change in subtle ways from one minor version to another. The regexp does not change and we can tailor it to our specific needs.

Steven, I read your comment but it doesn't make sense to me. Sorry. I've yet to read the first real argument, or see proof of that. Let's start with php's built-in ini functionality, and let us switch to something else, as soon it is really needed. Thanks.

Dries and Neil have pretty much stated in no uncertain terms that this patch will not be committed unless it's split up along the following functionality lines:

1. _uninstall hooks,
2. dependency system
3. the notion of 'packages'
4. a new UI for module management
5. meta files.

I'll take meta files tomorrow, and try and take a stab at some of the others as well, time permitting. If other people help out, we can still get this in! :D

Ok, here's the meta files patch: http://drupal.org/node/80952

I'll work on the uninstall hook now.

The rest are kind of dependent on these two, so not sure how to proceed.

Here's the start of the uninstall hook one: http://drupal.org/node/81033

I've taken the stuff we can more or less directly copy/paste, but the rest of it will take some work and I don't think can happen exactly as is in this patch atm. My availability this week is not looking that great, but I've done the tedious part of the work, so hopefully someone else can bring this part home. :)

Btw, it's worth pointing out that with these two pieces of functionality farmed out into other patches, the crux of what remains is quite small by comparison -- maybe a quarter of the size. So if those two can be spiffed up and put in within the next day or two, there's still hope for this "little patch that could" yet! :D

Dries, see proof of what? That parse_ini_file dies on the first tilde character encountered?? tias.

follwing up. It sure needs usablity hand

Split off dependencies Add dependencies to .info files and respect them in modules page

packages split

If there is nothing left here go ahead and close it.

All the UI changes are now left, but those will go in post-code freeze. Or should we create a separate issue for that as well?

perhaps keep it here, this issue contains a lot of related discussion/screenshots. then again, lot of noise as well :)

Hookin in, maybe will outsource module version display stuff for .info files.

Closing this issue. Basically everything from it went in in other patches. Final one is http://drupal.org/node/87298.

Ahem. ;)