May 2005 - Development - lists.drupal.org

[drupal-devel] How to take up development of a module
by NSK 28 May '05

28 May '05

Hi I would like to take up development of the Amazon Items module. The owner doesn't seem to respond: http://drupal.org/node/23397 What do I need to do? I would like my version to appear in drupal.org. Should I rename my version? -- NSK http://portal.wikinerds.org

2 2

[drupal-devel] Drupal 4.6.1 release sechedule
by Dries Buytaert 28 May '05

28 May '05

Hello world, I'd like to release the first Drupal 4.6 maintenance release, Drupal 4.6.1, early next week. Please help us test the DRUPAL-4-6 branch to ensure that this release is stable, and that the upgrade path works. Thanks. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] upload should support open formats by default
by Bèr Kessels 28 May '05

28 May '05

Call me a purist, or whatever you want, but i do not like the fact that an OS product -Drupal- by default allows uploads of all sorts of MS office files, but not those from OO.o or koffice, etc. So would you people mind if i change the array of default allowed foile extensions into something else? Please give me your favorite extensions too. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

2 1

[drupal-devel] [bug] New pager code broken taxonomy pagers
by Dries 27 May '05

27 May '05

Issue status update for http://drupal.org/node/23687 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Dries Status: patch Morbus: the funky comment thread stuff rocks. We should do the same for book pages and taxonomy terms if it can be done effectively. This doens't mean we should remove the traditional pid-columns. Dries Previous comments: ------------------------------------------------------------------------ May 26, 2005 - 21:44 : Morbus Iff I've not yet looked into it, but I doubt I'll be able to fix it (the original taxonomy/term pager code was a hack that moshe taught me about). In a nutshell, though, the recent pager cleanup in head has broken the term pagers for vocabularies. ------------------------------------------------------------------------ May 26, 2005 - 22:21 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_23687_taxopager.patch (1.88 KB) Patch attached. ------------------------------------------------------------------------ May 27, 2005 - 09:05 : Steven Why can't this code use pager_query() and query the database directly? If free tagging vocabularies can get so big, it seems a very inefficient thing to fetch the entire list. ------------------------------------------------------------------------ May 27, 2005 - 09:05 : Steven Note: if you need to fetch a list of tags ordered by hierarchy in one query, you should look at how comment.module does it. ------------------------------------------------------------------------ May 27, 2005 - 13:17 : Morbus Iff Which part of comment.module? I hope you don't think the crazy "thread 1.1.2/, 1.2" stuff is /better/. ------------------------------------------------------------------------ May 27, 2005 - 15:19 : Steven Maybe it's crazy, but it has a single, pagable query and an unambigous sorting both ways. It works well for what it needs to do. In fact, the only problem is the assignment of numbers because we cannot do a "natural order" sort in SQL. Right now it uses a rather inefficient coding that scales O(n) with size and adds another digit every 10 values. This prompted me to experiment with better codings. First I generalized the current scheme a bit, then tweaked it to get near O(log n) scaling and on average only 20-30% more digits than an equivalent decimal notation, while still retaining the string sorting property. Quite fun actually. I don't see the problem with the approach though... all it does is store a compact ordering key per row. Compare this to the convoluted tree logic in taxonomy_get_tree() and I know which one I prefer. Of course, I'm not at all sure if the comment.module approach can be implemented here, but I can't believe you'd do something like this after talking about mega-taxonomies for so long. Loading in 8000 tags just to show 50 is nowhere near optimal. ------------------------------------------------------------------------ May 27, 2005 - 15:28 : Morbus Iff Fair enough. I don't have the time right now to code this though - my deadline for the full NHPR conversion is fast approaching, and the patch attached merely brings us back to the "working" behavior prior to the pager changes, not "better" behavior, which you're proposing. However, I'm a little .. .. .. cautious about the idea of using a comment.thread-like equivalent (something I immediately knee-jerked disliked the first time I saw it) for a regular parent/child relationship just to get a hierarchal sort based on a LIMIT. This can't be how other database apps are doing it, is it?

1 0

[drupal-devel] [bug] New pager code broken taxonomy pagers
by Morbus Iff 27 May '05

27 May '05

Issue status update for http://drupal.org/node/23687 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch Fair enough. I don't have the time right now to code this though - my deadline for the full NHPR conversion is fast approaching, and the patch attached merely brings us back to the "working" behavior prior to the pager changes, not "better" behavior, which you're proposing. However, I'm a little .. .. .. cautious about the idea of using a comment.thread-like equivalent (something I immediately knee-jerked disliked the first time I saw it) for a regular parent/child relationship just to get a hierarchal sort based on a LIMIT. This can't be how other database apps are doing it, is it? Morbus Iff Previous comments: ------------------------------------------------------------------------ May 26, 2005 - 14:44 : Morbus Iff I've not yet looked into it, but I doubt I'll be able to fix it (the original taxonomy/term pager code was a hack that moshe taught me about). In a nutshell, though, the recent pager cleanup in head has broken the term pagers for vocabularies. ------------------------------------------------------------------------ May 26, 2005 - 15:21 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_23687_taxopager.patch (1.88 KB) Patch attached. ------------------------------------------------------------------------ May 27, 2005 - 02:05 : Steven Why can't this code use pager_query() and query the database directly? If free tagging vocabularies can get so big, it seems a very inefficient thing to fetch the entire list. ------------------------------------------------------------------------ May 27, 2005 - 02:05 : Steven Note: if you need to fetch a list of tags ordered by hierarchy in one query, you should look at how comment.module does it. ------------------------------------------------------------------------ May 27, 2005 - 06:17 : Morbus Iff Which part of comment.module? I hope you don't think the crazy "thread 1.1.2/, 1.2" stuff is /better/. ------------------------------------------------------------------------ May 27, 2005 - 08:19 : Steven Maybe it's crazy, but it has a single, pagable query and an unambigous sorting both ways. It works well for what it needs to do. In fact, the only problem is the assignment of numbers because we cannot do a "natural order" sort in SQL. Right now it uses a rather inefficient coding that scales O(n) with size and adds another digit every 10 values. This prompted me to experiment with better codings. First I generalized the current scheme a bit, then tweaked it to get near O(log n) scaling and on average only 20-30% more digits than an equivalent decimal notation, while still retaining the string sorting property. Quite fun actually. I don't see the problem with the approach though... all it does is store a compact ordering key per row. Compare this to the convoluted tree logic in taxonomy_get_tree() and I know which one I prefer. Of course, I'm not at all sure if the comment.module approach can be implemented here, but I can't believe you'd do something like this after talking about mega-taxonomies for so long. Loading in 8000 tags just to show 50 is nowhere near optimal.

1 0

[drupal-devel] [bug] New pager code broken taxonomy pagers
by Steven 27 May '05

27 May '05

Issue status update for http://drupal.org/node/23687 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Steven Status: patch Maybe it's crazy, but it has a single, pagable query and an unambigous sorting both ways. It works well for what it needs to do. In fact, the only problem is the assignment of numbers because we cannot do a "natural order" sort in SQL. Right now it uses a rather inefficient coding that scales O(n) with size and adds another digit every 10 values. This prompted me to experiment with better codings. First I generalized the current scheme a bit, then tweaked it to get near O(log n) scaling and on average only 20-30% more digits than an equivalent decimal notation, while still retaining the string sorting property. Quite fun actually. I don't see the problem with the approach though... all it does is store a compact ordering key per row. Compare this to the convoluted tree logic in taxonomy_get_tree() and I know which one I prefer. Of course, I'm not at all sure if the comment.module approach can be implemented here, but I can't believe you'd do something like this after talking about mega-taxonomies for so long. Loading in 8000 tags just to show 50 is nowhere near optimal. Steven Previous comments: ------------------------------------------------------------------------ May 26, 2005 - 21:44 : Morbus Iff I've not yet looked into it, but I doubt I'll be able to fix it (the original taxonomy/term pager code was a hack that moshe taught me about). In a nutshell, though, the recent pager cleanup in head has broken the term pagers for vocabularies. ------------------------------------------------------------------------ May 26, 2005 - 22:21 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_23687_taxopager.patch (1.88 KB) Patch attached. ------------------------------------------------------------------------ May 27, 2005 - 09:05 : Steven Why can't this code use pager_query() and query the database directly? If free tagging vocabularies can get so big, it seems a very inefficient thing to fetch the entire list. ------------------------------------------------------------------------ May 27, 2005 - 09:05 : Steven Note: if you need to fetch a list of tags ordered by hierarchy in one query, you should look at how comment.module does it. ------------------------------------------------------------------------ May 27, 2005 - 13:17 : Morbus Iff Which part of comment.module? I hope you don't think the crazy "thread 1.1.2/, 1.2" stuff is /better/.

1 0

[drupal-devel] Question on block creation
by Syscrusher 27 May '05

27 May '05

Good evening! Is there a "Drupally correct" way to do the following two things? 1. Obtain the current Drupal path without querying web server variables. 2. Know whether or not the current page is displaying a node in full-page view *from within a block* (i.e., *not* from within the node content creation). I know how to do this as a kludgy hack, but is there a nice, elegant way to obtain this info? If not, a function like drupal_get_current_path() might be a useful addition to core for 4.7, and probably easy to implement. :-) Kind regards, Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher

2 2

[drupal-devel] [bug] System module relies on node module
by Thox 27 May '05

27 May '05

Issue status update for http://drupal.org/node/23736 Project: Drupal Version: 4.6.0 Component: system.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/system.module_8.patch (1 KB) The system module uses node_list() without checking if the node module is loaded. Since the node module is optional, I've patched it to use module_invoke('node', 'list') instead. Thox

1 0

[drupal-devel] [bug] Non locale date information in theme
by Poetro 27 May '05

27 May '05

Issue status update for http://drupal.org/node/23734 Project: Drupal Version: 4.6.0 Component: aggregator.module Category: bug reports Priority: normal Assigned to: Poetro Reported by: Poetro Updated by: Poetro Status: patch The aggregator modul does not display dates in locale format. To solve this, you have to modify 2 rows in the aggregator modul (1.233.2.4): line 1103: - $output .= '<h3>'. date('F j, Y', $item->timestamp) ."</h3>\n"; + $output .= '<h3>'. format_date($item->timestamp, 'custom', 'F j, Y') ."</h3>\n"; line 1107: - $output .= ' <div class="date">'. date('H:i', $item->timestamp) ."</div>\n"; + $output .= ' <div class="date">'. format_date($item->timestamp, 'custom', 'H:i') ."</div>\n"; Poetro

2 1

[drupal-devel] PHP string functions overloading for multibyte support
by Piotr Szotkowski 27 May '05

27 May '05

Hello. My name is Piotr Szotkowski and I'm a developer responsible for internationalisation, and, thus, UTF-8 support in the CiviCRM module. One of the problems I've encountered is that we'd like PHP to overload the string manipulation functions with their multibyte counterparts (as per [1]). Unfortunately, the overloading is possible only at the directory level, which means we'd have to overload all of the Drupal's calls, not only CiviCRM's ones. After adding php_value mbstring.func_overload 7 php_value mbstring.internal_encoding UTF-8 to the end of my /var/www/drupal/.htaccess, every Drupal page starts with the following warning: warning: mb_strrpos() [function.mb-strrpos]: Empty haystack in /var/www/drupal/includes/menu.inc on line 974. which, of course, breaks any following header() calls. What do you think about the whole idea of forcing this overload on Drupal? Is it feasible and I should pursuit the warning (and any other that follow), or should I simply drop this idea, as it will break Drupal and/or any popular modules anyway? // We could rewrite all of our substr(), split(), strpos() calls to // their mb_* counterparts, the catch is we'd also have to rewrite // parts of third-party code (like Smarty), and we'd rather try the // overloading first. We're using CiviCRM inside Drupal 4.6.0, running on PHP 5 and Apache 2. [1] http://www.php.net/manual/en/ref.mbstring.php#mbstring.overload Cheers, -- Shot -- Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. -- Edward Abbey ====================== http://shot.pl/hovercraft/ === http://shot.pl/1/125/ ===

5 15