Clean-up settings page (step #1)

I completely agree with this direction.

looked at the screenshot only: I find it confusing that the menu does not seem to have the same items as the main page, ie there are additional items for the main page. Maybe we should remove the menu?

Dries, it's not very clear to me what the advantage of this is, or should be..
I would love to see it, but unfortunatly I can not find the advantages...

Is this the final state of admin/settings? Only the links to the pages which are desplaying the seetings?

If that is the end goal, I would love to get rid of the whole admin menu.. We can help users with breadcrumbs to let them navigate through the settings...

I think...

I think I am ok with this patch. Deprecating the settings hook and using the menu system is a straigthforward improvement.

Some beautification of the page should be done in a second step.

I also never liked the many collapsible fieldsets on the page.

The patch applies with a 21 line offset on user.module.

Generally speaking, I like the idea behind the patch. I found it always unnerving that I had to load the whole core setting page just to access the module setting pages on the lower rung.

some comments, though:

1) I have the same comment as Killes on the differing order of the items. (but Dries already replied to this).

2) I find it confusing to have the core settings mixed in together with the module settings. Before, I knew I had one menu item under admin/settings/ for each module. When enabling each module, I can look in the list (menu) and it reminds me what modules I have enabled on this particular site.

(my definition of 'core settings' are those for the required modules that cannot be turned off. In general, I am looking for only one (at most) additional setting link for each additional module enabled).

=> can we solve this by grouping the core settings entries together (in one list), and the hook_settings() on a second list, each with an appropriate title/header?
The idea is that beside the few core settings grouped on one side, I'd have the module settings grouped on the other side, with exactly one link per module (or one link per hook_setting()).
This could be easily (??) achieved in the main area of the page (print two lists under different headings).
In the menu, we could:
a- leave it as is,
b- have two sub-menus: admin > settings > core settings > list of core settings and admin > settings > module settings > list of modules with settings (forces to click through one more page, unless the menu item is set as expanded per default, which allows us to collapse the core setting sub-menu once done with the initial core settings).
c- split the menu into two parts: admin > settings (core) and admin > settings (modules).
d- leave as is, but with core settings coming first in the menu, and module settings coming last, with a separator between them.

(obviously, I am not considering here the difficulty of implementation, which is also an important issue. I'm just brainstorming about different alternatives).

3) Not crucial, but the link appear lonely in the middle of the page. Maybe, in this patch or later, a short plain text description can be added beside the link.

Hmmm.... looking at the code, I guess Dries will not like my comments: none of what I propose can be easily implemented ;)
So, my final comment is: I don't object to the patch as it is, now. I was just expressing my first impressions when watching the result.

oh!
In that case, assuming that module settings are still at admin/settings/module, what would happen if I access admin/settings ? 404?
Or maybe you mean that we should have admin/mymodule/settings ?

The general site configuration in the screenshot doesn't separate the core settings from the module settings as I mentioned above.

I think all the settings which are required (as in "required form element") are quite important and should be more easily accessible. A module author should then mark some setting as required if the module won't run otherwise. So, the site email address woruld be required and should be easily accessible. Same for the files directory, but maybe not for the cache and date settings.

I am fully ok with addressing the "which setting is important" part later.

Your use of Drupal on buytaert.net is IMHO overkill, you'd be better served with wordpress or some other blogging tool. ;)

I am pretty sure that 98% of all Drupal installs have at least sent a mail once. Having a mail sender that people can reply to is a good thing even if the mail (like password reminders) isn't intended to be replied to, "root@localhost" doesn't cut it.

I think the file settings should only be displayed if a module that uses them is enabled.

Dries: your third screenshot seems to be broken. I cannot view it.

When I was speaking about 'core' settings, I didn't mean 'important' settings.
I gave my definition above.
At first, by 'core settings' I meant everything that is currently under admin/settings and that is broken up into different parts with this patch.

But my final definition of what is a 'core setting' is, as mentioned above, all the settings that are still available after having turned off all non-required modules.
For all additional module being enabled, we should have only one set of settings, accessible via a single link. One module = one link to one group of settings.

This is a useability issue. If an admin enables one more module, she should be looking for a maximum of one addition link, not two leaving her wondering if she missed a third one.

According to this definition, I think it would be best if we could have all the 'core settings' grouped together, and the module settings listed separately (but not far :) ).

I think when the admin overview page is done, this re-organization will address -- if not quite wholly -- your issues.

Please don't commit just yet -- I want to give it a try first... will post a review within the hour.

Ok, my first thought is "yikes" ...

a) One of the first things I do when testing a "mega patch" like this one is turn on every core module. Here's what my admin/settings page looks like:

* RSS aggregator
* blog APIs
* comments
* contact form
* sites registry
* distributed authentication
* forums
* user profiles
* access logging
* throttle
* uploads
* menus
* posts
* content types
* site information
* error reporting
* page caching
* file system
* image toolkit
* RSS feeds
* date and time
* site status
* unicode
* cron status
* clean URLs
* users

To the casual observer (and even the non-casual observer), this is utter chaos. Pretend you're a new user and have never before used Drupal in your life. Now try and find where you'd configure file upload permissions. Unless you either really like reading or are handy with Ctrl+F, you're going to be staring at this screen for a very long time.

b) In #7 you said:

killes: they have the same items but aren't listed in the same order.

However, here's what my settings menu looks like (even after DELETE FROM cache):
# settings

* clean URLs
* content types
* cron status
* date and time
* distributed authentication
* error reporting
* file system
* image toolkit
* menus
* page caching
* posts
* RSS aggregator
* RSS feeds
* site information
* sites registry
* site status
* unicode
* user profiles
* users

Notice that several items are missing here: including forum and upload. So even if I ignore the utter chaos of the admin/settings page (which presumably gets fixed in some way with merlin's follow-up patch), and instead go with the menu which is ordered alphabetically, I can't. I am forced to hunt and peck through the big list looking for the settings page I need. This seems like a bug.

c) Also note fun things like RSS aggregator and RSS feeds being nowhere near one another, even though "conceptually" they're referring to the same kind of stuff.

d) Note also that for example "image toolkit" brings up nothing at all on its setting page other than the Save Configuration and Reset to Defaults buttons. That also seems like a bug.

e) A comparison to Windows Control Panel doesn't really work here, because Control Panel (and Apple's System Preferences, etc.) uses icons to easily identify where groups of settings are. If I'm looking for printer settings, I look for the picture of the printer. I don't need to read every single description (or any description, really) looking for which one says "Printers and Faxes." I can also easily go back to that icon because the items are listed in alphabetical order. It's going to be after "Power Options" and before "QuickTime" (ewww, how did QuickTime get on this machine? ;)).

This has been my biggest complaint with attempts at re-working the admin section -- the lack of visual cues to allow viewers to easy "drill-down" to the information they require, simply at a glance. I can accept, however, that UI improvements of icons and such should be a separate patch. I just want to strongly note that what is here now is going to cause more confusion than a hierarchical, alphabetical listing we have now, unless something like this is done.

---

What I would suggest in the interim, which would get around massive UI changes but still make some sense out of the current list on admin/settings, would be some way of grouping settings pages by module. For example:

What I would suggest instead is grouping these by modules, in alphabetical order.. for example:

<fieldset>
System (always at the top)
<ul>
  <li>clean URLs (list of settings pages ordered alphabetically)</li>
  <li>date and time</li>
...
</ul>
</fieldset>

<fieldset>
Aggregator (rest of core/contrib modules ordered alphabetically)
<ul>
  <li><a href="http://localhost/head/?q=admin/settings/aggregator">RSS aggregator</a></li>
</ul>
</fieldset>

<fieldset>
Blog
...
</fieldset>

Make sense?

Btw, marked "code needs work" because:
- The fact that different settings show in the menu vs. on admin/settings seems like a bug.
- The fact that there are totally empty settings pages seems like a bug.
- IMHO, just in case a follow-up patch does not make it in, we really need admin/settings to be at least somewhat usable, even if it only ends up being this way in HEAD for 2 weeks or something. The way it is now is just too confusing.

If you disagree, of course, just set it back. :)

webchick: IMO the organization is a matter for my patch that Dries mentioned earlier, and I am actually very interested in getting this in as a stepping stone toward the re-org. Once we have the re-org, settings will be in their more logical placements.

As mentioned several times, the categorization of the the settings pages will be taken care of by the next patch (which Earl is currently working on).

Yeah, I realize that. My concern was that this page is totally un-usable until that patch lands. But now that the menu items are all there, and sorted in alphabetical order, this should provide a suitable workaround for the short-term.

"image toolkit" is still blank, and hunk 1 of 6 on user.module fails... it's the part changing the welcome message.

Hi, I am a moron. :P I should update HEAD before applying patches. ;)

Not sure what you want to do about image toolkit, but probably not enough of a problem to mark this "code needs work"

image toolkit probably just needs an explanation that you have no additional image toolkits installed and that you can only use the default. That'll solve the blankness and the only difficulty, really, is writing the explanation. IMO.

Ohhh, excellent! Thanks so much, Dries!

Tested and works as stated. As an added bonus, it took the buttons off "cron status" which is just a message to let me know it hasn't run.

RTBC. :)

After fresh install, cannot run clean url test.

patch fixes clean url test