March 2005 - Development - lists.drupal.org

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by Goba 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: Goba Status: active So then a container div might be a working solution. Goba 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.

1 0

[drupal-devel] [bug] Search: no results when term begins with space
by TDobes 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/6763 Project: Drupal Version: cvs Component: search.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: mikis Updated by: TDobes -Status: active +Status: fixed I cannot reproduce this problem with the 4.6 search.module. I get the same search results regardless of how many spaces I prefix/postfix onto search terms. TDobes Previous comments: ------------------------------------------------------------------------ March 28, 2004 - 13:46 : mikis I'm using Drupal 4.4.0-RC, and I saw this in the log file: when user enters search term with space in front, ie. ' something', search returns 0 results (even if there are more results for term 'something'). One trim()/ltrim() in search module should fix this. Also, equal sign (=) should be added to "Remove punctuation and stuff" list, to be stripped from words to be indexed; right now I have keywords like '==================' in database. ------------------------------------------------------------------------ October 9, 2004 - 01:30 : erikhopp it seems that one space plus search term yields results, but not two or more spaces. is there some way to strip all spaces at the begining of a search?

1 0

[drupal-devel] [support] Unusual watchdog error for Search module
by TDobes 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/15887 Project: Drupal Version: cvs Component: search.module -Category: bug reports +Category: support requests Priority: normal Assigned to: Anonymous Reported by: teradome Updated by: TDobes Status: active This sounds like an old 4.5.x-era module that is improperly implementing the _search hook. (It hasn't been fully updated for 4.6 yet.) Can you verify this error without any contrib modules installed? If not, what contrib modules are you using? TDobes Previous comments: ------------------------------------------------------------------------ January 19, 2005 - 23:34 : teradome This is the error that I get: Missing argument 2 for do_search() in /home/virtual/site440/fst/var/www/html/modules/search.module on line 444. Problem is it happens on a number of different URLs, at unpredictable times.

1 0

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by Junyor 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: Junyor Status: active 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. 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.

1 0

[drupal-devel] [feature] Blog.module as container system
by Bèr Kessels 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19394 Project: Drupal Version: cvs Component: blog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: active Attachment: http://drupal.org/files/issues/blog_7.patch (14.15 KB) I rewrote blog.module to become a container, something like book outlines. In these files, there no longer is a blog type node. With a checkbox (see screenshot) users with the correct permissions can add any node to their blog. Feel free to try, also feel free to improve these files, just mail me if you commit changes. Please see my sandbox for a complete module and its files: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/ber/blog/ Bèr Kessels

4 8

[drupal-devel] [bug] Do not execute functions in include files
by adrian 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/18213 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: killes(a)www.drop.org Updated by: adrian Status: active It's definately not a simple problem. For instance.. the db connection needs to be started during bootstrap, and during normal execution. I think the better idea is to include a DRUPAL_INIT constant we can check before executing the function. (or a DRUPAL_NO_INIT .. i'm not picky). adrian Previous comments: ------------------------------------------------------------------------ March 2, 2005 - 00:09 : killes(a)www.drop.org Drupal currently executes functions in include files. This is very annoying if you want to include files from external scripts such as update scripts or other scripts that want to use Drupal as a framework. Offending files are: database.inc: db_set_active(); session.inc: session_set_save_handler("sess_open", "sess_close", "sess_read", "sess_write", "sess_destroy", "sess_gc"); session_start(); common.inc: A bunch of stuff at the bottom. All this should be moved into a start.inc file. ------------------------------------------------------------------------ March 27, 2005 - 08:44 : adrian I haven't done this recently, but back in 4.4 era I attempted something similar to this for the install api. A _lot_ of modifications were required to be able to use (for instance) the theme api without needing to have a database connection active.

1 0

[drupal-devel] [bug] Do not execute functions in include files
by adrian 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/18213 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: killes(a)www.drop.org Updated by: adrian Status: active I haven't done this recently, but back in 4.4 era I attempted something similar to this for the install api. A _lot_ of modifications were required to be able to use (for instance) the theme api without needing to have a database connection active. adrian Previous comments: ------------------------------------------------------------------------ March 2, 2005 - 00:09 : killes(a)www.drop.org Drupal currently executes functions in include files. This is very annoying if you want to include files from external scripts such as update scripts or other scripts that want to use Drupal as a framework. Offending files are: database.inc: db_set_active(); session.inc: session_set_save_handler("sess_open", "sess_close", "sess_read", "sess_write", "sess_destroy", "sess_gc"); session_start(); common.inc: A bunch of stuff at the bottom. All this should be moved into a start.inc file.

1 0

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

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal -Version: <none> +Version: cvs Component: node.module Category: bug reports -Priority: normal +Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: adrian -Status: closed +Status: active 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. adrian Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 01: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 - 16:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 03:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633

1 0

[drupal-devel] [feature] Strip site directory from the theme list.
by adrian 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19524 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: minor Assigned to: adrian Reported by: adrian Updated by: adrian Status: active Attachment: http://drupal.org/files/issues/strip-site-dir.patch (1.2 KB) When installing themes in the user's site directory, the full path to the theme is displayed as the description, including the site directory (ie: site/www.mysite.com/themes/mytheme/mystyle) While this is technically correct, it does serve to create a lot of clutter, and exposes the underlying structure of the site more than the site maintainer might feel comfortable. Attached is a simple patch to strip out the site directory on display. I admit this patch makes more sense in a mass hosting system like bryght, where the directory structure is irrelevant to the site.. but I just thought I'd roll it and see what you guys think. adrian

1 0

[drupal-devel] ecommerce question.
by Gordon Heydon 27 Mar '05

27 Mar '05

Hello, I am currently developing a event product for a client. The problem is that when creating the product, the second page after you select the type of product I am trying wanting to refresh this page. What I am trying to do is that I have a couple of recurring fields, class, category, and sub category that needs to be selected by the user when they enter into the event. So I have a couple of fields blank fields that they can type data into, and then when they run out I can just click the add more button which will post the current data, and then redisplay the field with more additional fields. I can do this once the product has been created, as it is handled by the standard node form routines, but I am having problems working out how to do this on the second page of the wizard select. Any ideas would be most appreciated. -- Gordon Heydon <gordon(a)heydon.com.au>

1 0