September 2005 - Development - lists.drupal.org

[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

[drupal-devel] [feature] Add <caption> support to theme_table()
by Crell 06 Sep '05

06 Sep '05

Issue status update for http://drupal.org/node/30423 Post a follow up: http://drupal.org/project/comments/add/30423 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Crell Updated by: Crell Status: patch (code needs review) Attachment: http://drupal.org/files/issues/theme_table_0.patch (1001 bytes) Well, if I made this patch properly :-), this patch adds a fourth parameter to the theme_table() function, $caption. If set, it adds a <caption>$caption</caption> line to the table. If it is not set, this patch has no effect. All styling is left up to CSS to figure out. It seems to me that $caption would make more sense as the 3rd parameter, before $attributes, but that would break backward compatibility so I just tacked it on at the end. I'll leave the final order of parameters up to someone else to figure out. Crell

5 11

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

06 Sep '05

I have had a problem with the default theme of Drupal for a long time. While BlueMarine is not a bad theme, it doesn't really showcase Drupal, and reading the post about this, I have to agree with Ber that we need a proper theme to show off Drupal. With Ber, Jose and Larry's ideas and insight, I am sure this would be a killer addition, perhaps not for 4.7, but definately in the near future! Regards, Kobus >>> berdrupal(a)tiscali.be 9/5/2005 10:14:17 PM >>> I am sorry for being unclear, again!. Op maandag 05 september 2005 21:47, schreef Larry Garfield: > Now, if all of the Ajax functionality was available in core but only > activated if some flag is set in a theme, then we're talking. That way > theme developers can pick and choose which features they want, but don't > have to know the ins and outs of cross-browser Javascript. My idea, was, indeed, to intrduce some form of (E.G.) theme('form_autofill',$foo, $bar); instead of form_autofill, that does all the checks on its own ,yet fails to improve usability. I would love to see a: theme('AJAX_autofill', $foo, $bar) that is only enabled in a few themes, yet, not default drupal behaviour Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

1 0

[drupal-devel] CiviCRM v1.1 Release
by Dave Greenberg 06 Sep '05

06 Sep '05

The CiviCRM team is happy to announce availability of our 1.1 release. This codebase has now been through our internal QA and several beta release cycles and we feel it is quite solid. We encourage interested CivicSpace and Drupal folks to: ** Try out our public demo 'sandbox' at : http://demo.openngo.org/civicrm/drupal-php5/ AND / OR ** Download, install the release and start using it for your organization(s) and projects. Grab the tarball file for php4 or php5 depending on which you are running from: http://downloads.openngo.org/civicrm/ For those of you who are currently running recent 1.1 beta releases (marked ...v1.1BETA-rev2811.tgz or later): - no database rebuild is required for 1.1 final - you can simply untar 1.1 final on top of your existing installation This release requires manual installation. We have created detailed installation documentation - which has now been test-driven by several members of the community - and should enable moderately technical folks to get through the installation succesfully. http://objectledge.org/confluence/pages/viewpage.action?pageId=3989 If you'd rather wait for an automated installer - the upcoming 0.8.2 CivicSpace release will install CiviCRM, and should be available soon. This release will include Massmailer and Volunteer integration. We hope you find CiviCRM to be exciting and useful - and look forward to hearing your feedback. If you are interested in taking a peek at what we're working on for our next release, you can check out our upcoming release roadmaps: v1.2 Roadmap - http://objectledge.org/confluence/display/CRM/CiviCRM+v1.2 v2.0 Candidate Features - http://objectledge.org/confluence/display/CRM/CiviCRM+v2.0 We anticipate releasing v1.2 in six to eight weeks. Best Regards, Dave Greenberg for the CiviCRM team

1 0

[drupal-devel] [bug] bug with hook_update() when using revisions.
by gordon 06 Sep '05

06 Sep '05

Issue status update for http://drupal.org/node/30308 Post a follow up: http://drupal.org/project/comments/add/30308 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: gordon Reported by: gordon Updated by: gordon Status: patch (code needs review) Attachment: http://drupal.org/files/issues/book_31.patch (812 bytes) This is a bug in the book module from the node revision patch (http://drupal.org/node/7582) where the book_update() seems to have an additional %s in the INSERT. gordon

2 1