- Development - lists.drupal.org

[drupal-devel] [feature] Menu fast edit node links
by Dries 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/9178 Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: minor Assigned to: mathias Reported by: mathias Updated by: Dries Status: patch Yes, we need something like this in core but as explained, there is a depency on the new node form (and collapsible form/page elements in particular). Is anyone going to work on this? I'm determined to help get this in core ASAP but can't take a lead in this. Takers? Dries Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 19:15 : mathias Attachment: http://drupal.org/files/issues/menu_fast_edit.patch (1.18 KB) When developers are creating custom menus, the process of adding content becomes twofold: 1. Create content 2. Navigate to administer > menus > add menu item and add the latest node entry This patch adds a link hook to the menu module. Specifically if a node does not have a menu entry the 'add menu item' link appears. If a menu item exists, the 'edit menu item' and 'delete menu item' are displayed thereby speeding up the publishing workflow. Note: This feature is only present when the menu module is enabled. Status: Waiting for JonBobs blessing ... ------------------------------------------------------------------------ July 10, 2004 - 19:21 : JonBob This is interesting. I do have a couple reservations. This adds a bunch of queries to node listing pages, since it has to check for every node whether that node has a menu item set. I also wonder how much time this saves the user in reality. It saves navigating to the menu admin screen, sure, but provides little other help. It seems that if we are to provide a link to the menu item add page, we should at least be pre-filling in the path and title fields for the user. The provided method is little better than having the menu admin page open in another browser tab. Maybe a node link isn't the right interface for this, anyway? Possibly a tab, or a hook_nodeapi('form admin') injection? If done right, this could finally replace that aging "link title" field in page.module nodes. ------------------------------------------------------------------------ January 24, 2005 - 23:23 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link.patch (5.91 KB) This new patch gives users the ability to define menu items on any node creation/editing form. Screenshot here: http://asitis.org/tmp/menu_quick_link_form.png [1] It does this through nodeapi (as suggested by Jonbob), which means that any node has access to these fields unless specified otherwise via the new menu configuration settings. The functionality lives in menu.module, and users with 'administer menus' permission are allowed to edit the menu item fields inside the node form. One more note. I'm also proposing the addition of a misc/drupal.js [2] file to Drupal core (* gasp *). Currently it includes javascript functions to hide regions of a page. When a link is clicked on for a collapsed region, the region unfolds revealing the additional parts of a page. In this case the menu item fields are displayed after clicking the 'Menu item settings' link. I think it helps make best use of screen real estate, but we'll leave that verdict up to the usability experts. Let's remove the js file if it's the only thing stopping this patch from being submitted. I thought it might be worth exploring, especially for form pre and form post regions of the node form. [1] http://asitis.org/tmp/menu_quick_link_form.png [2] http://asitis.org/tmp/drupal.js ------------------------------------------------------------------------ January 24, 2005 - 23:34 : mathias Woops. Setting status to 'patch'. ------------------------------------------------------------------------ January 25, 2005 - 15:17 : Bèr Kessels +1 on the feature, I use menu_otf all the time. -1 for the javascript. Not that i am against it, ion contrary. I think we should not start implementing JS on a per-case basis, but we should introduce a javascript system that can do your accordeon-magick on any element. So it should wait IMO. ------------------------------------------------------------------------ January 25, 2005 - 17:07 : Dries I agree with Ber: +1 for the feature, -1 for the Javascript. This would (or should) be easy to implement/integrate as soon the new node forms are done. Both the new node forms, and this feature are crucial. ------------------------------------------------------------------------ January 27, 2005 - 22:39 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link_0.patch (4.12 KB) Okay, here's the latest patch, footloose and javascript free. ------------------------------------------------------------------------ February 1, 2005 - 10:04 : robertDouglass +1 to the feature, with or without javascript. The Menu item title:* is showing that it is required, but it can't be required as that would force users to create menu items (and it doesn't validate to be required). The patch does, however, open up a big can of permissions worms, and lacks configuration. I would like to see a checkbox on the Workflow (/admin/node/configure/types/{type}) page so that I can hide this on a per-type basis. Then, I think we need some way of limiting this by role, by user, and by menu. I would at least want an "excluded menus" list where I could, say turn off the main Navigation menu so that people don't go and trash it. Very cool feature in a very important direction! I sincerely hope this makes it into the code freeze. ------------------------------------------------------------------------ February 3, 2005 - 00:37 : Anonymous I removed the required mark next to menu item form field. Thanks for spotting that. I don't completely understand what you mean by this patch 'opening up a big can of permissions worms'. User's with 'administer menus' permission are simply given an easier way to add menu items while creating content. I think it's better to keep it simple to begin with. http://asitis.org/tmp/menu_quick_link_form.png [3] There actually is a configuration interface (settings/menu). Your menu cache probably needed to be cleared after applying the patch :-) On that page you can choose which node types acquire the quick menu item form field as well as define the default menu item. I disagree with putting the menu item form visibility settings on the admin/node/configure/types/{type} page. Those settings are for the default state of the node instance, not what's visible on the form field. For example, I wouldn't want to see a list of all 'form pre' and 'form post' fields on that page to select from, but it could be useful as a standard interface elsewhere. [3] http://asitis.org/tmp/menu_quick_link_form.png ------------------------------------------------------------------------ February 3, 2005 - 00:40 : mathias Last comment by 'learning to login' mathias. ------------------------------------------------------------------------ February 6, 2005 - 12:23 : Dries I'm going to put this on hold until the collapsbile form groups [4] settled. I encourage you to participate in the design and discussion so that it meets your requirements. The same should be done for other parts of the node edit form, so let's try to come up with a generic solution that can be used through an API that shields you from all Javascript details. [4] http://drupal.org/node/16204 ------------------------------------------------------------------------ March 14, 2005 - 00:13 : killes(a)www.drop.org Hmm, should we have a status "on hold"? I am unsure what to do with this one. It still applies. ------------------------------------------------------------------------ March 29, 2005 - 12:15 : TDobes +1 on this... trying to explain to users that they need to add their pages, then add their pages to the menu system (and explain why) was incredibly difficult... menu_otf has helped with this, and I think this sort of functionality really belongs in core.

1 0

[drupal-devel] [bug] User feedback if commenting on a closed node
by TDobes 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/10417 Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: TDobes Status: patch +1 from me too... although with one minor complaint: we want to say "post" rather than "posts" in the error message. Although this is a rare case, it is one users may sometimes encounter... and a total lack of feedback as we have now is bad. TDobes Previous comments: ------------------------------------------------------------------------ August 28, 2004 - 13:37 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/comment_2.diff (701 bytes) If a user (for whatever reason) tries to post to a node which doesn't allow this, he currently doesn't get an error message. This patch fixes this. ------------------------------------------------------------------------ September 5, 2004 - 01:02 : killes(a)www.drop.org recategorizing to show up in the patch queue. ------------------------------------------------------------------------ September 13, 2004 - 20:42 : Steven I'm not 100% sure about this patch. We don't normally cater to inaccessible forms. I suppose the comment form is a candidate, when a moderator disables commenting on a (heated?) topic while people are still typing replies. But are there more probably situations like this out there? ------------------------------------------------------------------------ September 14, 2004 - 00:37 : killes(a)www.drop.org As you mentioned the comment form isn't neccessarily inaccessible, the sending of the comment might become later. We should present a meaningfull message to the user in that case. I am developing a module where you can only comment for a limited amount of time, so no message is actually confusing. ------------------------------------------------------------------------ September 14, 2004 - 15:03 : Dries I don't think this needs fixing. ------------------------------------------------------------------------ September 14, 2004 - 15:17 : killes(a)www.drop.org I disagree. The user doesn't get a 403 or anything, just an empty "Post comment" page.Tha's bad usability. ------------------------------------------------------------------------ October 14, 2004 - 16:54 : drumm +1 Although it is a rare case, this is a really simple fix that might as well go in. ------------------------------------------------------------------------ March 13, 2005 - 15:02 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/comment_2_0.diff (723 bytes) Updated to cvs. Better wording.

1 0

[drupal-devel] [feature] Menu fast edit node links
by TDobes 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/9178 Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: minor Assigned to: mathias Reported by: mathias Updated by: TDobes Status: patch +1 on this... trying to explain to users that they need to add their pages, then add their pages to the menu system (and explain why) was incredibly difficult... menu_otf has helped with this, and I think this sort of functionality really belongs in core. TDobes Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 11:15 : mathias Attachment: http://drupal.org/files/issues/menu_fast_edit.patch (1.18 KB) When developers are creating custom menus, the process of adding content becomes twofold: 1. Create content 2. Navigate to administer > menus > add menu item and add the latest node entry This patch adds a link hook to the menu module. Specifically if a node does not have a menu entry the 'add menu item' link appears. If a menu item exists, the 'edit menu item' and 'delete menu item' are displayed thereby speeding up the publishing workflow. Note: This feature is only present when the menu module is enabled. Status: Waiting for JonBobs blessing ... ------------------------------------------------------------------------ July 10, 2004 - 11:21 : JonBob This is interesting. I do have a couple reservations. This adds a bunch of queries to node listing pages, since it has to check for every node whether that node has a menu item set. I also wonder how much time this saves the user in reality. It saves navigating to the menu admin screen, sure, but provides little other help. It seems that if we are to provide a link to the menu item add page, we should at least be pre-filling in the path and title fields for the user. The provided method is little better than having the menu admin page open in another browser tab. Maybe a node link isn't the right interface for this, anyway? Possibly a tab, or a hook_nodeapi('form admin') injection? If done right, this could finally replace that aging "link title" field in page.module nodes. ------------------------------------------------------------------------ January 24, 2005 - 15:23 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link.patch (5.91 KB) This new patch gives users the ability to define menu items on any node creation/editing form. Screenshot here: http://asitis.org/tmp/menu_quick_link_form.png [1] It does this through nodeapi (as suggested by Jonbob), which means that any node has access to these fields unless specified otherwise via the new menu configuration settings. The functionality lives in menu.module, and users with 'administer menus' permission are allowed to edit the menu item fields inside the node form. One more note. I'm also proposing the addition of a misc/drupal.js [2] file to Drupal core (* gasp *). Currently it includes javascript functions to hide regions of a page. When a link is clicked on for a collapsed region, the region unfolds revealing the additional parts of a page. In this case the menu item fields are displayed after clicking the 'Menu item settings' link. I think it helps make best use of screen real estate, but we'll leave that verdict up to the usability experts. Let's remove the js file if it's the only thing stopping this patch from being submitted. I thought it might be worth exploring, especially for form pre and form post regions of the node form. [1] http://asitis.org/tmp/menu_quick_link_form.png [2] http://asitis.org/tmp/drupal.js ------------------------------------------------------------------------ January 24, 2005 - 15:34 : mathias Woops. Setting status to 'patch'. ------------------------------------------------------------------------ January 25, 2005 - 07:17 : Bèr Kessels +1 on the feature, I use menu_otf all the time. -1 for the javascript. Not that i am against it, ion contrary. I think we should not start implementing JS on a per-case basis, but we should introduce a javascript system that can do your accordeon-magick on any element. So it should wait IMO. ------------------------------------------------------------------------ January 25, 2005 - 09:07 : Dries I agree with Ber: +1 for the feature, -1 for the Javascript. This would (or should) be easy to implement/integrate as soon the new node forms are done. Both the new node forms, and this feature are crucial. ------------------------------------------------------------------------ January 27, 2005 - 14:39 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link_0.patch (4.12 KB) Okay, here's the latest patch, footloose and javascript free. ------------------------------------------------------------------------ February 1, 2005 - 02:04 : robertDouglass +1 to the feature, with or without javascript. The Menu item title:* is showing that it is required, but it can't be required as that would force users to create menu items (and it doesn't validate to be required). The patch does, however, open up a big can of permissions worms, and lacks configuration. I would like to see a checkbox on the Workflow (/admin/node/configure/types/{type}) page so that I can hide this on a per-type basis. Then, I think we need some way of limiting this by role, by user, and by menu. I would at least want an "excluded menus" list where I could, say turn off the main Navigation menu so that people don't go and trash it. Very cool feature in a very important direction! I sincerely hope this makes it into the code freeze. ------------------------------------------------------------------------ February 2, 2005 - 16:37 : Anonymous I removed the required mark next to menu item form field. Thanks for spotting that. I don't completely understand what you mean by this patch 'opening up a big can of permissions worms'. User's with 'administer menus' permission are simply given an easier way to add menu items while creating content. I think it's better to keep it simple to begin with. http://asitis.org/tmp/menu_quick_link_form.png [3] There actually is a configuration interface (settings/menu). Your menu cache probably needed to be cleared after applying the patch :-) On that page you can choose which node types acquire the quick menu item form field as well as define the default menu item. I disagree with putting the menu item form visibility settings on the admin/node/configure/types/{type} page. Those settings are for the default state of the node instance, not what's visible on the form field. For example, I wouldn't want to see a list of all 'form pre' and 'form post' fields on that page to select from, but it could be useful as a standard interface elsewhere. [3] http://asitis.org/tmp/menu_quick_link_form.png ------------------------------------------------------------------------ February 2, 2005 - 16:40 : mathias Last comment by 'learning to login' mathias. ------------------------------------------------------------------------ February 6, 2005 - 04:23 : Dries I'm going to put this on hold until the collapsbile form groups [4] settled. I encourage you to participate in the design and discussion so that it meets your requirements. The same should be done for other parts of the node edit form, so let's try to come up with a generic solution that can be used through an API that shields you from all Javascript details. [4] http://drupal.org/node/16204 ------------------------------------------------------------------------ March 13, 2005 - 16:13 : killes(a)www.drop.org Hmm, should we have a status "on hold"? I am unsure what to do with this one. It still applies.

1 0

[drupal-devel] [feature] common.inc Move textarea pre hook between title and textarea
by TDobes 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/18828 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: TDobes Status: patch +1... I'm pretty sure the current positioning was accidental anyway... it was always meant to go directly above the textarea. TDobes Previous comments: ------------------------------------------------------------------------ March 13, 2005 - 03:52 : jbond Attachment: http://drupal.org/files/issues/common.inc_10.patch (1.8 KB) This patch moves the textarea hook for 'pre' between the title and the textarea. This makes it easier for simply textarea enhancements like quicktags to add a toolbar just above the textarea. It doesn't appear to have any effect on the fckeditor or htmlarea modules. It doesn't introduce any new hooks. ------------------------------------------------------------------------ March 13, 2005 - 11:56 : killes(a)www.drop.org Guess that is a patch. ------------------------------------------------------------------------ March 14, 2005 - 07:38 : Bèr Kessels +1 From me. Any module that adds something, will want to add it after the title. I really cannot think of any case where aditional content should sit above the title, but I can think of loads of cases where content needs to sit between the title and textarea. ------------------------------------------------------------------------ March 14, 2005 - 17:20 : stefan nagtegaal Indeed, nice and simple patch! +1 from me either.. ------------------------------------------------------------------------ March 15, 2005 - 08:13 : jbond http://www.voidstar.com/node.php?id=2263 [1] If this patch gets accepted I'll drop this into contrib. It's similar to quicktags but *I* like it better. ;-) [1] http://www.voidstar.com/node.php?id=2263

1 0

[drupal-devel] [bug] Menu cache is not locale aware
by chx 29 Mar '05

29 Mar '05

Issue status update for http://drupal.org/node/13503 Project: Drupal Version: cvs Component: menu system Category: bug reports -Priority: normal +Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch I have bumped this to critical status, I feel this very important, very simple, non evasive. chx Previous comments: ------------------------------------------------------------------------ November 26, 2004 - 08:13 : chx Attachment: http://drupal.org/files/issues/menu_locale.patch (522 bytes) If you have a multi language site, and change languages, the menu is already cached, thus it can not display the translated version. This simple patch makes the menu cache locale aware. Do I need to file the same patch against HEAD? 'Cos it applies, too. ------------------------------------------------------------------------ November 26, 2004 - 10:13 : Dries Isn't it better to flush the menu cache when someone (or the admin) switches languages? Keeps the cache size down. ------------------------------------------------------------------------ November 26, 2004 - 12:20 : chx There could be several points where the language is changed. i18n for example displays a language selection block which lets you switch anytime. Thus I think this solution is the best. ------------------------------------------------------------------------ November 26, 2004 - 13:26 : Goba See also this issue [1], which is still (again) open. The locale is also changed, when the admin changes it as the default on the admin interface, and the menu cache needs to be flushed then, and the admin needs to be redirected. I don't know how these problems are solved currently, so I would only be able to submit a placebo patch to make that issue pop up again... [1] http://drupal.org/node/11312 ------------------------------------------------------------------------ November 26, 2004 - 14:28 : Bèr Kessels I solved it by adding some logic to the swithcer function in i18n: when a language is switched the cache is flushed. The negative side of this, is that if you have hundred various roles of users reading English and one switching to German, the complete cahce is flushed. But then again, who has so many roles, that this might become an issue? ------------------------------------------------------------------------ November 27, 2004 - 10:59 : Dries I just fixed bug 11312 [2]. I don't see what's wrong with invalidating the user's menu cache when he or she switches language. Just do: <?php cache_clear_all("menu:$user->uid"); ?> [2] http://drupal.org/node/11312 ------------------------------------------------------------------------ January 30, 2005 - 20:26 : Jose A Reyero This is needed also for i18n. Invalidating cache is not a solution here, as we would need to do it also for anonymous users. So I think this is a simple solution and will work fine for both cases, user/locale and i18n. ------------------------------------------------------------------------ January 31, 2005 - 16:15 : Bèr Kessels I found out what is wrong with this: Swithcing and cache are two completely differetn things: The language is a per-session setting. The cache is a per-role setting. So any user can switch langauge on any moment, resulting in a cahce that will get flushed on nearly every page-load. And since roles and sessions are tow different thingsm we should not flush a role based cache because a variable in the session changes. The only correct option would be to have per-locale cache. (as per Jose's patch) ------------------------------------------------------------------------ January 31, 2005 - 16:27 : Bèr Kessels Correction, It was not José that submitteed the patch for locale aware menu's but Károly Négyesi, I got confused because José was the last to comment on that patch. ------------------------------------------------------------------------ February 2, 2005 - 21:44 : moshe weitzman i can't make heads or tails of this patch request. it seems that some folks are confusing menu cache and page cache. and we don't even have a role cache. dries' question remains unanaswered. why can we not just rebuild a user's menu cache when needed? ------------------------------------------------------------------------ February 2, 2005 - 22:17 : Jose A Reyero /why can we not just rebuild a user's menu cache when needed?/ This way you cannot have menus in multiples languages for anonymous users, unles they're not cached at all. ------------------------------------------------------------------------ February 2, 2005 - 22:27 : moshe weitzman Aha! Makes sense now. +1 for this simple patch. ------------------------------------------------------------------------ March 13, 2005 - 23:10 : killes(a)www.drop.org I agree, this should get patched. Still applies. ------------------------------------------------------------------------ March 14, 2005 - 00:24 : stefan nagtegaal Tested against 4.6 RC I and works perfectly! +1 for applying this bug-fix.. ------------------------------------------------------------------------ March 14, 2005 - 14:23 : Bèr Kessels Josés latest comment tels in much less wording what i tried to explain too. Still +1 from me, since with i18n (and other possible language modules) you cannot simply flush the cache. This patch is simple, clean and only adds one row per language to your cache table. That cannot be a problem, now, can it? ------------------------------------------------------------------------ March 26, 2005 - 20:56 : elfur I'd like to +1 this change. I too have a dual language website where changing the language in the language block does not change the language of the navigation block, while all other blocks change. But what also happens is that on my user profile page I can select which language are assigned to the user, and when I swithced that the first time, the language of the navigation block got switched to the selected language of the web - however when I changed that user profile setting back to my preferred language, the navigation block does not change back with it. Infact, when I then change the language in the language block, the navigation does not change back to what it was stuck at before *shrug*. I hope that does make sense to anyone. /me heads over to try that patch to see if it fixes this annoying "feature" thanks elfur http://elfur.is

1 0

[drupal-devel] Orphaning fixentities module
by neil＠civicspacelabs.org 29 Mar '05

29 Mar '05

Apparently I don't care about keeping this module current and working. I'll be removing it from CVS HEAD and deleting http://drupal.org/project/fixentities sometime between tomorrow and later this week unless I hear that I shouldn't. -Neil

1 0

[drupal-devel] Image.inc and separation of gd2
by Tim Altman 29 Mar '05

29 Mar '05

Greetings, I've been looking into the image.inc code and I'm unhappy with the amount of gd2-specific code in that file. The logic in many of the functions has special cases for gd2 that would be unnecessary if gd2 were another external toolkit, rather than integrated with image.inc. Couldn't we distribute Drupal with image.inc and image.gd2.inc? I think that would make all the image code simpler, more readable, and more maintainable. -- Tim Altman

2 4

[drupal-devel] Re: [feature] theme each group differently
by Chris Messina 28 Mar '05

28 Mar '05

How does this themable group stuff work? I guess you choose a full theme per group (I haven't tested it out yet)? I wonder if it would make sense to work with the /admin theme idea? For example, you could specifiy /group and then /group/alternate01 and /group/alternate02 for different color schemes or something? I dunno. Sorry for stabbing in the dark. Chris On Mon, 28 Mar 2005 21:33:43 +0200, moshe weitzman <og(a)tejasa.com> wrote: > Issue status update for http://drupal.org/node/17286 > > Project: Organic groups > Version: cvs > Component: Miscellaneous > Category: feature requests > Priority: normal > Assigned to: moshe weitzman > Reported by: Alaska > Updated by: moshe weitzman > Status: active > > comitted to HEAD. since this feature is not yet optimized, i don't > recommend using HEAD og on a production site for a few days until a > patch to core gets approved. i will close this issue when that happens. > > > moshe weitzman > > Previous comments: > ------------------------------------------------------------------------ > > February 13, 2005 - 16:19 : Alaska > > Using your module to create two groups. These are accessed from the > home Drupal page. The groups are green and brown. Green has a node of > node/5 and brown is node/2. Both are accessible from the groups menu > and work well. > There is an issue that may not be a part of your code. When using > section module to add a unique theme to each group I run into an > interesting issue. The new theme is available when I go to green at > node/5. However, when in the green theme and comments, reply or blog > are accessed the theme returns to default of blue. i.e. path is then > not correct. This is the path for accessing a comment when on the green > part of the site. http://localhost/drupal/node/18#comment. > The issue appears to be related in generating the correct path for the > section module. There is a place for that code, but I am not sure what > the interaction is between the two modules. i.e. what path code should > be used so that all of the sub pages (nodes) in green will still be in > the green theme and not revert back to the default of blue. > The overall plan is to have a number of groups in one Drupal site , but > each with their own unique theme. > This issue may have nothing to due with either module but just my > understanding of how a path works in Drupal. Any help in addressing > the path issue is appreciated. > Jim > > ------------------------------------------------------------------------ > > March 1, 2005 - 21:54 : moshe weitzman > > it is not yet possible to theme each group differently. this is a non > trivial feature request. > > ------------------------------------------------------------------------ > > March 20, 2005 - 00:54 : moshe weitzman > > coming soon > >

2 1

[drupal-devel] [task] RSS feeds for forums
by drumm 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/19607 Project: Drupal Version: cvs Component: forum.module Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/forum.module_2.diff (546 bytes) Forums have RSS feeds since they are taxonomy-powered. We should link to those feeds from the forum pages. drumm

2 1

[drupal-devel] [bug] Getting a "gd2" error when I save settings
by nysus 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/19517 Project: Drupal Version: cvs Component: system.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: nysus Status: active I compiled my version of PHP with the --with-gd option on. I do not have the image.module installed. I get the following error in my watchdog logs: details Typephp DateSaturday, March 26, 2005 - 20:56 Usertest [1] Location/admin/settings [2] MessageThe selected image handling toolkit '/gd2/' can not correctly process '/image_gd2_settings/'. Severityerror Hostname192.168.1.6 [1] http://drupal.org/user/1\" title=\"View user profile. [2] http://drupal.org//admin/settings nysus

4 7