- Development - lists.drupal.org

[drupal-devel] [bug] Comments per page, links don't go to correct page
by mindless 21 Sep '05

21 Sep '05

Issue status update for http://drupal.org/node/26966 Post a follow up: http://drupal.org/project/comments/add/26966 Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: jakeg Updated by: mindless Status: patch (code needs review) We have this problem on http://gallery.sf.net too.. the incorrect redirect url after posting a new comment on a long topic was the case I noticed. I did fix one link in the forum module, see patch here: http://drupal.org/node/31645 mindless Previous comments: ------------------------------------------------------------------------ Mon, 18 Jul 2005 15:53:36 +0000 : jakeg When you, as admin, set the default number of comments per page, the links to those comments are not updated as they should be. For example, all links to individual comments still go to /node/x/#comment-x but comment no. x may not be on that page if x is bigger than the number of comments per page. Hence the link is wrong. This includes links from the 'recent comments' block and also very importantly after someone has submitted a new comment, they should be taken to their comment but if their new comment isn't on the first page then they have the same problem. This is a *big* problem if you have discussion/comment threads of more than about 100 posts (some threads on my site are over 300 posts) and hence you can't sensibly include them all on one page. ------------------------------------------------------------------------ Wed, 27 Jul 2005 20:44:29 +0000 : jakeg bump. I consider this to be quite important. Its definitely a 'bug' and not a feature request as when you click a link to a certain comment you expect to get to that comment, as the # in the URL would suggest. ------------------------------------------------------------------------ Tue, 09 Aug 2005 08:19:03 +0000 : jakeg bump - can anyone help? Its a major problem for me. ------------------------------------------------------------------------ Sun, 21 Aug 2005 06:58:32 +0000 : robertDouglass Changing this to CVS and widening the scope. When I set the comments per page at 10, in the CVS version, and then make a node with over 10 comments, I get no pager links to other pages of comments, but rather a useless "moderate comments" button. In short, in my install from yesterday, comments are foobar. ------------------------------------------------------------------------ Thu, 25 Aug 2005 23:49:03 +0000 : tostinni Attachment: http://drupal.org/files/issues/comment_page.patch (1.02 KB) "When I set the comments per page at 10, in the CVS version, and then make a node with over 10 comments, I get no pager links to other pages of comments, but rather a useless "moderate comments" button. In short, in my install from yesterday, comments are foobar. " Ok I got a patch for this, it's just a smal mistake in the order of the pager_query arguments. I'll have a look at the comment link tomorrow. ------------------------------------------------------------------------ Fri, 26 Aug 2005 22:49:52 +0000 : tostinni Regarding the block comment : "When you, as admin, set the default number of comments per page, the links to those comments are not updated as they should be. For example, all links to individual comments still go to /node/x/#comment-x but comment no. x may not be on that page if x is bigger than the number of comments per page. Hence the link is wrong. " In HEAD, it seems that links goes to /node/$nid#comment-$cid so I think there's a mistake here, it should be /node/$nid/$cid#comment-$cid if you want to see the individual comment. But if we want to see global comment thread and move the focus to the current comment, we should consider doing something like node/$nid?page=$pid&comments_per_page=10#comment-$cid $nid, $pid, $cid are variable defining the comment. What do you think about this ? ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:29:51 +0000 : tostinni Attachment: http://drupal.org/files/issues/comment_page_0.patch (2.32 KB) Here comes a new patch, and for the moment, here will stop my contributions. I need help and review because I don't know how to fix the next bugs. What do my patch : - correct the pager_query function to see the list of comment as described in #4 - correct the links on the title of the comment when seeing the comments. Currently they are built like : /$nid#comment-$cid this doesn't work when a page is specified, so we have to look if URL get extra parameters like "page=1" to rebuilt the url link. So I modified phptemplate engine to change the comment theme function in order it takes these parameters. Now I'm still blocked because I don't have any idea how to solve the biggest problems in comment_block and about redirecting user after posting his comment. This is not so hard to tell, but I don't know a clean way to do this : In comment_block, the problem is that when we make the link to last comment, we didn't know the page where the post is supposed to be (this only happen when we have a threaded mode). So we should find it. Yes, but the problem is how... We should do an other query, like the one we made in comment_render and then find the position in thread of the current comment to add the page fragment to the url. It happens pretty much the same in the redirection after writing a comment. Any odeas on how we should make this ? 4.7 is coming... :) ------------------------------------------------------------------------ Mon, 12 Sep 2005 21:18:14 +0000 : killes(a)www.drop.org The first patch is an obvious bugfix and shoudl be committed. I don't understand the rest of the probem, though. paged coments have been broken for a long time, so it would be nice to see them fixed.

1 0

[drupal-devel] [feature] Administration Control Panel suggestion
by syllance 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: syllance Status: patch (code needs review) 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² :) syllance Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy 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 ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance 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 ! ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:09:43 +0000 : der I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons? ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:16:15 +0000 : chx Maybe just because I created it, I like my control panel module better. ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:25:30 +0000 : der If I would have known there was a module I wouldn't have written this patch although I do think this would be good for core Drupal as the default. Is your modules a recent creation? I don't see it on drupal.org nor could I find in the contribs section of CVS (either the modules or sandbox sections). I'm I missing something? Is it called something different? ------------------------------------------------------------------------ Sat, 17 Sep 2005 18:20:15 +0000 : syllance 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 ? ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:24:11 +0000 : Amazon 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 ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:47:55 +0000 : der Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB) This has sparked a lot of good discussion. I've taken a look at cp.module and I think it really is complimentary with my proposed patch. I've taken my patch one step further and provided the settings icons in a collapsable group below the main control panel. This would allow access to all admin functions without referring to the traditional menu. Syllance, do you think this addresses the gap you saw in my solution? ------------------------------------------------------------------------ Sat, 17 Sep 2005 20:33:10 +0000 : der Kieran, I'm glad to see some serious thought going into the user experience for site administrators. I think separating the user and admin sections of the site is critical. It will not only allow extensive usability work to be done for site admins it will also make it much easier for theme creators as they will be able to focus on the end user experience. I like the admin theme for civicspace. My only dislike about the approach is that it's template driven which causes a sites template to be larger and more complex due to handling all the logic for user and admin themes. I think a better approach may be to use a module such as the sections module. This allows you to have smaller templates focused on user or admin themes. I agree with your point about making sure the control panel ties into them menu system. My approach uses the existing menu structure so modules are added dynamically and all permissions are enforced. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:21:05 +0000 : chx <?php 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. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:39:40 +0000 : der Thanks for the code feedback. I'm assuming the extracted style info would get patched to drupal.css? Your right about the duplicate code. A function would make more sense, I'll make the change. I'm not sure about the comment to use "$may_cache" I've never used it before. What's it's purpose? How should I use it in this situation. I'll dig around and see if I can figure it out but I thought you might be able to give me a little insight. Thanks! ------------------------------------------------------------------------ Sun, 18 Sep 2005 10:41:00 +0000 : syllance 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 :) ------------------------------------------------------------------------ Sun, 18 Sep 2005 12:54:55 +0000 : der Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB) Here's a new patch with the code reworked per chx's comments with the exception of his objection to my use of drupal_goto function. chx, I'm probably missing something really obvious but I'm not understanding your suggestion. Are you suggesting I use some menu function to do the redirect? If so, I could not find one that suits my needs. Or are you suggesting to use the drupal_goto function in a different manner than I am using it. Like I said, I'm probably missing something really obvious here but for the life of me I don't know what it is. Any further advice would be greatly appreciated. The offending code below: <?php function _system_adminpage () { drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL); } ?> ------------------------------------------------------------------------ Mon, 19 Sep 2005 13:42:57 +0000 : syllance 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 ------------------------------------------------------------------------ Mon, 19 Sep 2005 14:10:03 +0000 : der which theme and which browser are you using? ------------------------------------------------------------------------ Mon, 19 Sep 2005 15:59:16 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB) I've tested this with IE and FireFox with each of the Drupal shipped HEAD themes and I'm not seeing the issue you described. Are you sure the patch applied correctly to drupal.css? Here's a slightly revised patch. It make the control panel icon group collapsable but open by default. ------------------------------------------------------------------------ Mon, 19 Sep 2005 18:09:22 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB) Sorry for the excessive number of patches. I just realized that my previous patch had an issue with icon image file names if there were admin and admin/settings menu items that were the same (eg admin/user and admin/settings/user). New patch attached to address. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:13:49 +0000 : syllance 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 ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:19:54 +0000 : Amazon 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. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:25:06 +0000 : der Attachment: http://drupal.org/files/issues/Control Panel.png (101.02 KB) Sure, here's what the current version looks like with the civicspace admin theme. ------------------------------------------------------------------------ Tue, 20 Sep 2005 04:22:36 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_2.patch (5.48 KB) Patch fixing the issue that syllance pointed out and it also fixes the obvious issue with the drupal_goto function arguments. duh! ------------------------------------------------------------------------ Tue, 20 Sep 2005 19:02:41 +0000 : der Attachment: http://drupal.org/files/issues/system.module_12.patch (2.48 KB) I've thought about this and I think it makes sense to break this enhancement request up and provide the second request (Admin Control Panel) as an add-on module. Therefore I've scaled this patch back to handling only the first enhancement request: /Add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page./ ------------------------------------------------------------------------ Tue, 20 Sep 2005 19:12:41 +0000 : chx 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. ------------------------------------------------------------------------ Tue, 20 Sep 2005 19:21:39 +0000 : der Attachment: http://drupal.org/files/issues/system.module_13.patch (2.47 KB) new patch per chx's comment

1 0

[drupal-devel] [feature] Authentication hook for local users
by bslade 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/29147 Post a follow up: http://drupal.org/project/comments/add/29147 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: naudefj Updated by: bslade Status: patch (code needs work) Nedjo said: " "I assume authentication should be either local or external--not both" " What exactly do you mean by "local" and "external"? Are you assuming: * The definition of "local" means logging in with just /username/ to get the username and password info from the name/pass fields in the core Drupal users table? (without calling hook_auth()) * The definition of "remote" means logging in with username@doman and calling hook_auth to get the username password info from some source /other than/ the core Drupal users table? I think this issue is talking about implementing some sort of authentication hook/module so that item (1) can access some other local table besides the core Drupal users table without having to hack the user.module. It sounds like, right now, the answer is, "can't do that". Ben in DC bslade Previous comments: ------------------------------------------------------------------------ Thu, 18 Aug 2005 20:46:57 +0000 : naudefj Please implement a hook to authenticate local users - similar to what hook_auth does for remote users. Alternatively, extend hook_auth to authenticate both local and remote users. Current behaviour: - If a user logs in with "user@domain", hook_auth gets activated; - If a user logs in with "user", hook_auth is bypassed. More details: http://drupal.org/node/27959 ------------------------------------------------------------------------ Sat, 20 Aug 2005 20:11:29 +0000 : killes(a)www.drop.org use hook_user(login) ------------------------------------------------------------------------ Sat, 20 Aug 2005 20:38:53 +0000 : naudefj I just tried hook_user(login), but it only fires when a valid drupal userid/password is entered. ------------------------------------------------------------------------ Sat, 20 Aug 2005 21:03:38 +0000 : naudefj I found the reason why hook_auth only works for remote users. Look at this code from users.module: // Try each external authentication source in series. Register user if // successful. else if (!$user->uid && $server) { Is this something that should be fixed, or should I just comment out the the "&& $server" part myself? ------------------------------------------------------------------------ Sun, 28 Aug 2005 19:03:24 +0000 : naudefj Attachment: http://drupal.org/files/issues/user_31.patch (1.7 KB) Here is a patch that will allow HOOK_AUTH to work for both local and remote users. If would be great if it can be reviewed and applied to HEAD. ------------------------------------------------------------------------ Sun, 11 Sep 2005 05:32:55 +0000 : moshe weitzman hook_auth deliberately is ineffective for local logins. if you enable it for all logins, you will slow down the experience for many people who guess their passwords wrong on login page. in that case, code would call all remote auth modules an dthey in turn would contact their home base. thats too slow. we want to return a 'sorry try again' message very quickly. what are you trying to accomplish here? ------------------------------------------------------------------------ Sun, 11 Sep 2005 06:59:52 +0000 : naudefj Hi, > hook_auth deliberately is ineffective for local logins. Not true. HOOK_AUTH cannot be used for local logins. Look at this line in user.module: else if (!$user->uid && $server) { > what are you trying to accomplish here? I would like my users to use their existing forum userids and passwords to login to Drupal. However, I quickly discovered that external authentication only works if you append a domain/servername to your userid. For example, if a username like "user*@domain*" is entered, HOOK_AUTH gets activated. Problem is that if a userid like "user" is used, HOOK_AUTH will be bypassed. This fix allows local users (i.e. just "user") to be authenticated against an external source. Any other solutions/ suggestions would be greatly appreciated! Best regards. Frank ------------------------------------------------------------------------ Sun, 11 Sep 2005 14:49:15 +0000 : nedjo "The fix allows local users (i.e. just "user") to be authenticated against an external source. " Why? I assume authentication should be either local or external--not both. Therefore, we need a way to distinguish between the two. Currently, the username@domain convention is used. Removing the @domain part of the DrupalID would remove this disctinction. Is the issue just that this convention is confusing for new users? In this case, I'd suggest pulling the domain part out into a different field. So, when drupal.module is enabled, there is a third user login field, "site" or "domain", that would include "local" and any registered associates. ------------------------------------------------------------------------ Mon, 12 Sep 2005 06:01:36 +0000 : naudefj > Why? Without it, it would be impossible to have a single userid/password for your entire site. It would be silly to ask users to log in to Drupal using their forumid@local. Surely there must be a way to authenticate them without having to type the "@local" part? > So, when drupal.module is enabled, there is a third user login field, "site" or "domain", that would include "local" and any registered associates. Not sure I understand - I'm not using drupal.module, but are trying to implement my own authentication module without the need to hack into user.module (or any other module for that sake).

1 0

[drupal-devel] Q: Custom node types in forums?
by David Cohen 20 Sep '05

20 Sep '05

I posted this question <http://drupal.org/node/30980> some time ago and got zero response. I'm following up here because I'd like to hear from Drupal experts before I pursue it any further. Briefly (this repeats content from the link above), I've created a new node type. It's an event with dates, location and other data. I want the event discussed in my forums, but I don't want to create a new forum entry in parallel with my event node. I'd like my event node itself to appear in the forums, as well as other places on the site (event calendar, etc). So my idea is that forums should include any node of any type, as long as it is associated with a forum taxonomy term. That is, if I create any node at all and give it the taxonomy term Forum->Events, it will appear in my Events forum. The current forum package does not work this way. It only shows nodes of type 'forum' and has a forum table which includes all forum nodes. I think both of these 'limitations' could be removed. Unless of course there is good reason for them that I do not see. Which is why I'm asking now. As I said in my earlier post, I'm willing to contribute to this if others like the idea. Thanks for your input, -Dave

5 6

[drupal-devel] [drupal-dev] screwed something up :)
by GravyFace 20 Sep '05

20 Sep '05

Well, I lost the in-page menu items some how -- the "Edit" and "View" tabs that are normally present on the nodes when logged in as admin are missing as well as some of the context menus in the admin section ("content type" etc.). I thought it was CSS display issue (I've been messing with drupal.css) but the actual form elements and table rows are missing.

1 1

[drupal-devel] [drupal-dev] menu_hook caching problem?
by GravyFace 20 Sep '05

20 Sep '05

I've been playing with the menu hooks, particularly with the Events module and noticed that changes are not reflected immediately and/or "linger" unless the corresponding cache record in the cache table is deleted. Steps to reproduce: 1. execute DELETE FROM Cache statement in MySQL 2. modify $items array in hook_menu 3. invoke module/request new path (GET /new/path) I have caching set to "disabled" in the admin > settings, but $may_cache is set to true; why is it caching it?

3 2

[drupal-devel] [bug] Remove drupal module from core
by Boris Mann 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/31716 Post a follow up: http://drupal.org/project/comments/add/31716 Project: Drupal Version: cvs Component: drupal.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: Boris Mann Status: patch (code needs review) Both CivicSpace (Kieran, I think we agreed on this) and Bryght are commited to developing distributed authentication functionality. We would love if something shipped by default with Drupal core. OpenID is my current best bet, although as chx pointed out, Pubcookie looks excellent for the more corporate market. My proposal would be to make drupal auth an OpenID compliant server, and to make the "base" dist auth have the proper trust relationships/security that people could be confident in using it in most standard security situations. The current "drupal" module would actually become more of a container for dist auth in general, as it has been in the past. One of it's functions might be (for example) mapping remote information to local, as we implemented for the SXIP module. Boris Mann Previous comments: ------------------------------------------------------------------------ Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB) The drupal module does two things; it implements distributed authentication and it lets you run a "directory server". These sound great in the features list, but the implementation of both features is weak and poses the real risk of exposing Drupal users to identity theft. Here is an excerpt from my writings on the module: Distributed authentication Drupal distributed authentication is a way to save site users the extra steps of creating redundant accounts on multiple sites. (snip... we know how it works :-) There are some limitations and concerns about the current implementation of distributed authentication. It would be relatively easy for someone to alter the code of their site to save a record of the passwords of users who log in. This is true of any website you visit, Drupal or otherwise. As long as the username and password only buys access to that very site, there is little incentive to do this. If, however, it would allow the malicious person to log into other sites as well, in this case any Drupal site that has the drupal module enabled, the incentive is greater and the potential loss or damage greater. The attacker would be able to masquerade on those sites using your user identity and execute actions on your behalf. CAUTION Drupal's distributed authentication is inherently insecure. If you do not know that you can trust the owner(s) of a particular site, never use your distributed authentication (Drupal id) to log into it. Running a directory server The drupal module offers a simple service by which other Drupal sites can announce their existence, or "ping" a central server on a regular basis. While there are many possible applications of such a service, the most prominent use is the now defunct Drupal sites page on Drupal.org which was simply a long list of sites that run Drupal. In practice, any site that has the drupal module enabled can function as a directory server. When another site pings the site, the remote site's name, slogan and mission are added to the list of sites. A useful application of a directory server might be on a college or university where individual labs or departments are setting up many different Drupal sites. Each one could ping a central server at the university to compile a list of all the various sites as they spring up. In its current state, the service lacks some basic features. There is no way for the administrator to block a certain site from pinging and being added to the list. Nor is there a way to limit the incoming pings to a certain set of domains or IP addresses. The potential to make a truly useful directory server service exists, though, and anyone is encouraged to participate in discussions and development at Drupal.org. ----------------------- I've come to the conclusion that a module that is this weak should be offered as a contributed module, not as core. If it weren't in core, I wouldn't bother writing about it because it is too weak, and poses a real security threat. My recommendation is that it be placed in the contributions repository as an example of how distributed auth. for those enterprising individuals who might want to improve upon it. ------------------------------------------------------------------------ Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass tasks don't send mail? Setting to bug report. ------------------------------------------------------------------------ Tue, 20 Sep 2005 10:30:42 +0000 : robertDouglass The more I think about it, the more I conclude that Drupal.org should also drop dist. auth. support, or find better security solutions. Here's an example scenerio to provoke discussion. Gerhard always logs on to drupal.org as killes(a)www.drop.org. AFAIK, these sites are now on two separate servers, and therefore probably have different security profiles. Now, just as conjecture, let us suppose that the server on which drop.org is run gets compromised and someone is able to steal Gerhard's password. They now have a big cat in the bag: drupal.org. They'd be able to become site/cvs admins for drupal.org, something which we probably don't want. In the end, if we have no way to say which sites can be trusted to do authentication, it is a bad idea allowing anyone to use this in conjunction with drupal.org. Another example: http://kerneltrap.org/user/2524 What if Jeremy's server were compromised (or perhaps Jeremy is just really evil and nobody knows ;-))? In either case, someone would be able to log into drupal.org with the UnConeD username - not a really attractive idea. PLEASE TELL ME I'M WRONG! Or remove the module. ------------------------------------------------------------------------ Tue, 20 Sep 2005 11:17:00 +0000 : eldarin Robert, you make perfect sense. ;-) Other servers could get compromised like you point out, and that could let someone take control of drupal.org if a siteadmin used the compromised site with the same account login. This could especially be true if a site used an earlier Drupal version. And it's not only current sites using this, but future sites and possible future modules which can be used to compromise security. Someone could offer my-cool-module.module and distribute it through some other forums, thereby getting some backdoor access. Using the distributed login feature, they could behave like a worm. Ultimately, it's up to the users to show good thinking and NOT use the same username or password everywhere .. but that is difficult to demand. Scenario example: two websites have siteadmins which know each other well (or same person), and same person registers on both sites. If the password is very similar or a pattern can be discerned and if that person is a drupal.org siteadmin, the possibility exists that drupal.org still could get compromised. There is no way to be foolproof, but helping users along doesn't hurt. ;-) ------------------------------------------------------------------------ Tue, 20 Sep 2005 11:34:07 +0000 : chx I agree. I have looked around for better solutions and pubcookies looks good. (Google on it. I do not have too much too time to write about it.) ------------------------------------------------------------------------ Tue, 20 Sep 2005 13:53:36 +0000 : gravyface Of course, this assumes that Gerhard uses a different username and password combination for every site, which most people don't; if not, you wouldn't need to exploit the distributed authentication to get this to work -- you could take the average user's account and not only log into other Drupal sites but into Hotmail, gmail, Paypal, eBay, etc. I agree with Robert; I think that this should be removed from the core. Single Sign-on (SSO) [1] is not an easy thing to tackle and outside of a controlled, private network, it may not even be desired. Look at Microsoft's Passport failure [2] as an example; the largest software company in the world could not get this to work and apparently, nobody wanted it either. [1] http://en.wikipedia.org/wiki/Single_sign_on [2] http://yro.slashdot.org/article.pl?sid=04/12/31/1416212&tid=109&tid=158&tid… ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:04:36 +0000 : kbahey For me, I never liked distributed authentication, be it from Microsoft Passport or from Drupal or anyone else. The point here is that you are trusting others to do security for you. Those others can be malicious, or can be slack in their security, or they got get hacked by someone else. So, for me, this is something that I will likely never use, whether it stays in core or not. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:10:13 +0000 : m3avrck I agree with all said points. I never had used drupal.module and never plan to. Great idea in concept, but in reality, just doesn't work. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:15:45 +0000 : Kobus I agree with the posts before, but will this influence the drupal-sites functionality? I have a few old Drupal 4.2 sites utilizing this feature to list themselves on the drupal-sites page. Regards, Kobus ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:30:37 +0000 : Bèr Kessels 1Though potetially insecure, iSSO is one of the best features in drupal. I'd rather notsee this end in the null bin, for it will then be lost. forever. What about a revive/rewrite? Here are my thoughts: case: drop.org user 'foo' log into Drupal drupal.org pings drop.org. Drop.org retruns TRUE if the pinged details are correct. foo(a)drop.org is NOT a user nor gets a uid on drupal.org. never! For as long as the session takes, he is a 'registered' user. if foo(a)drop.org visits 'my account' and changes anything in there, he gets a uid, welcome mail and a native drupal.org user. That has, from then on, nothing to do with drop.org, drop.org will never be pinged anymore. Off course one is required to fill in a new password and an email addy. if foo(a)drop.org never visits 'my account', or does not change anything in there, the user 'foo(a)drop.org' will be lost as soon as the session terminates. drupal.org user with a lot of rights 'foo' logs into drop.org drupal.org will send TRUE when it receives correct login details. foo(a)drupal.org is NOT a user nor gets a uid on drop.org. never! For as long as the session takes, he is a 'registered' user. but drop.org knows nothing, nor saves anything on drop.org. only packet sniffers can track the user details; This is very much how it works now, with one difference: you have to actively undertake something to me changed from remote user to native user. You have to actively undertake something to get yuour details in the database of the other site. This, Icw some common sense (Dries should be aware that he must not use his drupalID on WannaHackdrupal.pr0nnet.ro) thiswill do, IMO. First rule of securit is clarity: if your users see and feel what happens, your security is much better maintainable. This is not really the case ATM. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:31:40 +0000 : killes(a)www.drop.org I am using my username only for historical reasons. drop.org is down and I've not been using distributed auth for quite a while. I agree that drupal.module's distributed auth isn't up to date any more and people shoudl be discouraged from using it. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:55:44 +0000 : Prometheus6 The module would be useful if the side that does the authentication had a list of trusted sites. That would let you have single sign-on across a range of related sites. But that still means it's more appropriately a contribution module. ------------------------------------------------------------------------ Tue, 20 Sep 2005 15:52:16 +0000 : Peter Apockotos I like the idea of the module. I just wish it wasn't tied to drupal.org itself. Perhaps a setting of which (trusted) sites to share the information with instead. ------------------------------------------------------------------------ Tue, 20 Sep 2005 16:20:59 +0000 : nedjo Thanks for bringing this issue up, Robert. See for reference the related issue "Refactor and rename drupal module", http://drupal.org/node/29826 The near consensus I'm hearing is: 1. The functionality areas covered in the drupal.module are valuable and desired. 2. But the current implementation has serious flaws, and therefore fails to meet clearly the standards for drupal core inclusion. There are probably three basic options: 1. Keep the module in core, with the commitment to fixing its flaws. 2. Temporarily (e.g,. for one release cycle) pull the module from core with the aim of refining it enough for reinclusion. 3. Remove the module from core to contributions. While I agree with the serious limitations of the current implementation, I'd hate to see this functionality area disappear from core. Projects pulled from core tend to languish. So I favour options one or - perhaps better - two. Inter-site functionality similar to what is covered in drupal.module is in increasing demand. Projects like the telecentre.org initiative centre on such functionality. CivicSpace has expressed keen interest in improving the ability of webs of related sites to discover each other, connect, and pool information. Look again at our mission, http://drupal.org/node/10250. Inter-site connections are increasingly key to "the collaborative production of online information systems and communities". Let's focus on fixing the module! ------------------------------------------------------------------------ Tue, 20 Sep 2005 17:28:34 +0000 : javanaut Just contributing some links to the discussion here. There was previous discussion on distributed auth here: http://drupal.org/node/19113 Parts of this discussion fed what became OpenID: http://openid.net/ There's a PHP implementation of OpenID here (I've never used this, though): http://www.videntity.org/openid If somebody had time/motivation to develop an auth module that used this, I think it would bode well for Drupal, whether core or contrib. It's primary benefit is that you need not trust the site that you're logging in to, just your main server. You never enter your password into a non-trusted site.

1 0

[drupal-devel] [feature] Administration Control Panel suggestion
by der 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: der Status: patch (code needs review) Attachment: http://drupal.org/files/issues/system.module_13.patch (2.47 KB) new patch per chx's comment der Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy 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 ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance 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 ! ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:09:43 +0000 : der I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons? ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:16:15 +0000 : chx Maybe just because I created it, I like my control panel module better. ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:25:30 +0000 : der If I would have known there was a module I wouldn't have written this patch although I do think this would be good for core Drupal as the default. Is your modules a recent creation? I don't see it on drupal.org nor could I find in the contribs section of CVS (either the modules or sandbox sections). I'm I missing something? Is it called something different? ------------------------------------------------------------------------ Sat, 17 Sep 2005 18:20:15 +0000 : syllance 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 ? ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:24:11 +0000 : Amazon 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 ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:47:55 +0000 : der Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB) This has sparked a lot of good discussion. I've taken a look at cp.module and I think it really is complimentary with my proposed patch. I've taken my patch one step further and provided the settings icons in a collapsable group below the main control panel. This would allow access to all admin functions without referring to the traditional menu. Syllance, do you think this addresses the gap you saw in my solution? ------------------------------------------------------------------------ Sat, 17 Sep 2005 20:33:10 +0000 : der Kieran, I'm glad to see some serious thought going into the user experience for site administrators. I think separating the user and admin sections of the site is critical. It will not only allow extensive usability work to be done for site admins it will also make it much easier for theme creators as they will be able to focus on the end user experience. I like the admin theme for civicspace. My only dislike about the approach is that it's template driven which causes a sites template to be larger and more complex due to handling all the logic for user and admin themes. I think a better approach may be to use a module such as the sections module. This allows you to have smaller templates focused on user or admin themes. I agree with your point about making sure the control panel ties into them menu system. My approach uses the existing menu structure so modules are added dynamically and all permissions are enforced. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:21:05 +0000 : chx <?php 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. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:39:40 +0000 : der Thanks for the code feedback. I'm assuming the extracted style info would get patched to drupal.css? Your right about the duplicate code. A function would make more sense, I'll make the change. I'm not sure about the comment to use "$may_cache" I've never used it before. What's it's purpose? How should I use it in this situation. I'll dig around and see if I can figure it out but I thought you might be able to give me a little insight. Thanks! ------------------------------------------------------------------------ Sun, 18 Sep 2005 10:41:00 +0000 : syllance 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 :) ------------------------------------------------------------------------ Sun, 18 Sep 2005 12:54:55 +0000 : der Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB) Here's a new patch with the code reworked per chx's comments with the exception of his objection to my use of drupal_goto function. chx, I'm probably missing something really obvious but I'm not understanding your suggestion. Are you suggesting I use some menu function to do the redirect? If so, I could not find one that suits my needs. Or are you suggesting to use the drupal_goto function in a different manner than I am using it. Like I said, I'm probably missing something really obvious here but for the life of me I don't know what it is. Any further advice would be greatly appreciated. The offending code below: <?php function _system_adminpage () { drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL); } ?> ------------------------------------------------------------------------ Mon, 19 Sep 2005 13:42:57 +0000 : syllance 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 ------------------------------------------------------------------------ Mon, 19 Sep 2005 14:10:03 +0000 : der which theme and which browser are you using? ------------------------------------------------------------------------ Mon, 19 Sep 2005 15:59:16 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB) I've tested this with IE and FireFox with each of the Drupal shipped HEAD themes and I'm not seeing the issue you described. Are you sure the patch applied correctly to drupal.css? Here's a slightly revised patch. It make the control panel icon group collapsable but open by default. ------------------------------------------------------------------------ Mon, 19 Sep 2005 18:09:22 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB) Sorry for the excessive number of patches. I just realized that my previous patch had an issue with icon image file names if there were admin and admin/settings menu items that were the same (eg admin/user and admin/settings/user). New patch attached to address. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:13:49 +0000 : syllance 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 ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:19:54 +0000 : Amazon 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. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:25:06 +0000 : der Attachment: http://drupal.org/files/issues/Control Panel.png (101.02 KB) Sure, here's what the current version looks like with the civicspace admin theme. ------------------------------------------------------------------------ Tue, 20 Sep 2005 04:22:36 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_2.patch (5.48 KB) Patch fixing the issue that syllance pointed out and it also fixes the obvious issue with the drupal_goto function arguments. duh! ------------------------------------------------------------------------ Tue, 20 Sep 2005 19:02:41 +0000 : der Attachment: http://drupal.org/files/issues/system.module_12.patch (2.48 KB) I've thought about this and I think it makes sense to break this enhancement request up and provide the second request (Admin Control Panel) as an add-on module. Therefore I've scaled this patch back to handling only the first enhancement request: /Add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page./ ------------------------------------------------------------------------ Tue, 20 Sep 2005 19:12:41 +0000 : chx 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.

1 0

[drupal-devel] [feature] Administration Control Panel suggestion
by chx 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: chx Status: patch (code needs review) 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. chx Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy 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 ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance 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 ! ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:09:43 +0000 : der I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons? ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:16:15 +0000 : chx Maybe just because I created it, I like my control panel module better. ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:25:30 +0000 : der If I would have known there was a module I wouldn't have written this patch although I do think this would be good for core Drupal as the default. Is your modules a recent creation? I don't see it on drupal.org nor could I find in the contribs section of CVS (either the modules or sandbox sections). I'm I missing something? Is it called something different? ------------------------------------------------------------------------ Sat, 17 Sep 2005 18:20:15 +0000 : syllance 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 ? ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:24:11 +0000 : Amazon 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 ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:47:55 +0000 : der Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB) This has sparked a lot of good discussion. I've taken a look at cp.module and I think it really is complimentary with my proposed patch. I've taken my patch one step further and provided the settings icons in a collapsable group below the main control panel. This would allow access to all admin functions without referring to the traditional menu. Syllance, do you think this addresses the gap you saw in my solution? ------------------------------------------------------------------------ Sat, 17 Sep 2005 20:33:10 +0000 : der Kieran, I'm glad to see some serious thought going into the user experience for site administrators. I think separating the user and admin sections of the site is critical. It will not only allow extensive usability work to be done for site admins it will also make it much easier for theme creators as they will be able to focus on the end user experience. I like the admin theme for civicspace. My only dislike about the approach is that it's template driven which causes a sites template to be larger and more complex due to handling all the logic for user and admin themes. I think a better approach may be to use a module such as the sections module. This allows you to have smaller templates focused on user or admin themes. I agree with your point about making sure the control panel ties into them menu system. My approach uses the existing menu structure so modules are added dynamically and all permissions are enforced. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:21:05 +0000 : chx <?php 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. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:39:40 +0000 : der Thanks for the code feedback. I'm assuming the extracted style info would get patched to drupal.css? Your right about the duplicate code. A function would make more sense, I'll make the change. I'm not sure about the comment to use "$may_cache" I've never used it before. What's it's purpose? How should I use it in this situation. I'll dig around and see if I can figure it out but I thought you might be able to give me a little insight. Thanks! ------------------------------------------------------------------------ Sun, 18 Sep 2005 10:41:00 +0000 : syllance 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 :) ------------------------------------------------------------------------ Sun, 18 Sep 2005 12:54:55 +0000 : der Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB) Here's a new patch with the code reworked per chx's comments with the exception of his objection to my use of drupal_goto function. chx, I'm probably missing something really obvious but I'm not understanding your suggestion. Are you suggesting I use some menu function to do the redirect? If so, I could not find one that suits my needs. Or are you suggesting to use the drupal_goto function in a different manner than I am using it. Like I said, I'm probably missing something really obvious here but for the life of me I don't know what it is. Any further advice would be greatly appreciated. The offending code below: <?php function _system_adminpage () { drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL); } ?> ------------------------------------------------------------------------ Mon, 19 Sep 2005 13:42:57 +0000 : syllance 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 ------------------------------------------------------------------------ Mon, 19 Sep 2005 14:10:03 +0000 : der which theme and which browser are you using? ------------------------------------------------------------------------ Mon, 19 Sep 2005 15:59:16 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB) I've tested this with IE and FireFox with each of the Drupal shipped HEAD themes and I'm not seeing the issue you described. Are you sure the patch applied correctly to drupal.css? Here's a slightly revised patch. It make the control panel icon group collapsable but open by default. ------------------------------------------------------------------------ Mon, 19 Sep 2005 18:09:22 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB) Sorry for the excessive number of patches. I just realized that my previous patch had an issue with icon image file names if there were admin and admin/settings menu items that were the same (eg admin/user and admin/settings/user). New patch attached to address. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:13:49 +0000 : syllance 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 ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:19:54 +0000 : Amazon 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. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:25:06 +0000 : der Attachment: http://drupal.org/files/issues/Control Panel.png (101.02 KB) Sure, here's what the current version looks like with the civicspace admin theme. ------------------------------------------------------------------------ Tue, 20 Sep 2005 04:22:36 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_2.patch (5.48 KB) Patch fixing the issue that syllance pointed out and it also fixes the obvious issue with the drupal_goto function arguments. duh! ------------------------------------------------------------------------ Tue, 20 Sep 2005 19:02:41 +0000 : der Attachment: http://drupal.org/files/issues/system.module_12.patch (2.48 KB) I've thought about this and I think it makes sense to break this enhancement request up and provide the second request (Admin Control Panel) as an add-on module. Therefore I've scaled this patch back to handling only the first enhancement request: /Add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page./

1 0

[drupal-devel] [feature] Administration Control Panel suggestion
by der 20 Sep '05

20 Sep '05

Issue status update for http://drupal.org/node/31326 Post a follow up: http://drupal.org/project/comments/add/31326 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: der Updated by: der -Status: patch (code needs work) +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/system.module_12.patch (2.48 KB) I've thought about this and I think it makes sense to break this enhancement request up and provide the second request (Admin Control Panel) as an add-on module. Therefore I've scaled this patch back to handling only the first enhancement request: /Add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page./ der Previous comments: ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:50:52 +0000 : der Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB) New feature suggestion: I would like to suggest a couple of enhancments to administration pages. First, add a new general settings option to allow the user to specify the admin home page. Currently the watchdog log view is the default home page. Second, add a new control panel page that can be used as the default admin start page. I've attached a suggested patch to the CVS head version of the system.module that implements these two enhancements. The patch does the following. Adds a new "default admin page" text field to the general settings group (just after the "default front page"). It also changes the admin menu entry to call a new function that examines the default "admin page" variable and redirects to the appropriate path. For the control panel, the patch adds a new function (system_admin_controlpanel). This function basically looks for the admin entry in the menu structure and then iterates through the child menu items and builds a control panel page using the path and title information returned from the menu structure. For the control panel icons it looks for an icon file in the misc directory that matches the name of the menu item (e.g. user.png, access.png etc) If it doesn't find an icon it uses a default. I've also included some 48/48 icons that I borrowed from my usr/share/icon/gnome directory of my local Linux box. I believe these are gnome GPL'ed icons but any 48/48 icons could be used. This patch allows users who prefer the current functionality to keep it as their default. It provides the option for others to make any admin page they want to be their admin "home page" including using a graphical control panel. Module developers that add new admin menu options can add their own custom icons for the control panel but they are not "required" to do so as a default will be used if they don't provide one. ------------------------------------------------------------------------ Thu, 15 Sep 2005 17:52:15 +0000 : der Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB) 48x48 icons attached ------------------------------------------------------------------------ Fri, 16 Sep 2005 14:30:16 +0000 : der Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB) updated patch. slightly changed the formatting of the control panel page ------------------------------------------------------------------------ Sat, 17 Sep 2005 00:37:24 +0000 : moggy 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 ;-) ) ------------------------------------------------------------------------ Sat, 17 Sep 2005 13:02:08 +0000 : syllance 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 ! ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:09:43 +0000 : der I'll move the styles off to a style sheet but I'm uncertain about whether or not make make the default admin page a dropdown. It's an easy change and it eliminates any typos by the user but it also restricts the user to a current visible admin menu item. If by chance someone wanted to write their own admin start page (ie their own control panel) they would have to hack the core system.module to do it. Anyone else want to weigh in with their preference? Also, anyone up for creating drupalized versions of the control panel icons? ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:16:15 +0000 : chx Maybe just because I created it, I like my control panel module better. ------------------------------------------------------------------------ Sat, 17 Sep 2005 16:25:30 +0000 : der If I would have known there was a module I wouldn't have written this patch although I do think this would be good for core Drupal as the default. Is your modules a recent creation? I don't see it on drupal.org nor could I find in the contribs section of CVS (either the modules or sandbox sections). I'm I missing something? Is it called something different? ------------------------------------------------------------------------ Sat, 17 Sep 2005 18:20:15 +0000 : syllance 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 ? ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:24:11 +0000 : Amazon 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 ------------------------------------------------------------------------ Sat, 17 Sep 2005 19:47:55 +0000 : der Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB) This has sparked a lot of good discussion. I've taken a look at cp.module and I think it really is complimentary with my proposed patch. I've taken my patch one step further and provided the settings icons in a collapsable group below the main control panel. This would allow access to all admin functions without referring to the traditional menu. Syllance, do you think this addresses the gap you saw in my solution? ------------------------------------------------------------------------ Sat, 17 Sep 2005 20:33:10 +0000 : der Kieran, I'm glad to see some serious thought going into the user experience for site administrators. I think separating the user and admin sections of the site is critical. It will not only allow extensive usability work to be done for site admins it will also make it much easier for theme creators as they will be able to focus on the end user experience. I like the admin theme for civicspace. My only dislike about the approach is that it's template driven which causes a sites template to be larger and more complex due to handling all the logic for user and admin themes. I think a better approach may be to use a module such as the sections module. This allows you to have smaller templates focused on user or admin themes. I agree with your point about making sure the control panel ties into them menu system. My approach uses the existing menu structure so modules are added dynamically and all permissions are enforced. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:21:05 +0000 : chx <?php 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. ------------------------------------------------------------------------ Sat, 17 Sep 2005 22:39:40 +0000 : der Thanks for the code feedback. I'm assuming the extracted style info would get patched to drupal.css? Your right about the duplicate code. A function would make more sense, I'll make the change. I'm not sure about the comment to use "$may_cache" I've never used it before. What's it's purpose? How should I use it in this situation. I'll dig around and see if I can figure it out but I thought you might be able to give me a little insight. Thanks! ------------------------------------------------------------------------ Sun, 18 Sep 2005 10:41:00 +0000 : syllance 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 :) ------------------------------------------------------------------------ Sun, 18 Sep 2005 12:54:55 +0000 : der Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB) Here's a new patch with the code reworked per chx's comments with the exception of his objection to my use of drupal_goto function. chx, I'm probably missing something really obvious but I'm not understanding your suggestion. Are you suggesting I use some menu function to do the redirect? If so, I could not find one that suits my needs. Or are you suggesting to use the drupal_goto function in a different manner than I am using it. Like I said, I'm probably missing something really obvious here but for the life of me I don't know what it is. Any further advice would be greatly appreciated. The offending code below: <?php function _system_adminpage () { drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL); } ?> ------------------------------------------------------------------------ Mon, 19 Sep 2005 13:42:57 +0000 : syllance 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 ------------------------------------------------------------------------ Mon, 19 Sep 2005 14:10:03 +0000 : der which theme and which browser are you using? ------------------------------------------------------------------------ Mon, 19 Sep 2005 15:59:16 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB) I've tested this with IE and FireFox with each of the Drupal shipped HEAD themes and I'm not seeing the issue you described. Are you sure the patch applied correctly to drupal.css? Here's a slightly revised patch. It make the control panel icon group collapsable but open by default. ------------------------------------------------------------------------ Mon, 19 Sep 2005 18:09:22 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB) Sorry for the excessive number of patches. I just realized that my previous patch had an issue with icon image file names if there were admin and admin/settings menu items that were the same (eg admin/user and admin/settings/user). New patch attached to address. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:13:49 +0000 : syllance 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 ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:19:54 +0000 : Amazon 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. ------------------------------------------------------------------------ Tue, 20 Sep 2005 02:25:06 +0000 : der Attachment: http://drupal.org/files/issues/Control Panel.png (101.02 KB) Sure, here's what the current version looks like with the civicspace admin theme. ------------------------------------------------------------------------ Tue, 20 Sep 2005 04:22:36 +0000 : der Attachment: http://drupal.org/files/issues/control_panel_2.patch (5.48 KB) Patch fixing the issue that syllance pointed out and it also fixes the obvious issue with the drupal_goto function arguments. duh!

1 0