August 2005 - Development - lists.drupal.org

[drupal-devel] [task] A bit more robust code for update.php
by drumm 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/29669 Post a follow up: http://drupal.org/project/comments/add/29669 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Using the faster './' for including files (the absolute path avoids some filesystem traversal). isset to prevent php notices. drumm

2 2

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Morbus Iff 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch (code needs review) Adrian - I'll be attaching a new version either later today or tomorrow, with a CHANGELOG. I'll also be running a live version of it over on NHPR.org for people to play with. The three major things I'm worried about right now are a) doxygen, b) variable/function naming, c) GMT considerations. After those, I'll be exploring a patch for my own needs: the ability to get archives for particular term. Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier ok, thanks again :D ------------------------------------------------------------------------ Mon, 29 Aug 2005 13:41:43 +0000 : Junyor +1 for this change. The archive.module in core is dead. ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:14:30 +0000 : adrian What is the progress on this morbus ?

1 0

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by adrian 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: adrian Status: patch (code needs review) What is the progress on this morbus ? adrian Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier ok, thanks again :D ------------------------------------------------------------------------ Mon, 29 Aug 2005 13:41:43 +0000 : Junyor +1 for this change. The archive.module in core is dead.

1 0

[drupal-devel] [feature] List of bloggers
by Bèr Kessels 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/17030 Post a follow up: http://drupal.org/project/comments/add/17030 Project: Drupal Version: cvs Component: blog.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch (code needs review) Thanks George, you are correct. I changed the query, it is now smaller and faster. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Tue, 08 Feb 2005 23:27:27 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.patch (1.66 KB) Small patch to show a list of bloggers. We all should know that blog.module is not meant for personal blogging, but that set aside, we do not have a way to show all bloggers, on a site as a list. This patch ads a few lines that will allow you to show that overview of blogging users. It ads a menu item, disabled by default that shows such a list. ------------------------------------------------------------------------ Tue, 08 Feb 2005 23:31:49 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list.png (4.02 KB) Here is a small screeny that shows what this is about. ------------------------------------------------------------------------ Tue, 08 Feb 2005 23:34:15 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/list_bloggers_2.png (2.25 KB) hmm. error in my png file. Here is a correct one. ------------------------------------------------------------------------ Sat, 19 Feb 2005 20:13:20 +0000 : Emiliano Hi Bèr Kessels! Thanks for the patch! It's really useful! :-) I just noticed what I think is a little mistake in this line: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url('blog/'.$row->uid.'/feed'), TRUE); Which I believe should end like: $items[] = l($row->name, 'blog/'.$row->uid)." ".theme('xml_icon', url*('blog/feed/'.$row->uid)*, TRUE); Ah, and BTW, "db_rewrite_sql" didn't work for me... I just cut it off... ;-) Cheers, Emiliano. ------------------------------------------------------------------------ Thu, 17 Mar 2005 22:17:39 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2.patch (1.81 KB) and here is the actual patch. (i think i really need some script that tells me i did not attach a patch ;) ) ------------------------------------------------------------------------ Thu, 17 Mar 2005 22:19:53 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_2_0.patch (1.71 KB) sigh. something tells me i should stop working.... a silly "F" sneaked into the previous patch. ------------------------------------------------------------------------ Thu, 24 Mar 2005 20:25:01 +0000 : Anonymous I applied the patch, reuploaded the blog.module and then deactivated and reactivated it. I cannot see a difference. How do I access the blog users page? Drupal 4.6rc thanks for the help. ------------------------------------------------------------------------ Thu, 24 Mar 2005 20:53:26 +0000 : Bèr Kessels look in the menu admin. ------------------------------------------------------------------------ Wed, 18 May 2005 13:38:39 +0000 : Bèr Kessels Nearly two months since the patch. If there is no need for this I will mark it won't fix. ------------------------------------------------------------------------ Wed, 18 May 2005 13:52:56 +0000 : tostinni I made a custom block for this, but it still need a little improvment (add "read more" for example). So I don't know if it's usefull but if anyone care : <?php $result = db_query("SELECT u.uid, u.name, COUNT(0) AS num FROM {node} n LEFT JOIN {users} u ON u.uid = n.uid WHERE n.type = 'blog' GROUP BY u.uid, u.name ORDER BY u.name ASC"); while ($blog = db_fetch_object($result)) { $output .= '<li />'.l($blog->name. ' ('.$blog->num.')', 'blog/'.$blog->uid); } return '<ul>'.$output.'</ul>'; ?> ------------------------------------------------------------------------ Wed, 18 May 2005 16:06:36 +0000 : Chris Johnson I think this is a useful feature. I've coded custom blocks in the past to provide it on my sites. ------------------------------------------------------------------------ Sat, 21 May 2005 05:23:11 +0000 : Andrzej7 I was a little afraid (poor PHP) to install the patch (March...), but I have made a block. And it's very nice. One question only. All the bloggers are shown, but the Admin (user No 1) is on the list and he has no blogs. What's that? ------------------------------------------------------------------------ Sun, 22 May 2005 16:24:08 +0000 : Bèr Kessels To avoid confusion: this patch ads no blocks, but shows the list inline: as content! ------------------------------------------------------------------------ Sat, 18 Jun 2005 22:07:42 +0000 : igrcic aaargh.....there is a problem when using PostgreSQL db. After I successfully patch blog.module and enable it in menu, click on it and following sql errors pop up: warning: pg_query(): Query failed: ERROR: function count(integer, character varying) does not exist HINT: No function matches the given name and argument types. You may need to add explicit type casts. in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 45. user error: query: SELECT COUNT(DISTINCT u.uid, u.name) FROM users u LEFT JOIN node n ON n.uid = u.uid WHERE n.type = 'blog' AND n.status =1 ORDER BY n.created DESC in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 62. warning: pg_query(): Query failed: ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 45. user error: query: SELECT DISTINCT u.uid, u.name FROM users u LEFT JOIN node n ON n.uid = u.uid WHERE n.type = 'blog' AND n.status = 1 ORDER BY n.created DESC LIMIT 10 OFFSET 0 in /web/www/htdocs/iaeste3/includes/database.pgsql.inc on line 62 For first one its clear, there is no such fucntion in Postgresql, and second one is typical Postgresql/Mysql error, n.created isn't in select syntax. But if we put it in a select distinct syntax , it isn't DISTINCT anymore, so I get lots of lines with user and all of his blogs, with different time of course. So we must modify query a bit: SELECT DISTINCT u.name, u.uid, MAX(n.created) as time FROM users u LEFT JOIN node n ON n.uid = u.uid WHERE n.type = 'blog' AND n.status = 1 GROUP BY u.name,u.uid ORDER BY time DESC It works fine like this :) Didn't look for first one yet... will when I catch some time. Cheers! ------------------------------------------------------------------------ Sat, 18 Jun 2005 22:15:29 +0000 : igrcic Attachment: http://drupal.org/files/issues/blog_bloggers_list_0.patch (1.75 KB) Sorry, here is a patch for a blog_bloggers_list_2_0.patch :) ------------------------------------------------------------------------ Tue, 05 Jul 2005 09:08:19 +0000 : Bèr Kessels That doesz not seem a patch of a patch, but a regular patch. Igrirc, please note that the SQL contains unbracketed tablenames. That is unacceptible. If you don't want to fix it, please report it back here, So I can fix it otherwise :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 19:46:13 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/blog_bloggers_list_1.patch (1.75 KB) Bingo! My own patch, brought to you by patchbingo! ------------------------------------------------------------------------ Thu, 25 Aug 2005 04:15:52 +0000 : essig I think 'DISTINCT' can be removed from the query in blog_bloggers_list_1.patch [1]. There is already a 'GROUP BY' clause over the same columns. George Essig [1] http://drupal.org/files/issues/blog_bloggers_list_1.patch

1 0

[drupal-devel] [bug] Problems with PostgreSQL and GROUP BY statements
by Cvbge 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/20255 Post a follow up: http://drupal.org/project/comments/add/20255 Project: Drupal Version: cvs Component: throttle.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: Cvbge -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal-head-throttle-20255.diff (856 bytes) Attached patch should fix the error. I've removed the ORDER BY (sorting does not have any impact on COUNT) and GROUP BY (we already have DISTINCT). Please test. Cvbge Previous comments: ------------------------------------------------------------------------ Sun, 10 Apr 2005 09:05:22 +0000 : Anonymous I set up Drupal from CVS yesterday, using PostgreSQL 8.0 as database. viewing pages as anonymous user often generates the following warning: warning: pg_query(): Query failed: ERROR: column "sessions.timestamp" must appear in the GROUP BY clause or be used in an aggregate function in /www/htdocs/includes/database.pgsql.inc on line 45.always followed by: user error: query: SELECT COUNT(DISTINCT(uid)) AS count FROM sessions WHERE timestamp >= 1113122734 AND uid != 0 GROUP BY uid ORDER BY timestamp DESC in /www/htdocs/includes/database.pgsql.inc on line 62. ------------------------------------------------------------------------ Sun, 10 Apr 2005 18:18:17 +0000 : Anonymous okay, after some time playing around in drupal, I could near the problem down a bit: the message appeared about every 10th time... and my auto-throttle-probability was set to 10%. Setting the probability to 50%, and the mentioned warnings came with that percentage. so the error seems to be in the throttle module. anyway, looking through the support issues, similar warnings ("xyz must appear in the GROUP BY") happen in several places when pgsql is used. Maybe the problem could be solved somewhere general instead of in each module, or there should be at least a note regarding this on the module developers handbook ( http://drupal.org/node/1395 ), as I assume this is some MySQL-specific notation. ------------------------------------------------------------------------ Thu, 14 Apr 2005 13:37:34 +0000 : r11r At my work, we ran into the same problem when doing a migration from Oracle to Postgres. The problem, I think, is that Postgres orders its results after the select statement not before so that it's impossible for it to order the results on a column you didn't select. I'm told we mostly ended up rewriting the queries to avoid this problem but given the information below, there might be a way around it without changing the queries too much. Here are a couple of links potentially relating to this same error: http://archives.postgresql.org/pgsql-general/2004-02/msg01199.php [1] http://www.postgresql.org/docs/7.4/static/queries-select-lists.html#QUERIES… [2] [1] http://archives.postgresql.org/pgsql-general/2004-02/msg01199.php [2] http://www.postgresql.org/docs/7.4/static/queries-select-lists.html#QUERIES… ------------------------------------------------------------------------ Fri, 15 Apr 2005 13:16:14 +0000 : adrian We always change the queries. From the link you posted : The DISTINCT ON clause is not part of the SQL standard and is sometimes considered bad style because of the potentially indeterminate nature of its results. With judicious use of GROUP BY and subqueries in FROM the construct can be avoided, but it is often the most convenient alternative. Adding the fields in the GROUP BY is the only way to have the sql work for both mysql and postgres. I'm gonna make a patch for this now. ------------------------------------------------------------------------ Mon, 22 Aug 2005 14:13:12 +0000 : Uwe Hermann Adrian, any updates on this?

1 0

[drupal-devel] [bug] [pgsql] watchdog referer, location field length
by Thomas Ilsche 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/29814 Post a follow up: http://drupal.org/project/comments/add/29814 Project: Drupal Version: cvs Component: watchdog.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Thomas Ilsche Updated by: Thomas Ilsche Status: patch (code needs review) "About field length - don't know what's right approach " Is there ANY reason to use VARCHAR(128)? MySQL stores them always using one length byte plus the actual string, resulting in a maximum VARCHAR(255), there is no reason to use a lower n? pgSQL afaik always uses four length bytes with a physical limit of 1 GB, If I am not mistake text / VARCHAR without any length specifier could be used without any disadvantages. So why not use that? I think thats more easy and comfortable than truncating the string. Thomas Ilsche Previous comments: ------------------------------------------------------------------------ Sat, 27 Aug 2005 17:40:30 +0000 : Thomas Ilsche It is quite easy to exceed the the watchdog referer and location field length of 128. The problem especielly with pgsql is that it generates an error, not just truncate the content like MySQL does. 1. For all databases I would suggest changing the limit to 255 (which is, at least for MySQL, the real limit). 2. More imporant: Add substrs to watchdog(). I would make a patch for the second but I fear I lack knowledge of update_***() for the first. ------------------------------------------------------------------------ Mon, 29 Aug 2005 14:29:05 +0000 : Cvbge Attachment: http://drupal.org/files/issues/drupal-head-referer-29814.diff (1.07 KB) This patch cuts referer to 128 characters before inserting into db, not tested. About field length - don't know what's right approach.

1 0

[drupal-devel] [bug] [pgsql] watchdog referer, location field length
by Cvbge 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/29814 Post a follow up: http://drupal.org/project/comments/add/29814 Project: Drupal Version: cvs Component: watchdog.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Thomas Ilsche Updated by: Cvbge -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/drupal-head-referer-29814.diff (1.07 KB) This patch cuts referer to 128 characters before inserting into db, not tested. About field length - don't know what's right approach. Cvbge Previous comments: ------------------------------------------------------------------------ Sat, 27 Aug 2005 17:40:30 +0000 : Thomas Ilsche It is quite easy to exceed the the watchdog referer and location field length of 128. The problem especielly with pgsql is that it generates an error, not just truncate the content like MySQL does. 1. For all databases I would suggest changing the limit to 255 (which is, at least for MySQL, the real limit). 2. More imporant: Add substrs to watchdog(). I would make a patch for the second but I fear I lack knowledge of update_***() for the first.

1 0

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Junyor 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Junyor Status: patch (code needs review) +1 for this change. The archive.module in core is dead. Junyor Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier ok, thanks again :D

1 0

[drupal-devel] [feature] Filtering of statistics ("real" visitors only)
by mikeryan 29 Aug '05

29 Aug '05

Issue status update for http://drupal.org/node/29328 Post a follow up: http://drupal.org/project/comments/add/29328 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: mikeryan Updated by: mikeryan Status: patch (code needs review) Attachment: http://drupal.org/files/issues/statistics.module_2.patch (6.73 KB) Justification: For all but the most heavily-trafficked sites, the statistics reported by Drupal are severely skewed by visits from crawlers, and from the administrators themselves. Assuming that the purpose of the statistics is to inform administrators about visits from human beings other than themselves, it is highly desirable to do our best to ignore other visits. To that end, I developed the statistics_filter module [1] (and its spinoff, the browscap module [2]). Why core? There's enough concern over the logging the statistics module does in the exit hook for the performance issues to be detailed in the help. To work as a contributed module, the statistics_filter module needs to undo what the statistics module did, essentially doubling the overhead for accesses that are meant to be ignored. If incorporated into the statistics module directly, the filtering functionality will actually reduce the database overhead (no database queries at all for ignored roles). Open issue Ignoring crawlers (which are the biggest part of the issue for most sites - my own site, with modest volume, gets 40% of its raw traffic from the Google crawler) requires the browscap database to identify crawlers. Currently I have maintenance of the browscap data (as well as provision for browser/crawler statistcs) encapsulated in a separate module. Should this support be submitted to core as a separate module, or integrated into the statistics module? Attached is a patch to statistics.module implementing filtering by roles, with filtering out crawlers dependent on an external browscap module. I hope this patch can be accepted into Drupal 4.7 - if the feeling is that the browscap code should be incorporated into statistics.module, I can do that. Thanks. [1] http://drupal.org/node/18013 [2] http://drupal.org/node/26569 mikeryan

11 21

[drupal-devel] MySQLi
by NSK 29 Aug '05

29 Aug '05

Hi, I enabled Drupal (CVS HEAD version, 29 August 2005) to work with MySQLi. Can MySQLi support be included in Drupal 4.7 or 4.8/5.0 ? This is important for people who don't use the deprecated MySQL client in their PHP, and for everyone who works with MySQL 4.1 and 5.0. This patch does not affect Drupal compatibility with older versions. http://drupal.org/node/29910 -- NSK Founder of the Wikinerds Community http://www.wikinerds.org/

1 0