March 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Usability improvement to forum module
by nysus 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/18795 Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/forum_patch.patch (412 bytes) Here's another usability improvement to the forum. Rather than return no table when no containers or forums exist, a message is displayed inside the table telling the user that no containers or forums exist and how to create a new one. nysus

4 8

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by Junyor 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: Junyor Status: fixed The same solution will probably work there. Junyor Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 00:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 15:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 02:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 06:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 09:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 13:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian err. and it's a patch. ------------------------------------------------------------------------ March 27, 2005 - 14:37 : adrian Attachment: http://drupal.org/files/issues/safari_float_render_0.diff (1.29 KB) I'm using the coffee defense as to why I missed the . infront of the .clear class ------------------------------------------------------------------------ March 27, 2005 - 14:45 : adrinux I can't see any other way to fix that, adding an ID and setting height on the fieldset would be just as ugly imo - maybe re-engineering the whole form would work but this isn't really the time to do that! Steven will moan at you for using a br probably :) ------------------------------------------------------------------------ March 27, 2005 - 16:54 : Steven The original commit referenced above did not fix the problem completely, it did make the node admin at least usable in Safari. Before, the form items would overlap eachother. Adrian's fix seems to work, and the br is sort of excusable in this case, as the browser's behaviour is quite broken with regard to fieldsets. Usually I use to avoid nasty br issues in IE, but there don't seem to be any in this case. could be considered a CSS version of which is transitional XHTML. Commited to head. ------------------------------------------------------------------------ March 27, 2005 - 19:26 : Junyor Looks good in Opera and Safari now, thanks. The behavior of floats inside fieldsets is undefined in CSS, so it's not really that they're broken. They're just different. :) ------------------------------------------------------------------------ March 27, 2005 - 22:29 : moshe weitzman Perhaps this is a good spot to mention that the author and timestamp fields are broken on the node edit form in Safari. They have been busted for a long time. The browser won't even click into those fields, so they can't be changed. Perhaps the fix there is similar to the fix submitted in this issue.

1 0

[drupal-devel] [feature] Link to node on comment edit page
by Steven 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/11782 Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kps Updated by: Steven Status: patch Perhaps this should be fixed through a breadcrumb instead? Steven Previous comments: ------------------------------------------------------------------------ October 20, 2004 - 16:31 : kps Attachment: http://drupal.org/files/issues/comment.module.patch (579 bytes) We have had users manage to post their comments on the wrong nodes, and when reviewing a newly submitted comment via admin/comment/list/approval, there seems to be no practical way to tell which node the comment belongs to. The attached patch adds a link to the node on the comment edit page. ------------------------------------------------------------------------ March 13, 2005 - 20:06 : killes(a)www.drop.org The patch is in html. ------------------------------------------------------------------------ March 26, 2005 - 19:15 : kps Attachment: http://drupal.org/files/issues/comment-admin-show-node.patch (579 bytes) Interesting! The patch wasn't in HTML when I uploaded it, and the stated size (579 bytes) matches the size of the plain text file, not the size of the HTML. I'll try again....

1 0

[drupal-devel] [bug] typo: "page not found" watchdog active class not properly colored
by TDobes 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19533 Project: Drupal Version: cvs Component: other Category: bug reports Priority: normal Assigned to: TDobes Reported by: TDobes Updated by: TDobes Status: patch Attachment: http://drupal.org/files/issues/watchdog_coloring_typo.patch (578 bytes) Due to a typo in drupal.css, the active column is not properly colored for "page not found" messages in the watchdog. Very, very small patch attached. TDobes

2 1

[drupal-devel] [bug] Disappearing 'submit' button on node/add pages
by jjeff 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19353 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: jjeff Updated by: jjeff Status: active With 'preview post' set to 'optional' (in admin/node/configure), the node/add pages show a both 'preview' and 'submit' buttons at the bottom of the page (the correct behavior). But if your submitted page has an error (if for instance you forgot to add a Title), the 'submit' button goes away leaving only the 'preview' button. The submit button seems to get clobbered whenever the drupal_set_message() is called, but there may be more to it than this. jjeff

8 10

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by moshe weitzman 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: moshe weitzman Status: fixed Perhaps this is a good spot to mention that the author and timestamp fields are broken on the node edit form in Safari. They have been busted for a long time. The browser won't even click into those fields, so they can't be changed. Perhaps the fix there is similar to the fix submitted in this issue. moshe weitzman Previous comments: ------------------------------------------------------------------------ February 14, 2005 - 18:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 09:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 24, 2005 - 20:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 00:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 03:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 07:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 07:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. ------------------------------------------------------------------------ March 27, 2005 - 07:58 : adrian err. and it's a patch. ------------------------------------------------------------------------ March 27, 2005 - 08:37 : adrian Attachment: http://drupal.org/files/issues/safari_float_render_0.diff (1.29 KB) I'm using the coffee defense as to why I missed the . infront of the .clear class ------------------------------------------------------------------------ March 27, 2005 - 08:45 : adrinux I can't see any other way to fix that, adding an ID and setting height on the fieldset would be just as ugly imo - maybe re-engineering the whole form would work but this isn't really the time to do that! Steven will moan at you for using a br probably :) ------------------------------------------------------------------------ March 27, 2005 - 10:54 : Steven The original commit referenced above did not fix the problem completely, it did make the node admin at least usable in Safari. Before, the form items would overlap eachother. Adrian's fix seems to work, and the br is sort of excusable in this case, as the browser's behaviour is quite broken with regard to fieldsets. Usually I use to avoid nasty br issues in IE, but there don't seem to be any in this case. could be considered a CSS version of which is transitional XHTML. Commited to head. ------------------------------------------------------------------------ March 27, 2005 - 13:26 : Junyor Looks good in Opera and Safari now, thanks. The behavior of floats inside fieldsets is undefined in CSS, so it's not really that they're broken. They're just different. :)

1 0

[drupal-devel] [bug] No q=poll breadcrumb; link to q=poll breadcrumb only present if block enabled
by ankur 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19485 Project: Drupal Version: cvs Component: poll.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: ankur Updated by: ankur Status: active I was looking at a bug report submitted on civicspacelabs.org (http://civicspacelabs.org/home/node/7185) The issue was about there being no breadcrumbs (there should be one: "Home") when you go to q=poll. I was looking through the code and noticed that there is no obvious way to get to q=poll unless the poll block is enabled. I was thinking both problems could be solved by changing poll_menu() so that it changes the path for q=poll to q=admin/poll....? Of course, I know that perms for q=admin/poll would then have to fall under the 'create polls' permission, which would then make it useless for the 'older polls' link in the polls block, but I'm thinking there's no harm done in making this a seperate menu item in poll_menu. If this is something that you think deserves a patch, I'm willing to submit one... -Ankur ankur

3 3

[drupal-devel] [feature] xtemplate: tags for {secondary_links} and {primary_links}
by rupi 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19552 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: rupi Updated by: rupi Status: active wouldn't it be handy to have BEGIN/END-tags for {secondary_links} and {primary_links} in the xtemplate-syntax? i'm working on a minimalist template and i'd like to wrap primary- and secondary-links in some div-tags so i can apply a style to it. the problem is, when i switch off the links in themes -> configure -> toggle display i still have the (now empty) div-tags in the page's sourcecode. this doesn't affect the rendering of the page (at least with firefox) however i think it's unnecessary and i'm not to sure, wheter this would cause displayproblems with ms internet explorer. and after all, isn't it unvalid xhtml to include empty tags? (also not sure about that...) rupi

1 0

[drupal-devel] [bug] Clean URL test fails if Drupal install uses HTTP auth
by Junyor 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19181 Project: Drupal Version: cvs Component: system.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Junyor Updated by: Junyor -Status: active +Status: duplicate Duplicate of http://drupal.org/node/19515. Junyor Previous comments: ------------------------------------------------------------------------ March 20, 2005 - 16:08 : Junyor The new clean URL test[1] in 4.6 causes problems for sites using HTTP auth. The call to /system/test through drupal_http_request() fails because the username/password is unknown to Drupal. Moshe proposed the following: " we could resolve this by having the user's browser do the check instead of the server. basically, use an tag to do the test and instead of just returning 200 in the response, the server sets a variable indicating that clean url is OK. so on the first view of admin/settings, everyone sees disabled ... this is just one of many possible solutions. " [1] http://drupal.org/node/12384 ------------------------------------------------------------------------ March 20, 2005 - 16:36 : Junyor I just looked around a little bit to see if there's some way we could just set a variable via the .htaccess file if mod_rewrite is enabled and check that, but I didn't see any way to do that. I suppose Moshe's solution would work, but we'd need to put a note in the settings page to reload it if you want to toggle Clean URL support. ------------------------------------------------------------------------ March 21, 2005 - 03:55 : Anonymous See also: another issue of users having problems with the clean URL check [1] [1] http://drupal.org/node/16309 ------------------------------------------------------------------------ March 21, 2005 - 03:59 : Steven HTTP auth returns a 401 status code right? We can easily check for that, but I wonder if it will still return 404s for non-existant files. ------------------------------------------------------------------------ March 21, 2005 - 10:21 : Junyor Yes, I believe HTTP auth returns a 401. But it returns a 401 even if the file doesn't exist if you're not authenticated. Could we do a check for a 401 and if that's the return value, give the user a chance to manually test? Alternatively, we could just say the test could not be performed and leave the radio buttons enabled.

1 0

[drupal-devel] drupal talk spam
by Gabor Hojtsy 27 Mar '05

27 Mar '05

Hi, I don't know if you noticed, but a particular hosting company spams the drupal talk feed regulary with some offers... Something should be done about it... Install spam.module on drupal.org? http://drupal.org/aggregator/categories/1 Goba

2 1