March 2005 - Development - lists.drupal.org

[drupal-devel] [bug] search.module doesn't search non-english words without mbstring php-module
by edhel 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/19575 Project: Drupal Version: 4.5.2 Component: search.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: edhel Updated by: edhel Status: active Search in Drupal work with national non-english words only with such conditions: 1) php-module mbstring is switched on 2) php configured with mbstring.func_overload = 7 (or at least 2) 3) php configured with mbstring.internal_encoding "UTF-8" Cause: in search.module there is used strtolower() which incorrectly work UTF-8 (without configured mbstring). Options 2-3 can be configured in .htaccess. Also these options can be replaced by other solution: replacing of all strtolower() to mb_strtolower() in search.module file. This "feature" is also present in 4.6 RC1. IMHO it must be fixed in some way or DOCUMENTED IN INSTALL.TXT AND IN HANDBOOK (in "installation" section). Notice: with 2-3 options there will be happen some warnings in Drupal: 1) in includes/menu.inc:910 (see: http://drupal.org/node/11758) 2) in modules/user.module:214. For correct work I replaced: <?php if (ereg("[^\x80-\xF7 [:alnum:]@_.-]", $name)) return t('The username contains an illegal character.'); ?> by code: <?php if (ereg("[^\\x80-\\xF7 [:alnum:]@_.-]", $name)) return t('The username contains an illegal character.'); ?> edhel

2 2

[drupal-devel] [bug] Clash with mbstring extension
by Steven 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/11758 Project: Drupal Version: 4.5.0 Component: menu system Category: bug reports Priority: minor Assigned to: Anonymous Reported by: Anonymous Updated by: Steven Status: active This won't be fixed unless there is a clear description of the problem and its solution, which complies with the Drupal coding standards. Steven Previous comments: ------------------------------------------------------------------------ October 20, 2004 - 08:05 : Anonymous I guess this is very minor stuff, but anyway... If the mbstring extension is loaded, the call to strrpos() in [...]/includes/menu.inc on line 910 will give a /warning: mb_strrpos(): Empty haystack in [...]\includes\menu.inc on line 910/. This will output sometimes (e.g. when saving the theme selection in the admin area) before headers are sent producing thus additional errors. On other occurrences it will simply appear at the top of the page. The problem is easily solved by not using the mbstring extension in PHP, which anyway is not set by default. Tried on Windows XP + Apache 2.0.49 + PHP 4.3.2 + Drupal 4.5.0 ------------------------------------------------------------------------ October 20, 2004 - 18:52 : vitamin That's because mbstring doesn't like empty arguments. The fix is described here (in russian), thanks to Basielienis: http://drupal.ru/node/view/310 Shortly, you should search in menu.inc (line 910 in 4.5.0) and replace line $parent = substr($parent, 0, strrpos($parent, '/')); with if ($parent) $_lenght = strrpos($parent, "/"); $parent = substr($parent, 0, $_lenght); ps: Can anybody commit this in HEAD? ------------------------------------------------------------------------ October 20, 2004 - 20:56 : Uwe Hermann This looks a bit strange to me (I haven't tested it though). Isn't $_length uninitialized if $parent is non-empty?Is that desired? If yes, though it may work, it's not a very obvious or clean solution, IMHO. ------------------------------------------------------------------------ October 29, 2004 - 08:38 : Anonymous I had this same issue. The solution for me was to revert back to default values on a setting I had changed in my /etc/php.ini. My php.ini included *mbstring.func_overload = 7* after resetting it back to the default value *mbstring.func_overload = 0* drupal as once again happy. I had set that value to 7 at the suggestion of eGroupWare, to allow support for utf extended characters (if I understood it correctly). Hope that helps-- rob(a)shrouded.net ------------------------------------------------------------------------ October 31, 2004 - 18:22 : vitamin Yes, but disabling function overload you disable using unicode aware string functions in php. As a result, you loose case insensetive searching in languages other than English. AFAIR, drupal doesn't use mbstring extension directly, so the only way for non-english speaking people to use full functional searching is to enable function overloading, so strrpos() is automagically replaced with mb_strrpos(), ereg() with mb_ereg() etc. I hope that one day somebody of developers will fix this annoying bug..

1 0

[drupal-devel] Fwd: Mailman-dev (was Re: Creating discussion lists from within CS)
by Dries Buytaert 28 Mar '05

28 Mar '05

Might be of interest! Begin forwarded message: > From: Gavin White <gavin.white(a)alumni.reed.edu> > Date: Mon 28 Mar 2005 07:46:18 CEST > To: civicspace-community(a)civicspacelabs.org > Subject: Mailman-dev (was Re: Creating discussion lists from within CS) > > > There's a great set of recommendations on the mailman-developers list > regarding how to integrate their software with an external CMS, > archiving system, and user-info database. It is located at > http://www.mail-archive.com/mailman-developers@python.org/ > msg06174.html > > Basically, Chuck Von Respach lays out what he says is a > five-minutes-to-implement approach to integrating mailman with > external data sources. I'm sure it would take longer to make it work > super-well with a spiffy admin interface, but that's the nature of > code. > -- > Gavin.White(a)alumni.reed.edu > www.wandreilagh.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > civicspace-community-unsubscribe(a)civicspacelabs.org > For additional commands, e-mail: > civicspace-community-help(a)civicspacelabs.org > > -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [task] drupal_specialchars() can now use UTF-8
by Uwe Hermann 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/19591 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Anonymous Reported by: Uwe Hermann Updated by: Uwe Hermann Status: active >From includes/common.inc (Drupal 4.6/CVS): /** * Encode special characters in a string for display as HTML. * * Note that we'd like to use htmlspecialchars($input, $quotes, 'utf-8') * as outlined in the PHP manual, but we can't because there's a bug in * PHP < 4.3 that makes it mess up multibyte charsets if we specify the * charset. This will be changed later once we make PHP 4.3 a requirement. */ function drupal_specialchars($input, $quotes = ENT_NOQUOTES) { return htmlspecialchars($input, $quotes); } As we now require at least PHP >= 4.3.3 (see INSTALL.txt) this can now be tackled, I guess. Uwe Hermann

2 1

[drupal-devel] [bug] form_checkboxes saves "no selection" as string
by chx 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/18663 Project: Drupal Version: cvs Component: base system Category: bug reports -Priority: critical +Priority: normal -Assigned to: chx +Assigned to: Anonymous Reported by: killes(a)www.drop.org Updated by: chx -Status: patch +Status: active Attachment: http://drupal.org/files/issues/checkboxes_0.patch (1.71 KB) Oh NO! One strayed space! I fixed it before steven beheads me.... chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 02:51 : killes(a)www.drop.org If you select nothing from a set of checkboxes an empty string is save to the variables table. This is a problem if the calling code assumes, it would get an array. We should make it save an empty array. The problem is the form_hidden field that we add. even if we replace form_hidden($name, 0) by form_hidden($name, array()) it isn't going to work, because the empty array is eaten by htmlspecialchars. redLED found this bug and he does not like it: 02:53 < redLED> i just like things saying 'CRITICAL' in red 02:53 < redLED> it gives this warm impending doom feeling 02:53 < redLED> and is generally associated with nuclear reactors in people's subconsciousness Suggestions welcome. ------------------------------------------------------------------------ March 12, 2005 - 19:47 : Steven There is no way to fix it in form_checkboxes() itself afaik, because even without htmlspecialchars, it would still come out as "Array". You can only create arrays indirectly through form submissions, by naming your values "foo[]". But you can not create empty arrays this way. So it is really up to the module which uses form_checkboxes() to handle this. A simple is_array() should do the trick. ------------------------------------------------------------------------ March 28, 2005 - 17:27 : chx Attachment: http://drupal.org/files/issues/checkboxes.patch (1.71 KB) system_settings_save can not really cope with this situation. This makes a problem with empty node options. And the fact that we have a check everywhere we use form_checkboxes is error prone, too. Here is a patch. If this accepted I'll comb the core for dead code. For eg. the first three lines of taxonomy_save_vocabulary and so.

1 0

[drupal-devel] [bug] form_checkboxes saves "no selection" as string
by chx 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/18663 Project: Drupal Version: cvs Component: base system Category: bug reports -Priority: normal +Priority: critical -Assigned to: Anonymous +Assigned to: chx Reported by: killes(a)www.drop.org Updated by: chx -Status: active +Status: patch Attachment: http://drupal.org/files/issues/checkboxes.patch (1.71 KB) system_settings_save can not really cope with this situation. This makes a problem with empty node options. And the fact that we have a check everywhere we use form_checkboxes is error prone, too. Here is a patch. If this accepted I'll comb the core for dead code. For eg. the first three lines of taxonomy_save_vocabulary and so. chx Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 02:51 : killes(a)www.drop.org If you select nothing from a set of checkboxes an empty string is save to the variables table. This is a problem if the calling code assumes, it would get an array. We should make it save an empty array. The problem is the form_hidden field that we add. even if we replace form_hidden($name, 0) by form_hidden($name, array()) it isn't going to work, because the empty array is eaten by htmlspecialchars. redLED found this bug and he does not like it: 02:53 < redLED> i just like things saying 'CRITICAL' in red 02:53 < redLED> it gives this warm impending doom feeling 02:53 < redLED> and is generally associated with nuclear reactors in people's subconsciousness Suggestions welcome. ------------------------------------------------------------------------ March 12, 2005 - 19:47 : Steven There is no way to fix it in form_checkboxes() itself afaik, because even without htmlspecialchars, it would still come out as "Array". You can only create arrays indirectly through form submissions, by naming your values "foo[]". But you can not create empty arrays this way. So it is really up to the module which uses form_checkboxes() to handle this. A simple is_array() should do the trick.

1 0

[drupal-devel] [bug] table and db prefix problems in 4.6RC
by chueewowee 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/19595 Project: Drupal Version: 4.5.2 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: chueewowee Updated by: chueewowee Status: active Below follows the PHP error message: Message Table 'dr_drupal.dr_dr_term_data' doesn't exist query: SELECT * FROM dr_dr_term_data WHERE tid = "13" in /Volumes/Files/Users/chuee/Sites/drupal/includes/database.mysql.inc on line 66. Severity error My tables are prefixed with 'dr_' The value $db_prefix = 'dr_'; has been inserted into settings.php An example of the actual tables from the database.mysql can be seen to be: -- Table structure for table 'term_hierarchy' create table dr_term_hierarchy ( tid int(10) unsigned NOT NULL default '0', parent int(10) unsigned NOT NULL default '0', KEY tid (tid), KEY parent (parent) ) TYPE=MyISAM; When checking all tables in through the dba.module, similar errors are given for non-core modules such as store.module. So the arror applies accross the board. The behaviour when creating content is like this: A post is accepted for publication according to inspection of the content list, and as according the log, eg.: page: added test conspiracy content. Severity notice Hostname 127.0.0.1), . However when clicking on a category term to view publications in the category browser, a blank pageis returned. When a category has no posts a normal page with message is displayed: 'There are currently no posts in this category.' John Plum chueewowee

1 2

[drupal-devel] [bug] Konqueror 3.3.x problems with forms input inside fieldset tags
by frjo 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/16729 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: syscrusher Updated by: frjo Status: active I had the same problem as syscrusher when I tried to add a new project with Safari (v125.12). It was not possible to enter anything to the field "CVS directory". With Mozilla it worked OK. frjo Previous comments: ------------------------------------------------------------------------ February 4, 2005 - 06:33 : syscrusher Certain versions of the Konqueror browser have a serious problem with form input in Drupal 4.4.x and 4.5.x. The symptoms are that keyboard and mouse input is completely ignored in the affected "text" and "textarea" fields. The symptoms only occur on textual fields that occur within a <fieldset>...</fieldset> tag set. This occurs, for example, when the form_group() API function is invoked. I have tested several variants on the fieldset attributes, and as far as I can tell it doesn't matter what attributes are applied. I also tried it with a manually-created <fieldset><input type="text" ... /></fieldset> sequence, to eliminate the subtags such as legend, description, and title. The problem occurs even with a bare fieldset, and immediately goes away when the form elements are used without being in a fieldset. I further tested to ensure that the <table> tag was not involved, because a Google search suggested that there were problems with tables and fieldsets in Konqueror. Again, the problem is duplicable with no table in the fieldset. It took a lot of digging, but I have finally traced the problem to the file misc/drupal.css. Specifically, the following clause appears to be at fault: .node-form fieldset { display: inline; } If I comment out the "display: inline;" attribute, then the fields work correctly. There does not appear to be any ill effect from this so far, but I haven't tested extensively nor have I tested to see if this patch breaks any other browsers. I can duplicate this problem across several patch levels of Konqueror 3.3.0, and across Drupal 4.5.0 through 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 07:14 : syscrusher I've verified that the patch doesn't break Firefox 1.0, and also that it /does/ fix the problem with Konqueror 3.3.0 in Drupal 4.4, on one of my production sites. Incidentally, the problem doesn't occur with older Konqueror versions, as far as I can tell. ------------------------------------------------------------------------ March 26, 2005 - 20:15 : Steven I believe that piece of CSS is there for IE5, but I can't remember if it was for Windows or Mac. I'll do some testing later. ------------------------------------------------------------------------ March 26, 2005 - 21:00 : Junyor Works fine in Safari and Opera with or without that rule. IE 5 seems to have the same problem with or without it. In 4.5.2, the fieldsets aren't displayed at all. In HEAD, they cross the screen, pushing everything else down. In other words, it doesn't seem to have any bad effects on Mac browsers with or without that rule. ------------------------------------------------------------------------ March 26, 2005 - 21:09 : syscrusher BTW, I can also duplicate this bug with the CVS version of Drupal 4.6 as of 2005-03-24. ------------------------------------------------------------------------ March 27, 2005 - 13:28 : stefan nagtegaal I can verify that this works flawlesly with drupal 4.6 and any Mac browser.. It would be nice if this would be applied.. ------------------------------------------------------------------------ March 28, 2005 - 05:06 : syscrusher The bug also bit me on the drupal.org site. I finished a new module and tried to create a project to announce it, but one of the required fields in the node/add/... page for Project has the CSS bug. I had to switch to Firefox in order to create the project, because I couldn't enter the data from Konqueror.

1 0

[drupal-devel] [bug] Browse archives block & dates
by mcd 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/17046 Project: Drupal Version: 4.5.2 Component: archive.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: grantbow(a)civicspacelabs.org Updated by: mcd Status: active I'm having the same problem. mcd Previous comments: ------------------------------------------------------------------------ February 8, 2005 - 21:20 : grantbow(a)civicspacelabs.org On my site I can view archive/2005/01/22 from the "22" link in the Browse archives block. Yet the entry displays it's date as Sun, 2005-01-23 01:22. I have a feeling this is due to some missing time zone information somewhere but I don't understand the code well enough to tell for sure.

1 0

[drupal-devel] [feature] Send email to new user when new account has been approved by the administrator
by robertDouglass 28 Mar '05

28 Mar '05

Issue status update for http://drupal.org/node/19587 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass Status: active Sites that operate under the "Visitors can create accounts but administrator approval is required" strategy suffer from the fact that users are never notified when the site admin approves their new account. This leaves them having to try to log in from time to time hoping that the busy admin has finally gotten around to it. Of course the admin could, as a courtesy, send a mail saying "OK, go for it", but this really should be an automatic part of the workflow. robertDouglass

1 0