March 2005 - Development - lists.drupal.org

[drupal-devel] Re: [contributions:ber] /sandbox/ber/blog README.txt
by Dries Buytaert 22 Mar '05

22 Mar '05

On 21 Mar 2005, at 22:17, drupal-cvs(a)drupal.org wrote: > User: ber Branch: HEAD Date: Mon, 21 Mar 2005 21:17:10 +0000 > > Added files: > /sandbox/ber/blog README.txt > > Log message: > adding a readme with some wishes etc. Untill this gets its own > project on drupal.org feature requests etc can be tracked in this > file. This might be core worthy. Don't start a project but upload a patch to the patch queue. (Regarding the README.txt; I'm in favor of Moshe's suggestion.) -- Dries Buytaert :: http://www.buytaert.net/

2 4

[drupal-devel] [bug] De-selecting all content type options creates in_array() error
by leafish_paul 22 Mar '05

22 Mar '05

Issue status update for http://drupal.org/node/17158 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: samo Updated by: leafish_paul -Status: active +Status: patch Attachment: http://drupal.org/files/issues/node.module_fix_empty_node_options.patch (1.04 KB) I was able to recreate this problem, and it seems that changing that instance of 'edit' to 'node' seems to do the trick. Not sure why tho, could someone check this patch? leafish_paul Previous comments: ------------------------------------------------------------------------ February 10, 2005 - 23:34 : samo Using latest code from CVS; steps to replicate: 1) administer -> content -> configure (tab) -> content types (tab) 2) story -> configure 3) de-select all "Default options": Published, In Moderation Queue, Promoted..., Sticky..., Create new revision 4) Save Configuration 5) create content -> story I receive 4 in_array() errors at lines 1318,1319,1320,1321 of node.module warning: in_array(): Wrong datatype for second argument in modules/node.module on line 1318. Is variable_get() expected to return an array? I added a quick line in node.module to get past the problem for now, but I'm sure it is not the preferred solution: if(!is_array($node_options) ) $node_options = array(); ------------------------------------------------------------------------ February 11, 2005 - 15:09 : samo The use of a default in variable_get() calls seems dangerous when we expect nothing back. Line 1254: variable_get('node_options_'. $edit->type, array('status', 'promote')); What if the variable "node_options_story" is empty? status and promote are applied despite explicitly denying them when configuring content types. ------------------------------------------------------------------------ February 11, 2005 - 15:19 : samo Shouldn't line 1254 of node.module use $node->type instead of $edit->type? ------------------------------------------------------------------------ February 14, 2005 - 17:29 : samo I beg of someone, anyone: is line 1254 of node.module correct? The object $edit is not referenced anywhere in that function. I believe $edit->type should be replaced with $node->type. ------------------------------------------------------------------------ February 19, 2005 - 08:10 : robertDouglass Changing status to critical. I have reproduced this error and am investigating why in node_validate, there is a dead reference to $edit: <?php if (user_access('administer nodes')) { ... } else { // Validate for normal users: $node->uid = $user->uid ? $user->uid : 0; // Force defaults in case people modify the form: // this line can never succeed: $edit is a dead reference. $node_options = variable_get('node_options_'. $edit->type, array('status', 'promote')); $node->status = in_array('status', $node_options); $node->moderate = in_array('moderate', $node_options); $node->promote = in_array('promote', $node_options); $node->sticky = in_array('sticky', $node_options); $node->revision = in_array('revision', $node_options); unset($node->created); } ?> ------------------------------------------------------------------------ February 19, 2005 - 08:30 : robertDouglass should this be $node instead of $edit? $node_options = variable_get('node_options_'. $node->type, array('status', 'promote'));

1 0

[drupal-devel] 20000 users on the website!
by Ross Kendall 22 Mar '05

22 Mar '05

OK, not really a devel issue, but cause for a least a little celebration. 19hours since 20000 drupal.org users

1 0

[drupal-devel] Re: [drupal:dries] /modules system.module
by Stefan Nagtegaal 22 Mar '05

22 Mar '05

Op 21-mrt-05 om 22:25 heeft drupal-devel(a)drupal.org het volgende geschreven: > User: dries Branch: HEAD Date: Mon, 21 Mar 2005 21:25:49 +0000 > > Modified files: > /modules system.module > > Log message: > - Patch #18093 by Junyor: clean up handling of image toolkit code in > absence of > any toolkits. > > Links: > > http://cvs.drupal.org/diff.php?path=drupal/modules/ > system.module&old=1.200&new=1.201 This is not uniform/consistent to the other code we currently have. Currently drupal just disables the options or doesn't display them at all. Which is - after a lot of patches - finally consistent.. Now, we are introducing something new again.. Can't we make this either consistent with the rest of drupal? Just don't display anything at all and put an message in the watchdog (WATCHDOG_NOTICE).. See also my patch for the image.inc here: http://drupal.org/node/18700. (Walkah: What's the status of your patch build on this one? Dries, when does this get comitted?) Stefan

2 4

[drupal-devel] please lock user
by Steven Peck 22 Mar '05

22 Mar '05

Greetings, I have now deleted two posts from this user http://drupal.org/user/20035 That were pure spam links. Please lock the account -sp

2 1

[drupal-devel] [bug] Image handling block on settings page provides no information if no toolkits are installed
by TDobes 22 Mar '05

22 Mar '05

Issue status update for http://drupal.org/node/18093 Project: Drupal Version: cvs Component: system.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Mad Maks Updated by: TDobes Status: patch I was under the same impression as Junyor that toolkits were supposted to have a settings hook such that there might be a unified place for configuration. (i.e. location of binaries if one is using imagemagick) Perhaps walkah (who wrote the image.inc code IIRC) could clarify on this? It looks like the problem was introduced by this patch [1], which is where the idea seems to have originated that the settings hook might be used to determine whether a toolkit exists or not. My guess is that we need to remove the "return true" from image_gd_settings and instead return a message like "You are using the GD toolkit, which has no configurable settings." or something along those lines. This would avoid breaking the check for toolkit existance based on the settings hook while fixing the problems it caused. See also: Stefan's UI consistency comments [2] [1] http://drupal.org/node/17477 [2] http://lists.drupal.org/archives/drupal-devel/2005-03/msg00915.html TDobes Previous comments: ------------------------------------------------------------------------ February 28, 2005 - 03:28 : Mad Maks i have installed the cvs version yesterday (upgrade from 4.5.2) and now i see at administration => settings a block with the titel image handeling. But in that block there is nothing except a "1" . Is this a now bug or did i do something wrong? greetings MM ------------------------------------------------------------------------ March 1, 2005 - 02:24 : Mad Maks nobody? ------------------------------------------------------------------------ March 9, 2005 - 04:41 : Mad Maks BrianH has posted a screenshot in http://drupal.org/node/18588 ------------------------------------------------------------------------ March 19, 2005 - 14:25 : Junyor Attachment: http://drupal.org/files/issues/system_5.patch (976 bytes) I think the problem is that no image toolkits are installed at your host. Here's a patch that should clean up things a bit by adding information if no toolkits are available. ------------------------------------------------------------------------ March 20, 2005 - 03:18 : Mad Maks thanks ------------------------------------------------------------------------ March 21, 2005 - 15:26 : Dries Committed to HEAD. ------------------------------------------------------------------------ March 21, 2005 - 22:29 : TDobes Forgive me if this is totally incorrect, but... A cursory glance at this patch seems to indicate that it's not the correct fix. The image_toolkit_invoke('settings') only gets called if there is more than one toolkit. What if there's only one toolkit installed and it has settings available? Also, the else clause is encountered if the number of toolkits is not greater than one (in other words: less than two). The else clause tells the user that there are NO toolkits. Isn't this message inaccurate if there's only one toolkit? For that matter, won't there always be at least one toolkit because we bundle one in image.inc? If we've decided that there will never be any settings from the core toolkit, perhaps we should just change the text to read "There are no extra toolkits installed, so image manipulation will be done using gd2." or something like that. From a user's perspective, the "no toolkits" message would be interpreted as "you can't manipulate images", which is not the case. Feel free to correct me if I'm wrong here... I haven't yet thoroughally looked over the image handling code. ------------------------------------------------------------------------ March 22, 2005 - 01:49 : Junyor @TDobes: You're correct, it's the wrong fix. I'm looking into it again now. ------------------------------------------------------------------------ March 22, 2005 - 02:07 : Junyor Attachment: http://drupal.org/files/issues/junyor.system.patch (927 bytes) OK, the problem seems to be that image_gd_settings() returns TRUE. So, if there's only one toolkit installed, you'll just see "1" in the image handling section on the settings page. I had thought that "image_toolkit_invoke('settings')" was supposed to show settings for an image toolkit, not verify that the toolkit is installed. Here's a new patch that corrects the problem in the first patch. If only one toolkit is installed and working, it prints a message saying the toolkit is ready for use. If no toolkits exist, the same message as in the previous patch is printed. If no message should be printed if no settings are available (only one toolkit is installed or no toolkits are installed), I can roll another patch.

1 0

[drupal-devel] [bug] Image handling block on settings page provides no information if no toolkits are installed
by Junyor 22 Mar '05

22 Mar '05

Issue status update for http://drupal.org/node/18093 Project: Drupal Version: cvs Component: system.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Mad Maks Updated by: Junyor -Status: active +Status: patch Attachment: http://drupal.org/files/issues/junyor.system.patch (927 bytes) OK, the problem seems to be that image_gd_settings() returns TRUE. So, if there's only one toolkit installed, you'll just see "1" in the image handling section on the settings page. I had thought that "image_toolkit_invoke('settings')" was supposed to show settings for an image toolkit, not verify that the toolkit is installed. Here's a new patch that corrects the problem in the first patch. If only one toolkit is installed and working, it prints a message saying the toolkit is ready for use. If no toolkits exist, the same message as in the previous patch is printed. If no message should be printed if no settings are available (only one toolkit is installed or no toolkits are installed), I can roll another patch. Junyor Previous comments: ------------------------------------------------------------------------ February 28, 2005 - 10:28 : Mad Maks i have installed the cvs version yesterday (upgrade from 4.5.2) and now i see at administration => settings a block with the titel image handeling. But in that block there is nothing except a "1" . Is this a now bug or did i do something wrong? greetings MM ------------------------------------------------------------------------ March 1, 2005 - 09:24 : Mad Maks nobody? ------------------------------------------------------------------------ March 9, 2005 - 11:41 : Mad Maks BrianH has posted a screenshot in http://drupal.org/node/18588 ------------------------------------------------------------------------ March 19, 2005 - 21:25 : Junyor Attachment: http://drupal.org/files/issues/system_5.patch (976 bytes) I think the problem is that no image toolkits are installed at your host. Here's a patch that should clean up things a bit by adding information if no toolkits are available. ------------------------------------------------------------------------ March 20, 2005 - 10:18 : Mad Maks thanks ------------------------------------------------------------------------ March 21, 2005 - 22:26 : Dries Committed to HEAD. ------------------------------------------------------------------------ March 22, 2005 - 05:29 : TDobes Forgive me if this is totally incorrect, but... A cursory glance at this patch seems to indicate that it's not the correct fix. The image_toolkit_invoke('settings') only gets called if there is more than one toolkit. What if there's only one toolkit installed and it has settings available? Also, the else clause is encountered if the number of toolkits is not greater than one (in other words: less than two). The else clause tells the user that there are NO toolkits. Isn't this message inaccurate if there's only one toolkit? For that matter, won't there always be at least one toolkit because we bundle one in image.inc? If we've decided that there will never be any settings from the core toolkit, perhaps we should just change the text to read "There are no extra toolkits installed, so image manipulation will be done using gd2." or something like that. From a user's perspective, the "no toolkits" message would be interpreted as "you can't manipulate images", which is not the case. Feel free to correct me if I'm wrong here... I haven't yet thoroughally looked over the image handling code. ------------------------------------------------------------------------ March 22, 2005 - 08:49 : Junyor @TDobes: You're correct, it's the wrong fix. I'm looking into it again now.

1 0

[drupal-devel] Plone: tabs as actions
by Dries Buytaert 21 Mar '05

21 Mar '05

In plone, 'actions' are presented using green tabs, while navigation is presented using 'blue tabs'. Read http://www.zopemag.com/Issue006/Section_Articles/ article_IntroToArchteypes.html for some insight and screenshots. Not sure it could solve our 'tabs as actions' problem but I figured I'd pass it along. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] Still trying to find getting Current, Clear and Complete information about on going projects
by Carl McDade 21 Mar '05

21 Mar '05

Is there anyway of getting Current, Clear and Complete information about on going module projects. Frequently people are told that their ideas conflict with another project. Currently there is no way to search for something like this and the projects area has a list of old, incomplete and without description projects many of which have already become part of Drupal as core or as a regularly maintained contribution. It looks a bit like a mini sourceforge. The cvs is not really a lot of help in this either. Does someone have this written on a paper napkin somewhere? Can I get a copy? Carl McDade Update: Just spent a week in the sandbox and haven't got a clue as to what is what. Anyone?

2 1

[drupal-devel] [bug] common.inc unused parameters, unitialized vars
by chx 21 Mar '05

21 Mar '05

Issue status update for http://drupal.org/node/19212 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/common_inc_parameter.patch (1.71 KB) As discussed at http://lists.drupal.org/archives/drupal-devel/2005-03/msg00003.html chx

1 0