May 2006 - Development - lists.drupal.org

Re: [development] Move all core modules into their own directories.
by Kobus Myburgh 03 May '06

03 May '06

> Largely, I think of new features for core only. Contrib is an absolute > mess. Worrying about poor help in contrib, for example, is far less than > important than the hundreds of security holes and injections possible. True that, true that. > With that said, being able to have the doc team create a metadata file > with help in it is a lot more "kosher" and "honorable" then actually Again, correct. > (Assuming, of > course, that the doc team gets so bored as to start writing help for > contrib modules that don't have pride in them). Ahh, hit me with my own noodle now, will ya? :-P No offense to ANYONE out there, really. But it is true! A lot of modules were just made to scratch an itch in a particular version and some of them aren't even ported from version to version. Regards, Kobus

1 0

Re: [development] Move all core modules into their own directories.
by Kobus Myburgh 03 May '06

03 May '06

> One of the "problems" I was hoping to solve with the metadata files > being PHP is we have a chance to move the entire _help hook there, which > will make the .module file smaller, will give the doc team their own > little "namespace" to worry about, and will lessen the load of the > .module file in memory (since we're not loading all the help text in, > especially when, for a visitor it rarely, if ever, gets parsed). While I understand your point here too, Morbus, I do feel that the contents of the _help() hook is abysmally little in most contrib modules, except the ones that the author took real pride in making, such as eCommerce, Views and a few others. Some modules were written to scratch an itch and stayed that way for several versions of Drupal, mostly just porting it to the new version (if at all) and weren't actively developed. Such modules often have less-than-sufficient help information, so my question is this: "How much space will this save in .module files?" Of course this point I make above is only for contrib, not for Core. If a module can be 3K smaller on average for Core and 500 bytes smaller on average for contrib modules, just how much would this increase performance? Kobus

2 1

Re: [Drupal feature] Default admin page
by David Reed 03 May '06

03 May '06

Agreed, that was the purpose of the 4.6/4.7 administration module done for civicspace. (i.e. rearrange the menus to be more logical and provide a "home" page for admins) About half the work done in the administration module was to remap all the admin menus. The other half was to provide a configurable admin "Home" page. The first part, remapping menu items, should all go into core and the contribs. The second part might be useful as a base for an admin home page. On 5/3/06, drumm <development(a)drupal.org> wrote: > > 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: drumm > -Status: patch (code needs review) > +Status: patch (code needs work) > > I was able to replace the admin screen with a URL alias. > > > Since HEAD development is reopened, I think we should consider > /incrementally/ changing the administration section to be something > more useful than logs and more organized than the menu. And > establishing standards for contrib modules to properly integrate their > items and for us to stay on track in core. > > > > > drumm > > > > 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.61KB) > > 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.48KB) > > 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.47KB) > > new patch per chx's comment > > > > > ------------------------------------------------------------------------ > > Tue, 20 Sep 2005 21:43:37 +0000 : syllance > > 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² :) > > > > > ------------------------------------------------------------------------ > > Wed, 21 Sep 2005 04:52:45 +0000 : der > > FYI control panel module posted at http://drupal.org/node/31806 > > > > > ------------------------------------------------------------------------ > > Tue, 11 Oct 2005 02:28:47 +0000 : der > > Attachment: http://drupal.org/files/issues/system.module_14.patch (1.78KB) > > rerolled patch for current CVS HEAD > > > > > ------------------------------------------------------------------------ > > Thu, 13 Oct 2005 21:07:41 +0000 : der > > Attachment: http://drupal.org/files/issues/system.module_14_0.patch (1.79KB) > > rerolled again for HEAD due to forms API changes > > > > > ------------------------------------------------------------------------ > > Fri, 28 Oct 2005 13:44:50 +0000 : killes(a)www.drop.org > > We do allow to set a custom front page, so this change makes sense to > me. > > > > > ------------------------------------------------------------------------ > > Fri, 28 Oct 2005 14:13:02 +0000 : moshe weitzman > > Patch looks OK except for one thing: > > > look at how index.php handles the $return value of > menu_execute_active_handler(). We should do same here. Ideally, you > should refactor this handling into a new function and use it in both > places. Perhaps the function should be called > menu_print_active_handler(). > > > > > ------------------------------------------------------------------------ > > Fri, 28 Oct 2005 14:16:06 +0000 : Dries > > Care to share a screenshot? > > > > > ------------------------------------------------------------------------ > > Fri, 28 Oct 2005 14:45:19 +0000 : moshe weitzman > > Dries - there is a screenshot in this issue. See > http://drupal.org/files/issues/Control%20Panel.png > > > > > ------------------------------------------------------------------------ > > Fri, 28 Oct 2005 21:03:43 +0000 : der > > Attachment: http://drupal.org/files/issues/default_admin.patch (3.42 KB) > > New patch with changes suggested by Moshe > > > > > ------------------------------------------------------------------------ > > Fri, 28 Oct 2005 21:04:46 +0000 : der > > Attachment: http://drupal.org/files/issues/default_admin.png (26.45 KB) > > Screenshot of just the admin/settings UI change. > > > > > ------------------------------------------------------------------------ > > Thu, 17 Nov 2005 14:51:21 +0000 : der > > Attachment: http://drupal.org/files/issues/default_admin_page.patch (3.42KB) > > rerolled again for latest HEAD > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 00:23:34 +0000 : chx > > Huh! Instead of menu_print_active_handler(); a simple return > menu_execute_active_handler(); isn't enough? > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 02:53:29 +0000 : der > > chx, I changed it at moshe's request (see his comments futher up the > post). I'm fine with doing it either way. > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 03:41:26 +0000 : Richard Archer > > The only thing I can see that needs attention is the phpdoc on > menu_print_active_handler(). This is the same as the first line of the > phpdoc for menu_execute_active_handler(). These functions do different > things so one of them must be wrong. > > > Perhaps the menu_print_active_handler phpdoc should mention displaying > the page or an appropriate error message. > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 04:24:29 +0000 : der > > Attachment: http://drupal.org/files/issues/default_admin_page2.patch (3.47KB) > > New patch with changed phpdoc comment. It now reads: > > > /** > * Execute the handler associated with the active menu item and > * return the page or an appropriate error message. > */ > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 04:30:08 +0000 : Richard Archer > > I like it! > +1 > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 05:09:32 +0000 : asimmonds > > For me, this makes it too easy to break my admin pages. If I enter > something invalid into the default admin page textfield, Apache crashes > when I goto /admin next time. The values that I tried were 'admin', > 'admin/not-exist' and a empty value, all crashed Apache. As well, if I > set it to a page that generates a 404, then the administer menu is not > expanded, making it harder to get to /admin/settings. > Could someone please confirm wether I'm not the only one that has > problems with this. > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 05:15:50 +0000 : Richard Archer > > You are right. Apache crashes if the page is not found. > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 05:51:38 +0000 : chx > > Also to Moshe: we are returning the value of menu_execute_active_handler > so why would we need to handle it ourselves? index.php will handle for > us if I am not mistaken. > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 12:48:27 +0000 : moshe weitzman > > chx - you might be right about. the previous patch had duplicated code > between drupal_ite_offline() and index.php and thats what i want to > avoid. i think a better solution would be to remove the break; in the > OFFLINE branch? > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 15:09:12 +0000 : der > > I wasn't able to get Apache to crash on my system but I do see a problem > with entering a path like 'admin/not-exist'. This causes a looping > condition as the menu system will fall back to the first valid menu > item in the path. Which in this case is 'admin' which obviously is the > same path that was called in the first place. One way to resolve this > would be to validate that the path entered maps to a valid menu item in > the menu array first BEFORE 'menu_set_active_item' is called. Another > way to address this would be to change the 'textfield' on the > admin/settings page to a 'select' that contains only valid menu items > to be selected. The only downside I see to this is I think it would > require a new function similar to 'menu_parent_options' only it would > have to return all valid/selectable menu items. > > > OR > > > We could go a much simpler route. The existing admin menu entery look > like this with the callback directly to a watchdog function. > > > $items[] = array('path' => 'admin', 'title' => t('administer'), > 'access' => user_access('access administration pages'), > 'callback' => 'watchdog_overview', > 'weight' => 9); > How about just allowing the function to be overridden by a variable? > > > $items[] = array('path' => 'admin', 'title' => t('administer'), > 'access' => user_access('access administration pages'), > 'callback' => <em>variable_get('site_adminpage', > 'watchdog_overview'),</em> > 'weight' => 9); > This is a simple one line change. The variable does not have to be > changable in core drupal admin/settings. And it give module developers > an easy way to override the default. > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 15:11:30 +0000 : der > > oops...ignore my <em></em> tags in my last post > > > > > ------------------------------------------------------------------------ > > Fri, 18 Nov 2005 18:06:18 +0000 : der > > Attachment: http://drupal.org/files/issues/default_admin_variable.patch ( > 1.17 KB) > > Here's a patch for the 'simpler' approach described in my last post. > > > > > ------------------------------------------------------------------------ > > Tue, 06 Dec 2005 11:49:46 +0000 : moshe weitzman > > this apache crash problem needs fixing before this can be accepted. > > > also, the most recent patch lacks a settings form field. not sure if > thats deliberate or not. > > > > > ------------------------------------------------------------------------ > > Tue, 06 Dec 2005 14:12:25 +0000 : der > > It was deliberate. See my posting on 11/18. I'm suggesting to scale > this patch back to only providing a variable for the now hard coded > function name of "watchdog_overview". I don't think it makes sense to > provide a settings form field for this. > > > > > ------------------------------------------------------------------------ > > Mon, 02 Jan 2006 02:43:07 +0000 : der > > Just checked and this patch still applies cleanly to the latest version > of the system.module. > > > > > ------------------------------------------------------------------------ > > Tue, 02 May 2006 22:29:01 +0000 : killes(a)www.drop.org > > moving to cvs. I am also wondering if you couldn't replace the default > overview suign a module that hijacks the /admin path. > > > > >

1 0

Officially supported browsers
by Neil Drumm 03 May '06

03 May '06

Occasionally we run into a spot where we need to decide what browsers we support for a certain issue. Lets make a standard list so we can stick to it. - What is the current de facto standard? - What are some good statistics? -- Neil Drumm http://delocalizedham.com/

5 5

Re: [Drupal bug] Aggregator module using wrong unique ID for feed items?
by Steve Dondley 03 May '06

03 May '06

I'm going to hold off on making patches for the database and update files until I'm sure this patch will be approved. On 5/3/06, Zen <development(a)drupal.org> wrote: > Issue status update for > http://drupal.org/node/61433 > Post a follow up: > http://drupal.org/project/comments/add/61433 > > Project: Drupal > Version: 4.7.0 > Component: aggregator.module > Category: bug reports > Priority: normal > Assigned to: Anonymous > Reported by: Steve Dondley > Updated by: Zen > -Status: patch (code needs review) > +Status: patch (code needs work) > > No idea about the issue, but if this requires a DB change, the patch > should incorporate the changes to database.mysql (4.0 and 4.1), > database.pgsql and updates.inc. > > > Thanks, > -K > > > > > Zen > > > > Previous comments: > ------------------------------------------------------------------------ > > Tue, 02 May 2006 15:12:28 +0000 : Steve Dondley > > For background, please see: http://drupal.org/node/61427 > > > I don't know much about RSS but I think the aggregator should be using > the *guid* of the feed item as the unique identifier and not the *url* > of the feed item. > > > > > ------------------------------------------------------------------------ > > Tue, 02 May 2006 15:59:01 +0000 : Steve Dondley > > Attachment: http://drupal.org/files/issues/aggregator_dup.patch (3.5 KB) > > OK, here's a first stab at a fix. > > > > > ------------------------------------------------------------------------ > > Wed, 03 May 2006 06:35:19 +0000 : Steve Dondley > > One other thing: > > > In addition to applying the patch, you have to create a new field in > the aggregator_item table called "guid". It's a varchar with a length > of 255. > > > > > -- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com

1 0

DHTML Image Cropper
by Adrian Rossouw 03 May '06

03 May '06

http://www.speedingrhino.com/cropper.htm -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

5 6

100 person Skypecasts free
by Kieran Lal 03 May '06

03 May '06

I think regular conference calls with up to 100 people for free could really help rally the community.: https://skypecasts.skype.com/ skypecasts/home -Drupal Core calls -Event calls -Organic Group calls -Consulting calls -Documentation calls -Training calls Cheers, Kieran

1 0

For 4.8 inclusion
by Earl Miles 03 May '06

03 May '06

Neil (and everybody who has an interest) -- I'd like to submit the na_arbitrator package, or at least the core of it, for merging into core. I don't think what I have is a good final solution, but it is a good next step in making Drupal's node_access behave more reliably. And with that, I would then like to consider integrating the forum_access code directly into the forum module, which would make a lot of people very happy, though I'm on the fence as to whether it should actually be done.

3 2

cvs non-branch tags
by Morten Wulff 03 May '06

03 May '06

Is it possible to add non-branch tags to modules in the /contributions? I'm about to make a major update of banner.module and I would like to mark the latest "known good" version. When I try to tag using TortoiseCVS, I get the following errors: --begin-- In D:\projekter\drupal\drupal-HEAD\modules\banner: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "--lf" "tag" "-c" "pre-node-conversion-20060417" "." CVSROOT=:pserver:wulff@cvs.drupal.org:/cvs/drupal-contrib Invalid tag for /contributions/modules/banner. cvs tag: Pre-tag check failed Invalid tag for /contributions/modules/banner/contributed/theme. cvs tag: Pre-tag check failed Invalid tag for /contributions/modules/banner/po. cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! --end-- Med venlig hilsen / Kind regards, Morten Wulff -- Self Injury Information and Support: http://www.psyke.org/ "I did not, you see, want to kill myself. Not at that time, anyway. But I wanted to know that if need be, if the desperation got so terribly bad, I could inflict harm on my body. And I could." - Elizabeth Wurtzel

3 3

Module data not loaded automatically into $user
by Sammy Spets 03 May '06

03 May '06

Hey there everyone, I'm looking through the bug reports and there is one (at least) i'm happy to fix. Just need a little info from the powers that be. http://drupal.org/node/46551 Is it by design that drupal not load module data into the $user object during bootstrap? I've written modules myself where it has to be done manually. Cheers, -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/

2 2