- Development - lists.drupal.org

[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

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by Robin Monks 27 May '05

27 May '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: 4.6.0 Component: statistics.module Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: Robin Monks Reported by: massabob Updated by: Robin Monks -Status: active +Status: patch Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin Robin Monks Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 07:51 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ May 27, 2005 - 01:44 : rbarreca Should read user_access('access statistics') not user_access('display statistics').

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 Which part of comment.module? I hope you don't think the crazy "thread 1.1.2/, 1.2" stuff is /better/. 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.

1 0

[drupal-devel] More flexible user profile page - blocks to the rescue
by Moshe Weitzman 27 May '05

27 May '05

So I'm looking at how to make the user profile page prettier and more useful. I'm using the various social networking sites for ideas. Here are 3 sample pages in case you are curious: http://www.friendster.com/user.php?uid=1856275 http://360.yahoo.com/profile-9lciejI3aafX1stHPoIRNmkmv4EowQ-- http://levistus.1up.com/ The user profile page is actually quite simple. The rendering function [theme_user_profile()] accepts an associative array where a key is a 'category name' and a value is a hunk of HTML. The categories are defined by the modules which are active. The order of the categories is defined by alphabetical order of module names. Note that any module can inject content onto the profile page, not just profile.module. This is good. In order to make this more flexible, we want to give the admin the choice of which items to show and where to show them. And perhaps give the user the ability to customize his profile page. It turns out that we already have a great system for managing this - blocks. Ideally, I think we could reuse the block admin page for profile page admin. There, admin will decide which 'categories' appear where, and even reuse logic like whether a category may be enabled/disabled by a user. We would not use the feature of blocks to turn on and off by path since the profile page only has one path. I'm interested in your thoughts about how this could be implemented from a UI perspective. My inclination is to add a new page for profile admin which reuses code from block.module. I'm not inclined to move block code into a block.inc, especially because block.module is required. I'd like to reuse the blocks table. I'm not sure how this fits into the 'block regions' work in progress. It would be nice to have more regions than left/right. Even without more regions, this would be useful than our current 'single column' model. Perhaps chx or nedjo could comment on this. Also, I'm not sure that grouping profile items into 'categories' is useful in this model. We might be better off copying hook_block() and letting modules declare their own blocks instead of fitting their items into arbitrary categories. Lastly, there is a chance that all this work inhibits sites which implement their own theme_user_profile(). They are currently able to do whatever they want with categories but I'm not so sure we can preserve this using the block paradigm. Feedback welcome. I'm not planning on starting code on this immediately. In fact, I'd be pleased if someone else wanted to run with this.

2 1

Re: [drupal-devel] [drupal:unconed] /includes common.inc
by Stefan Nagtegaal 27 May '05

27 May '05

Op 27-mei-2005, om 1:39 heeft drupal-devel(a)drupal.org het volgende geschreven: > User: unconed Branch: HEAD Date: Thu, 26 May 2005 23:39:25 +0000 > > Modified files: > /includes common.inc > > Log message: > - #23700: Fix some broken t()'s in common.inc > > Links: > http://cvs.drupal.org/diff.php?path=drupal/includes/ > common.inc&old=1.448&new=1.449 > > -- > [ Drupal cvs list | http://list.drupal.org/ ] Ehmmm.... Maybe it is me, but didn't we agreed that we use meaningfull variable names? So: - watchdog('php', t("Could not convert XML encoding '%s' to UTF-8.", $encoding), WATCHDOG_WARNING); + watchdog('php', t("Could not convert XML encoding '%s' to UTF-8.", array('%s' => $encoding)), WATCHDOG_WARNING); and: - watchdog('php', t("Unsupported encoding '%s'. Please install iconv, GNU recode or mbstring for PHP.", $encoding), WATCHDOG_ERROR); + watchdog('php', t("Unsupported encoding '%s'. Please install iconv, GNU recode or mbstring for PHP.", array('%s' => $encoding)), WATCHDOG_ERROR); Had to be something like: - watchdog('php', t("Could not convert XML encoding '%s' to UTF-8.", $encoding), WATCHDOG_WARNING); + watchdog('php', t("Could not convert XML encoding '%encoding' to UTF-8.", array('%encoding' => $encoding)), WATCHDOG_WARNING); - watchdog('php', t("Unsupported encoding '%s'. Please install iconv, GNU recode or mbstring for PHP.", $encoding), WATCHDOG_ERROR); + watchdog('php', t("Unsupported encoding '%encoding'. Please install iconv, GNU recode or mbstring for PHP.", array('%encoding' => $encoding)), WATCHDOG_ERROR); If yes, I'll provide a patch to correct this.. Stefan..

2 2