- Development - lists.drupal.org

[drupal-devel] Crucial problem with mysql 4.1.x and collation
by Abalieno 07 Sep '05

07 Sep '05

This is a rather serious problem, from my point of view, that I foresee getting rather widespread if not solved quickly. After a few hours of research and an headache here's what I discovered: - Mysql 4.1.x adds the possibility to set a collation for the database. This seems a new feature that wasn't there before. - By default it seems that every database created or imported is automatically set to "latin1_swedish_ci". The whole database is set with that collation as you install drupal under that version of mysql or import a previous dump. - This is causing a serious corruption in the database while exporting it because accented and other utf-8 characters are just NOT COMPATIBLE with the latin1_swedish_ci set. - This means that if you install drupal on mysql 4.1.x, the very first time you export the database for a backup or whetever else, you'll finish with a corrupted dump because all the accented characters in the nodes, comments and aggregator items will get replaced with GARBAGE. As -> "SaturdayÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢s Teen People" in the place of "Saturday ’s Teen People" This is taken from my now broken database and since I noticed this too late I now cannot do anything if not manually change every single entry. How fun. - In the handbook, install.txt and all the other install guides for Drupal THERE IS NO MENTION of the collation. This means that it's written nowhere how to set the collation and so everyone just follows the standard instructions and finishes with a "latin1_swedish_ci" as it happened to me. Including the text in the aggregator items, node and comment bodies. - How the hell the DB must be configured now? Because from what I read here: http://drupal.org/node/15746#comment-36443 It's not even possible to set Drupal to use utf8 because it's still not compliant. So, beside having my database now unrecoverable, how should I set it to have it working properly from now on and be able to back up it without getting unrecoverable garbage text? Then I seriously suggest you to patch the guides and the drupal package to stop this or it would become a rather large problem considering that following step by step the instruction you unavoidably go toward this corruption problem. - HRose / Abalieno

3 3

[drupal-devel] AutoComplete suggestion
by Stefan Nagtegaal 07 Sep '05

07 Sep '05

Just want you guys to see this! We have a nice autocomplete field now, but this is extremely cool! http://script.aculo.us/demos/ajax/autocompleter_customized I love it! Stefan --- Stefan Nagtegaal Drupal Thinker & Themer

2 1

Re: advanced settings (was Re: [drupal-devel] advanced theme in core vs all in core.)
by Kobus Myburgh 07 Sep '05

07 Sep '05

> IMO that page should only be a summary of already defined variables. So, in > contrary to windows registry or (shivver) gnome-conf, this should (IMO) only > list the variables that are settable in other places too. I sort-of disagree with that. Wouldn't that defeat the purpose of what sparked this thread? Having the ability to add extra settings will not be possible if you only keep settings that can be set elsewhere. If you're going for this approach, you're doing useless duplication for the most part. The only people who will use it then are people who know the innards of Drupal very well, i.e. Developers or people who've been involved for a long time in Drupal otherwise. Newbies and less technical users won't... If I understand this whole thread correctly, this started with "adding another option would make the interface cluttered." From there, came the idea that new (less frequently used) options could be added to a separate page. Regards, Kobus

1 0

[drupal-devel] [bug] array-merge() error thrown (issue when rolling back node revisions)
by killes 06 Sep '05

06 Sep '05

Issue status update for http://drupal.org/node/16140 Post a follow up: http://drupal.org/project/comments/add/16140 Project: Drupal Version: cvs -Component: menu system +Component: comment.module Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: killes(a)www.drop.org Reported by: lyk0s(a)drupal.org Updated by: killes(a)www.drop.org -Status: patch (code needs review) +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/comment_16.patch (828 bytes) this is a bug somewhere else. A menu entry defines callback arguments that are not wrapped in an array. Either a contrib module or comment module. Patch attached. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Tue, 25 Jan 2005 03:25:26 +0000 : lyk0s(a)drupal.org warning: array_merge() [function.array-merge]: Argument #1 is not an array in /Web/cybertrib.com/..../includes/menu.inc on line 349. (I am using PHP 5 :) ------------------------------------------------------------------------ Thu, 30 Jun 2005 13:43:30 +0000 : townxelliot Attachment: http://drupal.org/files/issues/menu.inc_2.patch (596 bytes) As far as I can tell, this bug is still not fixed in the latest (as of today) CVS version. I've attached a patch for it (diff -Nur, as I couldn't work out what the preferred patch format for Drupal is). I found the error occurred when running under PHP 5 and attempting to rollback to a previous revision of a node. ------------------------------------------------------------------------ Sat, 02 Jul 2005 12:27:28 +0000 : Dries I think we can avoid having to do the array_merge() in this case. Would be nice if you could a slightly cleaner solution. It might be possible.

1 0

[drupal-devel] [bug] use upload_tmp_dir as default for FILE_DIRECTORY_TEMP
by m3avrck 06 Sep '05

06 Sep '05

Issue status update for http://drupal.org/node/26249 Post a follow up: http://drupal.org/project/comments/add/26249 Project: Drupal Version: 4.6.2 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: danielc Updated by: m3avrck Status: patch (code needs review) Works for me as well. Question though, Drupal Admin > Settings allows a user to specify a temp directory, does this interfere with that? This patch defines a tmp directory but Drupal Admin > Settings allows another one to be defined. Haven't looked into this but this could be a deeper issue. If this isn't an issue, then +1 from me. m3avrck Previous comments: ------------------------------------------------------------------------ Sat, 02 Jul 2005 20:03:13 +0000 : danielc In includes/file.inc, the FILE_DIRECTORY_TEMP constant is set as follows: define('FILE_DIRECTORY_TEMP', IS_WINDOWS ? 'c:\\windows\\temp' : '/tmp'); It's wiser to set it to php.ini's upload_tmp_dir value: define('FILE_DIRECTORY_TEMP', ini_get('upload_tmp_dir')); I noticed this issue because I'm running Windows 2000, which defaults to an install directory of c:\winnt, not c:\windows. When I go to the "Settings" administration page, (while running PHP 5.0.5-dev) I got the following error at the top of the page: warning: mkdir() [function.mkdir]: No such file or directory in ...\includes\file.inc on line 86. ------------------------------------------------------------------------ Thu, 07 Jul 2005 13:05:36 +0000 : AlberT75 I had the same problem when installed on a host with open_base_dir enabled (it should be on a decent hoster machine)... ------------------------------------------------------------------------ Sat, 03 Sep 2005 21:42:49 +0000 : crunchywelch Attachment: http://drupal.org/files/issues/file.inc.patch (635 bytes) Here is a patch for this, seems like a good idea to me, works on a new HEAD install on SUSe Linux. ------------------------------------------------------------------------ Sat, 03 Sep 2005 21:43:17 +0000 : crunchywelch change status

1 0

[drupal-devel] [bug] speed up "Top pages in past n days" page
by Jeremy 06 Sep '05

06 Sep '05

Issue status update for http://drupal.org/node/28924 Post a follow up: http://drupal.org/project/comments/add/28924 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: minor Assigned to: Jeremy(a)kerneltrap.org Reported by: Jeremy(a)kerneltrap.org Updated by: Jeremy(a)kerneltrap.org Status: patch (code needs review) Attachment: http://drupal.org/files/issues/statistics.module-cvs_0.patch (615 bytes) Displaying statistics pages can be slow. The attached patch removes one of the "GROUP BY" columns to increase the speed of generating the "Top pages in the past n days" page. (Grouping by 'title' does not work, as there are many different paths that can have the same title. Instead, 'path' is unique for each page, so it is a more logical column to group by. I tested this on my active webpage to verify that the resulting page was what I expected.) Jeremy(a)kerneltrap.org

3 3

[drupal-devel] [feature] More allowed HTML tags by default
by robertDouglass 06 Sep '05

06 Sep '05

Issue status update for http://drupal.org/node/30481 Post a follow up: http://drupal.org/project/comments/add/30481 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/filter_patch.txt (994 bytes) This patch extends the list of HTML tags that are allowed by the HTML filter by default. This is a feature that was requested in this thread: http://drupal.org/node/30364#new The list of tags allowed by this patch includes: <a> <em> <strong> <cite> <blockquote> <pre> <code> <ul> <ol> <li> <dl> <dt> <dd> <h2> <h3> <h4> <h5> <h6> <ins> <del> I didn't include <h1> because that is used by the title more often than not. Discussion on the list of tags is welcome, but I agree with the poster that mentioned this that there could be more without any danger to site or theme. robertDouglass

2 1

[drupal-devel] testing for NULL or empty variables or array keys
by Nedjo Rogers 06 Sep '05

06 Sep '05

I find I'm sometimes not sure which types of test I should apply to test if a variable (or array key) is null or empty. Looking at the code, I see various usages: if (is_null($variable)) if (empty($variable)) if ($variable == NULL) if ($variable === NULL) if ($objectname->propertyname) if (array_key_exists($key, $arrayname)) if ($arrayname['key']) etc. Can anyone point to or suggest a limited set of tests that we should use, and guidelines for when each should be applied? This would be a useful addition to the coding standards, http://drupal.org/node/318. Thanks!

1 0

Re: [drupal-devel] advanced theme in core vs all in core.
by Kobus Myburgh 06 Sep '05

06 Sep '05

> I am 100% opposed to having that be handled by the theme layer. I > believe it's core functionality, and it has NOTHING (less than > nothing actually) to do with the theme. If I am not mistaken, it will be core functionality, and I think what Ber meant was that only the function is CALLED in the theme. The function will not RESIDE in the theme. If that is indeed the case, I agree with Ber. If the function is to RESIDE in the theme, I agree with Adrian. > I don't have an issue with there being a variable, in settings.php > not in the interface) that allows you to change the behaviour. This is a usability no-no. How will non-techie users change this easily? > I do however think that we need a new default theme =) Ahem! Regards, Kobus

2 1

Re: [drupal-devel] advanced theme in core vs all in core.
by Kobus Myburgh 06 Sep '05

06 Sep '05

> An example would be a website with multiple themes, where users would > be confused when they change theme and suddenly don't have the same > functionality that they had a moment ago. That is the beauty of themes. This is not a problem, in my opinion, but a desired feature of this approach. A site with a diversity of users, such as Drupal.org would have different users, such as developers, designers, or just regular visitors. Designers might like to see AJAX stuff, because it appeals to them, developers may not. How to handle this? Let them choose the theme. Not everyone wants the same features. IMVHO, it is left to the site admin to make sure that the correct theme is set as default, and only people wanting something different should set it that way. I see this as a non-issue, because if you don't like the new theme you selected, go back to the previous one. Core functionality in a theme will not be removed, so the theme can at least get the user back to changing it again to what he wants. Regards, Kobus

1 0