July 2005 - Development - lists.drupal.org

[drupal-devel] Wordpress' new "post edit screen"
by Dries Buytaert 01 Jul '05

01 Jul '05

The next version of WordPress, WP 1.6, will have the following "post edit screen": http://asymptomatic.net/wp/images/2005/June/wp16.gif (animated) http://asymptomatic.net/wp/images/2005/June/wp16write.jpg -- Dries Buytaert :: http://www.buytaert.net/

8 11

[drupal-devel] [bug] The anonymous user account can be edited
by Chris Johnson 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/25605 Project: Drupal Version: 4.6.1 Component: user system Category: bug reports Priority: critical Assigned to: Robin Monks Reported by: nysus Updated by: Chris Johnson Status: patch I've always thought that the administrator should be able to edit uid == 0 (the anonymous user) and that ALL of drupal should use the username provided by the administrator in that record as the name of the anonymous user to display (with a default to t('anonymous')). Likewise for anything else about the anonymous user that might ever be displayed. Handling of the anonymous user has been schizophrenic. I patched it once, but then development moved things around in the 'variable' usage of anonymous so much that my patch no longer applied and making it work again would have taken a large amount of work, so I never re-developed it. But it's still the right way to do it: http://drupal.org/node/5639 Chris Johnson Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 07:06 : nysus Any user, anonymous or otherwise, can go to /user/0/edit and edit the account of the anonymous user. ------------------------------------------------------------------------ June 24, 2005 - 05:20 : Robin Monks I'll take care of this one :-) CONFIRMED on WinXP/Xitami CVS Robin ------------------------------------------------------------------------ June 24, 2005 - 05:41 : Robin Monks Attachment: http://drupal.org/files/issues/annon.user.edit.fix (1.92 KB) Here is the patch. It removes the /edit and /delete operation from user 0. Tested to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 24, 2005 - 10:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-edit-fix.patch (999 bytes) The patch didn't apply on head. I also like my solution better. ;) ------------------------------------------------------------------------ June 27, 2005 - 13:17 : Dries killes: your patch looks broken. Shouldn't $user->uid be arg(1)? ------------------------------------------------------------------------ June 27, 2005 - 13:31 : killes(a)www.drop.org One of us is confused, but who? I don't think that $user->uid has to be == arg(1). it is a global var. ------------------------------------------------------------------------ June 28, 2005 - 05:31 : Robin Monks Anyways, my patch still applies (chx had concerns earlier, but the patch was made correctly and seems to be OK). And it's been tested to work. I also like the fact that mine covers the entire user, and not just the edit portion. Robin ------------------------------------------------------------------------ June 30, 2005 - 22:39 : mfb With killes' patch I was still able to fill out the edit form at user/0/edit , user/0./edit or user/0.0/edit to create a new user. +1 for Robin's patch, which needs to be converted from DOS to UNIX format. ------------------------------------------------------------------------ July 1, 2005 - 05:25 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_anonymous_noedit.patch (701 bytes) I've tried both patches, both seem to apply, both work, with the only difference that Killes's still allows Administrator to edit anonymous account. But both patches fail to protect custom profile fields (If you create custom profile fields, any user still can access categories of profile fields for user 0). So I propose this one, which removes all operations for user 0.

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by walkah 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/25600 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: kubaZygmunt Updated by: walkah Status: patch just to follow up.. chx's patch in #7 only fixes XMLRPC servers... anything that uses XML-RPC client (i.e. drupal_auth or ping) will still be busted. walkah Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 06:28 : kubaZygmunt Attachment: http://drupal.org/files/issues/bootstrap.diff (422 bytes) I've found that new cvs version doesn't get properly db_prefix. In bootstrap.inc (function _drupal_bootstrap($phase) ) I added another global variable $db_prefix, and then it goes . I don't know if my solution is good because on my local site I can't see any blocks and on my internet site I have some caching and I can't see anything :) ------------------------------------------------------------------------ June 23, 2005 - 07:45 : kubaZygmunt Above I've put my patch ------------------------------------------------------------------------ June 23, 2005 - 07:56 : Jaza Attachment: http://drupal.org/files/issues/db_prefix_global.patch (582 bytes) Also noticed this bug, when trying to install a fresh CVS snapshot. Attached is my patch against CVS HEAD (same as kubaZygmunt's, basically). ------------------------------------------------------------------------ June 23, 2005 - 08:10 : chx Yes, this is a bug, if you look at the bootstrap patch, there were versions when I thought variables in settings.php should be written as $GLOBALS['something'] but then introduced global $something . Forgot when that something is db_prefix . ------------------------------------------------------------------------ June 28, 2005 - 00:26 : Jaza Can this patch be applied to HEAD please? This is not something that should be left sitting around in the issues list. Chx has identified that it was a simple honest mistake on his part, and has indicated that the submitted patch(es) will fix the mistake. Until this patch is applied, anyone who tries to install HEAD using db prefixes will get a fatal error. It doesn't get much more critical than that :-p. ------------------------------------------------------------------------ June 30, 2005 - 09:56 : Bart Jansens Attachment: http://drupal.org/files/issues/20050630.bootstrap-prefix-update.patch (1.21 KB) There is another related problem, it is no longer possible to override variables in settings.php. And update.php no longer works. Updated patch attached. ------------------------------------------------------------------------ June 30, 2005 - 10:04 : chx Attachment: http://drupal.org/files/issues/20050630.bootstrap-patch.patch (2.92 KB) Oh, and XML-RPC client is broken too. I talked with walkah and we found it the best to move xmlrpc.inc to modules which use them. ------------------------------------------------------------------------ June 30, 2005 - 10:09 : chx Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB) some more xml-rpc fixes. ------------------------------------------------------------------------ June 30, 2005 - 10:20 : Steven Making XML-RPC a conditional include was discussed a while ago, and decided against due to problems with the class persistency. Why is this now possible? ------------------------------------------------------------------------ June 30, 2005 - 12:36 : walkah basically - it's not. the problem is, well, the xmlrpc.inc is not very well written. It requires / depends on several global variables, etc. which leads to a fair bit of the scoping issues. If you look at what PEAR has done with this (since their XML-RPC module is based on the same original code)... you'll notice lots of $GLOBALS['...'] usage (see http://cvs.php.net/co.php/pear/XML_RPC/RPC.php) . Basically, I think we have 3 options: 1) keep banging on this old code to make it work. 2) switch libraries to either PEAR::XML-RPC or something like incutio's (http://scripts.incutio.com/xmlrpc/) 3) re-write our own custom xml-rpc library personally, I'd +1 #2 - since #1 is ugly, and #3 I personally don't have time for, and I'd rather see our developer resources going to more interesting things. that said, i know there are those with strong feelings against 3rd party libraries... but this needs to get fixed quickly. blogapi and drupal dist_auth are both currently broken in HEAD. (isn't there anyone else here that tests XML-RPC stuff??)

8 12

[drupal-devel] [bug] don't show blocks if they have no content
by Jose A Reyero 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/7897 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: ax Updated by: Jose A Reyero Status: patch +1 Tried the patch, it works Jose A Reyero Previous comments: ------------------------------------------------------------------------ May 19, 2004 - 19:06 : ax Attachment: http://drupal.org/files/issues/no.blocks.without.content.patch (5.06 KB) blog, forum, and statistics.module show their blocks even if they have no contents. this looks quite dull, eg. +----------------------+ | Forum topics | | | | Active forum topics: | | | | New forum topics: | | | | more | +----------------------+ +----------------------+ | Popular content | | | | Today's: | | | | All time: | | | | Last viewed: | | | +----------------------+ and isn't what the rest of the drupal blocks do (not showing up if there is no content). this patch fixes this. additional improvements: * removed the "more" links from blog and forum.module and replaced them with block titles linking to the respective module page. rationales: + "more" means there are more blog entries/forum topics than those linked from the blocks. this, however, wasn't always the case. + it is common user expectation that the title of a "content excerpt" links to the complete content. examples: node titles on the homepage, links in admin tables, tracker, etc. + it saves screen estate * fixed the forum link description ('Read the latest forum topics.' > 'Go to the forums.') * added a link from the 'Popular content' block title to the 'Most popular content' page (statistics). this wasn't accessible before. please review and apply. ------------------------------------------------------------------------ May 20, 2004 - 15:23 : Dries I haven't tested the patch yet but it would be nice if more block titles were links (eg. the title of the archive block could link to the main archive page). ------------------------------------------------------------------------ May 31, 2004 - 23:24 : ax want me to make all block titles link to the respective module page? ------------------------------------------------------------------------ June 2, 2004 - 19:56 : Dries I'd like to discuss this at the very least. :-) ------------------------------------------------------------------------ June 2, 2004 - 20:47 : Boris Mann I don't want clickable block titles! This is a theming issue, and I don't think it should be in by default. What is wrong with the "more" link? Empty blocks not displaying content (i.e. block doesn't show at all) is OK for some blocks, not OK for others. This would ideally be a configuration option: "display even if empty" and a checkbox. I've always wanted "Active" and "New" forum topics a) either split into two blocks or b) made it configurable to display one or the other or both. ------------------------------------------------------------------------ June 2, 2004 - 20:51 : Goba Targets for block title links could be provided by modules, but it is after all the decision of modules to print out block titles using those links. ------------------------------------------------------------------------ June 3, 2004 - 12:26 : Kjartan Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). ------------------------------------------------------------------------ June 3, 2004 - 13:53 : moshe weitzman we already pass the 'more' link separate from the content. this is about how the core themes should present that 'more' link ------------------------------------------------------------------------ June 3, 2004 - 13:58 : Kjartan >From my quick look at blocks in HEAD this is not true for the aggregator or blog blocks, they have specific div & CSS class around them yes, but they are not 100% controlable in the theme. ------------------------------------------------------------------------ June 3, 2004 - 18:18 : Boris Mann " Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). " +10!! Yes, make more block stuff themeable. This is a great solution, since you could also add a "link" field to custom blocks that would display in the same way. Ideally, both the text (e.g. "more", "check this out", "extra stuff", etc. etc.) and the link would be configurable, and the theme would take care of how this is displayed. ------------------------------------------------------------------------ June 17, 2004 - 19:52 : Dries I'm marking this patch 'active' as we agreed to disagree with the suggested patch/approach. Please resubmit or split your patch in smaller chunks. Thanks. ------------------------------------------------------------------------ June 13, 2005 - 13:28 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content.patch (3 KB) This patch fixes the actual goal of the bug "don't show blocks if they have no content". This is basically ax's patch broken up and updated to HEAD. This patches forum.module and stats. It's been tested to work on CVS HEAD. I'll take responsibility for upcoming changes to this patch. Robin ------------------------------------------------------------------------ June 13, 2005 - 13:55 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_0.patch (3.16 KB) Chx recommended moving the returns into their relative ifs. This also works on HEAD. Robin ------------------------------------------------------------------------ June 13, 2005 - 13:57 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_1.patch (3.17 KB) ...wrong patch version... Robin ------------------------------------------------------------------------ July 1, 2005 - 08:51 : mfb Looks good, +1

1 0

[drupal-devel] [bug] request_uri() broken if in subdir
by killes 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/10917 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch Another manifestation of this bug: http://drupal.org/node/26163 killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ September 17, 2004 - 21:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/requi.patch (678 bytes) We asumme the $_SERVER[REQUEST_URI] would contain only the url from the point of Drupal's directory on. This is true only iff you run from the root of your site. If you are in a subdir, the function request_uri() will be unusable if we want to construct a valid url from $base_url and request_uri() (what we do in a number of places). The attached patch fixes this by using basename(). ------------------------------------------------------------------------ September 17, 2004 - 21:45 : killes(a)www.drop.org The patch doesn't suffice if your access only the base_url of your Drupal site in a subdir. Putting on hold. ------------------------------------------------------------------------ September 17, 2004 - 23:39 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request.patch (761 bytes) ok, I think I got it. The distinction between apache and non-apache servers went away to keep it simple. ------------------------------------------------------------------------ September 18, 2004 - 02:19 : killes(a)www.drop.org Apparently the action in forms depends on the bug that I found, ie it needs request_uri to contain the full url (from documentroot on). ------------------------------------------------------------------------ September 18, 2004 - 02:53 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request_0.patch (2.46 KB) This new patch fixes the problem with forms. request_uri() also does not start with a leading slash anymore. Ask Steven for why this is good. http://acko.net/dumpx/relative.html is apparently a clue I don't get. ------------------------------------------------------------------------ September 18, 2004 - 03:04 : Steven Explanation: People are going to stick relative_uri() into links. These links are resolved relative to the $base_url which is put into the <head> tag. However, if a link URI starts with a / then it is relative to the root of the site, even if the base tag uses a path with a subdirectory. Example: <html> <base href="http://www.test.com/subdir1/"> <body> test [1] test [2] </body> </html> The first link resolves to http://www.test.com/subdir2, the second resolves to http://www.test.com/subdir1/subdir2. Thus, it is more meaningful to not have a leading slash, as this will avoid possible bugs with subdirs (which often do not get caught because the tester uses a site without a subdir) and hints at the callee that this is a relative URI too. [1] http://drupal.org//subdir2 [2] http://drupal.org/subdir2 ------------------------------------------------------------------------ March 13, 2005 - 20:38 : Chris Johnson Patch no longer applies completely to bootstrap.inc: Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/bootstrap.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/bootstrap.inc,v |retrieving revision 1.28 |diff -u -F^f -r1.28 bootstrap.inc |--- includes/bootstrap.inc 16 Sep 2004 07:17:54 -0000 1.28 |+++ includes/bootstrap.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file bootstrap.inc using Plan A... Hunk #1 succeeded at 273 (offset 83 lines). Hunk #2 succeeded at 292 (offset 83 lines). Hunk #3 failed at 446. 1 out of 3 hunks failed--saving rejects to bootstrap.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/common.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/common.inc,v |retrieving revision 1.390 |diff -u -F^f -r1.390 common.inc |--- includes/common.inc 16 Sep 2004 16:12:21 -0000 1.390 |+++ includes/common.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file common.inc using Plan A... Hunk #1 succeeded at 988 (offset -90 lines). done ------------------------------------------------------------------------ June 14, 2005 - 13:21 : Robin Monks Attachment: http://drupal.org/files/issues/request_uri.broken.if.in.subdir.patch (2.6 KB) Here is that patch re-rolled for latest CVS HEAD. Since killes hasn't been active in this bug lately, I hope he won't mind my reassigning this to myself. Robin ------------------------------------------------------------------------ June 14, 2005 - 13:22 : Robin Monks I've also tested this to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 14, 2005 - 15:33 : moshe weitzman did you test this on non apache servers? the comment that you removed is crystal clear about a need for 2 different cases. it is OK to 'make it simpler' as long as you don't remove compatibility with other web servers. I am primarily concerned with IIS. ------------------------------------------------------------------------ June 14, 2005 - 16:42 : Robin Monks I took great care to ensure I didn't remove any support needed for other servers. I also tested this patch to work on Xitami on Win32. Robin ------------------------------------------------------------------------ June 14, 2005 - 19:09 : Robin Monks I spent some more time testing, and this broke some (perhaps all) configuration forms. It appears the / is needed after all. Perhaps killes will have better luck understanding this, the / is needed IMHO. Robin

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by Jose A Reyero 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: Jose A Reyero Status: patch +1 I tested the patch, works fine, and I'm always for "more options" ;-) Jose A Reyero Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 08: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 - 02:44 : RobRoy Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ May 27, 2005 - 12:19 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ June 1, 2005 - 05:09 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ June 1, 2005 - 15:13 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ June 9, 2005 - 14:55 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ June 9, 2005 - 15:08 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ June 9, 2005 - 17:30 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ June 9, 2005 - 17:32 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ June 9, 2005 - 17:49 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ June 9, 2005 - 18:00 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ June 9, 2005 - 18:05 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ June 9, 2005 - 18:11 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin ------------------------------------------------------------------------ June 9, 2005 - 18:21 : Bèr Kessels +1 for this patch. it adds functionality, but does not add clutter nor any config options. ------------------------------------------------------------------------ June 10, 2005 - 03:39 : frjo +1 I have implemented the patch authstats_2.patch on my site running Drupal 4.6.1 and it works well. ------------------------------------------------------------------------ July 1, 2005 - 09:10 : mfb +1

1 0

[drupal-devel] [bug] The anonymous user account can be edited
by Jose A Reyero 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/25605 Project: Drupal Version: 4.6.1 Component: user system Category: bug reports Priority: critical Assigned to: Robin Monks Reported by: nysus Updated by: Jose A Reyero Status: patch Attachment: http://drupal.org/files/issues/user_anonymous_noedit.patch (701 bytes) I've tried both patches, both seem to apply, both work, with the only difference that Killes's still allows Administrator to edit anonymous account. But both patches fail to protect custom profile fields (If you create custom profile fields, any user still can access categories of profile fields for user 0). So I propose this one, which removes all operations for user 0. Jose A Reyero Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 14:06 : nysus Any user, anonymous or otherwise, can go to /user/0/edit and edit the account of the anonymous user. ------------------------------------------------------------------------ June 24, 2005 - 12:20 : Robin Monks I'll take care of this one :-) CONFIRMED on WinXP/Xitami CVS Robin ------------------------------------------------------------------------ June 24, 2005 - 12:41 : Robin Monks Attachment: http://drupal.org/files/issues/annon.user.edit.fix (1.92 KB) Here is the patch. It removes the /edit and /delete operation from user 0. Tested to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 24, 2005 - 17:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-edit-fix.patch (999 bytes) The patch didn't apply on head. I also like my solution better. ;) ------------------------------------------------------------------------ June 27, 2005 - 20:17 : Dries killes: your patch looks broken. Shouldn't $user->uid be arg(1)? ------------------------------------------------------------------------ June 27, 2005 - 20:31 : killes(a)www.drop.org One of us is confused, but who? I don't think that $user->uid has to be == arg(1). it is a global var. ------------------------------------------------------------------------ June 28, 2005 - 12:31 : Robin Monks Anyways, my patch still applies (chx had concerns earlier, but the patch was made correctly and seems to be OK). And it's been tested to work. I also like the fact that mine covers the entire user, and not just the edit portion. Robin ------------------------------------------------------------------------ July 1, 2005 - 05:39 : mfb With killes' patch I was still able to fill out the edit form at user/0/edit , user/0./edit or user/0.0/edit to create a new user. +1 for Robin's patch, which needs to be converted from DOS to UNIX format.

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by mfb 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: mfb Status: patch +1 mfb Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 00: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 26, 2005 - 18:44 : RobRoy Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ May 27, 2005 - 04:19 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ May 31, 2005 - 21:09 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ June 1, 2005 - 07:13 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ June 9, 2005 - 06:55 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ June 9, 2005 - 07:08 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ June 9, 2005 - 09:30 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ June 9, 2005 - 09:32 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ June 9, 2005 - 09:49 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ June 9, 2005 - 10:00 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ June 9, 2005 - 10:05 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ June 9, 2005 - 10:11 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin ------------------------------------------------------------------------ June 9, 2005 - 10:21 : Bèr Kessels +1 for this patch. it adds functionality, but does not add clutter nor any config options. ------------------------------------------------------------------------ June 9, 2005 - 19:39 : frjo +1 I have implemented the patch authstats_2.patch on my site running Drupal 4.6.1 and it works well.

1 0

[drupal-devel] [bug] don't show blocks if they have no content
by mfb 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/7897 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: ax Updated by: mfb Status: patch Looks good, +1 mfb Previous comments: ------------------------------------------------------------------------ May 19, 2004 - 11:06 : ax Attachment: http://drupal.org/files/issues/no.blocks.without.content.patch (5.06 KB) blog, forum, and statistics.module show their blocks even if they have no contents. this looks quite dull, eg. +----------------------+ | Forum topics | | | | Active forum topics: | | | | New forum topics: | | | | more | +----------------------+ +----------------------+ | Popular content | | | | Today's: | | | | All time: | | | | Last viewed: | | | +----------------------+ and isn't what the rest of the drupal blocks do (not showing up if there is no content). this patch fixes this. additional improvements: * removed the "more" links from blog and forum.module and replaced them with block titles linking to the respective module page. rationales: + "more" means there are more blog entries/forum topics than those linked from the blocks. this, however, wasn't always the case. + it is common user expectation that the title of a "content excerpt" links to the complete content. examples: node titles on the homepage, links in admin tables, tracker, etc. + it saves screen estate * fixed the forum link description ('Read the latest forum topics.' > 'Go to the forums.') * added a link from the 'Popular content' block title to the 'Most popular content' page (statistics). this wasn't accessible before. please review and apply. ------------------------------------------------------------------------ May 20, 2004 - 07:23 : Dries I haven't tested the patch yet but it would be nice if more block titles were links (eg. the title of the archive block could link to the main archive page). ------------------------------------------------------------------------ May 31, 2004 - 15:24 : ax want me to make all block titles link to the respective module page? ------------------------------------------------------------------------ June 2, 2004 - 11:56 : Dries I'd like to discuss this at the very least. :-) ------------------------------------------------------------------------ June 2, 2004 - 12:47 : Boris Mann I don't want clickable block titles! This is a theming issue, and I don't think it should be in by default. What is wrong with the "more" link? Empty blocks not displaying content (i.e. block doesn't show at all) is OK for some blocks, not OK for others. This would ideally be a configuration option: "display even if empty" and a checkbox. I've always wanted "Active" and "New" forum topics a) either split into two blocks or b) made it configurable to display one or the other or both. ------------------------------------------------------------------------ June 2, 2004 - 12:51 : Goba Targets for block title links could be provided by modules, but it is after all the decision of modules to print out block titles using those links. ------------------------------------------------------------------------ June 3, 2004 - 04:26 : Kjartan Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). ------------------------------------------------------------------------ June 3, 2004 - 05:53 : moshe weitzman we already pass the 'more' link separate from the content. this is about how the core themes should present that 'more' link ------------------------------------------------------------------------ June 3, 2004 - 05:58 : Kjartan >From my quick look at blocks in HEAD this is not true for the aggregator or blog blocks, they have specific div & CSS class around them yes, but they are not 100% controlable in the theme. ------------------------------------------------------------------------ June 3, 2004 - 10:18 : Boris Mann " Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). " +10!! Yes, make more block stuff themeable. This is a great solution, since you could also add a "link" field to custom blocks that would display in the same way. Ideally, both the text (e.g. "more", "check this out", "extra stuff", etc. etc.) and the link would be configurable, and the theme would take care of how this is displayed. ------------------------------------------------------------------------ June 17, 2004 - 11:52 : Dries I'm marking this patch 'active' as we agreed to disagree with the suggested patch/approach. Please resubmit or split your patch in smaller chunks. Thanks. ------------------------------------------------------------------------ June 13, 2005 - 05:28 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content.patch (3 KB) This patch fixes the actual goal of the bug "don't show blocks if they have no content". This is basically ax's patch broken up and updated to HEAD. This patches forum.module and stats. It's been tested to work on CVS HEAD. I'll take responsibility for upcoming changes to this patch. Robin ------------------------------------------------------------------------ June 13, 2005 - 05:55 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_0.patch (3.16 KB) Chx recommended moving the returns into their relative ifs. This also works on HEAD. Robin ------------------------------------------------------------------------ June 13, 2005 - 05:57 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_1.patch (3.17 KB) ...wrong patch version... Robin

1 0

[drupal-devel] [bug] node created timestamp changes on node edit
by adrinux 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/24002 -Project: Image +Project: Drupal -Version: 4.6.0 +Version: 4.6.0 -Component: image.module +Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adrinux Updated by: adrinux Status: patch No time to test this until next week myself, but It's already got two +'s so I'm moving it to core and re-titleing. Thanks to dtan for hunting this one down :) adrinux Previous comments: ------------------------------------------------------------------------ May 31, 2005 - 17:57 : adrinux When an image node is edited it changes position in the gallery, and in image taxonomy listings. This is not the usual 'most recently edited' item floating to the top. The edited image simply shifts to a different place in the gallery with no apparent logic. As far as I can tell this happens because image module sorts the images in a gallery by the node creation timestamp, and for some reason the creation timestamp is being incremented a little on editing the node. (Of course the changed timestamp also changes as expected.) Here's and example. Lets take this gallery http://sphop.perlucida.com/image/tid/62 And change the title from *sphp_2002_061_henk.jpg* to *Seagulls* on this image: http://sphop.perlucida.com/node/322 Prior to the change we have the following (info extracted from the db): nid: 322 title: sphp_2002_061_henk.jpg created: 1117550744 changed: 1117550744 And the image is listed between *sphp_2002_062_henk.jpg* and *sphp_2002_060_henk.jpg* as you'd expect. We change the title and image moves to appear between *sphp_2002_067_henk.jpg* and *sphp_2002_066_henk.jpg* as you can see: http://sphop.perlucida.com/image/tid/62?from=12 The db now gives: nid: 322 title: Seagulls created: 1117550756 changed: 1117558316 So, why does the *created* timestamp change at all, and can I stop that happening? I should say that the images in the gallery were initially imported using import_image.module - but I don't see what this could have to do with that. ------------------------------------------------------------------------ June 30, 2005 - 01:59 : dtan Attachment: http://drupal.org/files/issues/node.module.created.patch (591 bytes) You'll notice that there is an authored on text box. . .it doesn't provide seconds, so when the timestamp is created, it picks up the current minutes seconds. Thus if you edit a node (any type) and view its created field in the db, and continuously repeat over 60 seconds, you will see the created loop back down. Here is the patch. . .which is actually applied to the *node.module*. ------------------------------------------------------------------------ June 30, 2005 - 02:42 : clydefrog dtan, your patch contains html. ------------------------------------------------------------------------ June 30, 2005 - 04:40 : dtan Attachment: http://drupal.org/files/issues/node_module_created.patch (591 bytes) another one :) ------------------------------------------------------------------------ June 30, 2005 - 16:13 : Jose A Reyero Hey dtan, I'd say very good catch :-) , tested the patch and seems to be ok. Anyway, I think this bugfix needs to be posted to Drupal core. ------------------------------------------------------------------------ June 30, 2005 - 20:22 : mfb +1

1 0