Default admin page

I quite like this. It certainly goes some way to making Drupal easier on the eyes for first time users.

I noticed there's a lot of hard coded style. Would this not be better in a stylesheet and the code just containing classes and ids?

Also would a dropdown box of possible admin pages be better than trying to remember how to spell controlpanel (something I'm having trouble with tonight ;-) )

Nice job :)

the default admin page is a nice feature, and the controlpanel is a very good idea. This goes in the good direction to make Drupal more user friendly.

i agree with the dropdown menu and stylesheet additions, but i already really appreciate the current version.

hope this will go into core soon, as it really makes the first admin pages contact better :)

i don't mind scrolling through the nav menu and i rarely goes into admin without checking the logs, but that definitely will help me converting my wife's site to drupal :p

thanks !

Maybe just because I created it, I like my control panel module better.

chx control panel is located in his sandbox (cp.module), and thanks to him for letting us know there's one :)

it's working fine (tested on HEAD) and provide interesting concept for navigating through the admin, instead of just add a frontend. the settings part is the better one, listing all elements in the page makes quickly forget the standard menu.

der's one looks nice and provide a more immediate access to admin pages, but the standard menu is still mandatory to access some elements (dba or store settings for example, still needs to be accessed via left menu).

to be honest, i like them both :)

being able to change the default admin page is very nice, and icons make admin looks a lot better, raising the Woman Acceptance Factor by a huge amount (my wife loves it :). but i also really like the more in depth admin navigation offered by chx module.

mixing both on my head setup gives a nice result, so may be it would be a good idea to join forces and mix the 2 panels.

chx, is your module somewhat official and scheduled to hit the core ?

Hi, I asked Karoly to create the control panel module. It important that the control panel be tied into the navigation menu block so that it does not create inconsistent navigation.

The goal is to start a user experience grouping exercise to help the community categorize administration tasks. The first thing that has to happen is that administration must be considered a seperate situation from creating personal content in Drupal. To support this seperation of personal tasks and administration tasks we broke out administration to have a separate theme in the CivicSpace theme.

Through research interviews into Drupal administration we need to discover what the goals and tasks of administrators are. Some early feedback is that site developers need modules to be evaluated on Drupal.org. They have also indicated they need better and consistent administration help ,with incontext list, which we have been adding. We have also heard administrators want a quick overview. Any change to provide a control panel like overview must have a dashboard like overview. You should assume that we will identify a list of 5-7 top goals for administrators.

Once those those 5-7 top goals are identified we need to ensure administrators can acommplish tasks to achieve those goals. Some of those tasks will completed by clicking through to icons or admin interface links. Sub-goals will be accomplished by providing effective navigation. We need to consider 4 types of navigation to be added to the control panel: Global navigation, local navigation, contextual navigation, and situational navigation. Some of this navigation can be accomplished through a theme or blocks. Some will need to be in the page and some need to be added in otherways, such as interaction techniques.

Keep all this in mind when creating a control panel solution. It also must respond to the fact that every site will have different permissions set and different modules. This is a complex problem and it's going to research and experimentation to get it right. But this is a big step in the right direction.

Cheers,
Kieran

function _system_adminpage () {
    drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}

no way. Use menu !$may_cache and set the path based on the variable.

Adding in-line style elements is also a no-go.

The code style is not kept. Never a space between full stop and apostrophe, always otherwise.

It's not $menuvisible but $menu_visible

I must be blind (it's 0:17am) but // Build the settings section of the control panel does not seem to differ from the previous section. A function may be appropriate.

der, i've checked the new version of your control panel, and it does simplify access to the settings menu (although with a complex setup, the site config collapsable menu goes a lot more down than the menu, but this a page and not a small menu so its still better)

however, there other case settings like, such as the ecommerce modules, which provides a more complex menu tree (ex : store->settings->payment->adjustments, each with their own admin pages). these are not taken into account by your panel, leaving the menu mandatory.

chx control panel handles this nicely with page navigation. going through the store menu with chx panel is a real pleasure while its a real pain with the menu. So i think the best would be to mix the two panels, chx one handling page navigation, and yours providing a frontend for basic admin pages, and collapsable site config items. instead of linking to the standard admin pages, icons might link to chx nav pages where there are sub entries.

i'm running both today, and this already makes the admin really better, but i'm often switching from der panel to chx one (for store), so mixing both would be, for me, a very nice solution :p

thanks for the good work :)

i think there's a problem with your latest patch. it seems to display all icons as a vertical list. it may be a problem with my setup, but i'm using basic themes that comes with head. the administer page is thus very long, and this is not very useful. previous version was better, imho :)

thanks

the vertical thing was probably due to a problem with my drupal.css. i've tested your new patch with a fresh update and the display is fine, but there's a bug.

the site configuration panel displays store settings items (checkout,payment,shipping), and not the global settings one. this might be due to the menus item having the same name 'settings', although not located at the same level (administer/settings, and administer/store/settings). ready for another patch ? :)

your panel adds a nice look and enable default administer page setup. but there's still a lot of menu access needed when other modules are setup (such as ecommerce), and i'm using it in addition to chx one to provide a complete admin solution :)

chx one looks just like the theme you're using with no icons, but it really help accelerating admin navigation. i'm wondering if integrating both to core wouldn't be the ultimate solution. your panel more targeted at standard admin needs, and chx one helping users that deals with lots of modules & settings.

thanks again

Hi, can you guys post some screen shots as you go along for those of us who don't want to keep installing new patches.

print theme('page', foo) is not used in HEAD, it's return foo. This approach now looks pretty good. I had another approach in my mind but this begins to look good. I'll test it later.

patch works fine.

this is a small but useful feature, i think it should be added to core while waiting for the reworked control panel module.

may be we could close the thread and switch to a new one for the upcoming module, as the comments start to grow (guilty, your honor :)

keep up your nice work Der :) your patch was nice, but i'm sure we'll soon have a nice admin panel module. (and there is no doubt about it if chx says it begins to look good :)

don't know anything about the approach mentionned by chx, but i really like the result of having der panel + chx one for navigation, this really gives drupal an improved admin usability.

thanks² :)

We do allow to set a custom front page, so this change makes sense to me.

Patch looks OK except for one thing:

look at how index.php handles the $return value of menu_execute_active_handler(). We should do same here. Ideally, you should refactor this handling into a new function and use it in both places. Perhaps the function should be called menu_print_active_handler().

Care to share a screenshot?

Dries - there is a screenshot in this issue. See http://drupal.org/files/issues/Control%20Panel.png

Huh! Instead of menu_print_active_handler(); a simple return menu_execute_active_handler(); isn't enough?

The only thing I can see that needs attention is the phpdoc on menu_print_active_handler(). This is the same as the first line of the phpdoc for menu_execute_active_handler(). These functions do different things so one of them must be wrong.

Perhaps the menu_print_active_handler phpdoc should mention displaying the page or an appropriate error message.

I like it!
+1

For me, this makes it too easy to break my admin pages. If I enter something invalid into the default admin page textfield, Apache crashes when I goto /admin next time. The values that I tried were 'admin', 'admin/not-exist' and a empty value, all crashed Apache. As well, if I set it to a page that generates a 404, then the administer menu is not expanded, making it harder to get to /admin/settings.
Could someone please confirm wether I'm not the only one that has problems with this.

You are right. Apache crashes if the page is not found.

Also to Moshe: we are returning the value of menu_execute_active_handler so why would we need to handle it ourselves? index.php will handle for us if I am not mistaken.

chx - you might be right about. the previous patch had duplicated code between drupal_ite_offline() and index.php and thats what i want to avoid. i think a better solution would be to remove the break; in the OFFLINE branch?

this apache crash problem needs fixing before this can be accepted.

also, the most recent patch lacks a settings form field. not sure if thats deliberate or not.

moving to cvs. I am also wondering if you couldn't replace the default overview suign a module that hijacks the /admin path.

I was able to replace the admin screen with a URL alias.

Since HEAD development is reopened, I think we should consider incrementally changing the administration section to be something more useful than logs and more organized than the menu. And establishing standards for contrib modules to properly integrate their items and for us to stay on track in core.

Isn't this fixed in HEAD/5.0?

All of this has been changed in the 5.0 admin reorganisation. If there is a request for an icons-and-polish control panel, a new issue should be opened.