- Development - lists.drupal.org

[drupal-devel] [bug] Update script should have clearer instructions when admin session is not in database copy
by willmoy 06 Apr '05

06 Apr '05

Issue status update for http://drupal.org/node/19941 Project: Drupal Version: cvs Component: other Category: bug reports Priority: normal Assigned to: willmoy Reported by: willmoy Updated by: willmoy Status: patch Attachment: http://drupal.org/files/issues/update.php_0.patch (1.75 KB) The following is from: http://civicspacelabs.org/home/node/9042 The documentation for error condition when the Admin 1 user was not logged into the database when it was backed up is inadequate. The documentation should read: With an editor find the update.php file on your system. It should be in the main CivicSpace directory that you installed all the files into. Change the line at the top of your update.php page and change what is between the quotes from $access_check = "TRUE"; to $access_check = "FALSE"; As soon as the script is done, you must change the update.php script back to it's original form to $access_check = "TRUE"; We should also explain that next time the user should back up the database with the Admin 1 user logged in to avoid this problem. The final text this patch inserts is: Access denied. You are not authorized to access this page. Please log in as the admin user (the first user you created). If you cannot log in, you will have to edit update.php to bypass this access check. To do this: 1. With a text editor find the update.php file on your system. It should be in the main Drupal directory that you installed all the files into. 2. There is a line near top of your update.php page that says $access_check = "TRUE"; Change it to $access_check = "FALSE"; 3. As soon as the script is done, you must change the update.php script back to it's original form to $access_check = "TRUE"; 4. To avoid having this problem in future, remember to log in to your website as the admin user (the user you first created) before you backup your database at the beginning of the update process. willmoy

3 5

[drupal-devel] [bug] Missing <div> container on HTML output
by killes 06 Apr '05

06 Apr '05

Issue status update for http://drupal.org/node/20079 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: budda Updated by: killes(a)www.drop.org -Status: active +Status: patch Attachment: http://drupal.org/files/issues/book_28.patch (558 bytes) Here's the patch. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ April 6, 2005 - 18:46 : budda Line 588 should be made to output the tree navigation within a container the same as the core navigation block - to keep consistent. new line 588: return '<div class="menu"><ul>'. $tree .'</ul></div>'; You are still able to format the book tree navigation different to the core navigation block as this tree is a child of css class 'book-block'.

1 0

[drupal-devel] Re: Help?
by Sheldon Rampton 06 Apr '05

06 Apr '05

Jim Riggs wrote: >The latest release date is based on when the branch was created, not >when something was last committed. I understand that. That's the problem. I want the current version of the module to be what people get when they click on the link that says "download latest release." Right now they're getting an old version. How do I fix that? --Sheldon

4 3

[drupal-devel] Re: [contributions(DRUPAL-4-5):sheldon]
by Sheldon Rampton 06 Apr '05

06 Apr '05

Goba wrote: >The FAQ and the contributors guide outlines the commands used to >checkout, commit, tag, etc. the files. The above confusions are the very >reason that the php.net projects suggest contributors TO NOT USE visual >CVS tools. They always mess up. All the time. Actually, the Drupal contributors guide advises Macintosh users TO use CVL as their CVS tool: http://drupal.org/node/2972 In fact, that's why I started using the damn thing in the first place. I WAS trying to follow the instructions in the contributor's guide. The contributors guide also advises Windows users to use TortoiseCVS as their front end: http://drupal.org/node/635 Dries wrote: >Does that mean all Drupal 4.5 releases are messed up now? Err. I don't know. When this happened, my CVL console spat out a bunch of messages that looked like errors or refusals. Just now I've tried spot-checking the releases page (drupal.org/project/releases) and all of the projects I've looked at show "latest release" dates from prior to my accident. (For that matter, even my interwiki project still shows a latest release date of December 31, 2004. I've tried several times to move the tags just on the interwiki project and can't get it to take.) It looks to me like either no real harm was done, or else someone caught it quickly and fixed it. However, I think it's clear that I'm far from expert in using CVS, so please don't take my word for anything. Based on my experience, I would recommend revising the contributor's guide so it doesn't advise Macintosh users to use CVL. Since I don't use Windows, I don't know whether continuing to recommend TortoiseCVS is a good idea, but if your goal is to ensure that contributors know what they're doing in CVS, I think it would be better to simply recommend using command-line access via a Unix terminal, and to provide a link to a good tutorial. --Sheldon

7 6

Re: [drupal-devel] Re: [contributions(DRUPAL-4-5):sheldon]
by Jeremy Epstein 06 Apr '05

06 Apr '05

On Apr 5, 2005 1:54 AM, Sheldon Rampton <sheldon(a)prwatch.org> wrote: > > Based on my experience, I would recommend revising the contributor's > guide so it doesn't advise Macintosh users to use CVL. Since I don't > use Windows, I don't know whether continuing to recommend TortoiseCVS > is a good idea, but if your goal is to ensure that contributors know > what they're doing in CVS, I think it would be better to simply > recommend using command-line access via a Unix terminal, and to > provide a link to a good tutorial. > I'm a full-time Windows user (and ashamed of it, as I should be), so I followed the advice in the Drupal handbook, and used TortoiseCVS to access the repository. The handbook has very clear advice on using TortoiseCVS to download and update the repositories to your local PC (this is the simplest thing you can do with CVS). So this is what I've been using TortoiseCVS for over the past month or so: logigng in anonymously, and just grabbing all the files that are available. When I got my CVS contrib account, I tried using TortoiseCVS to make my first commit. I was too scared to do it: the handbook has no advice on how to do this (except using CLI); and there are just so many menu options you can select, and it's quite frightening, knowing that pushing many of them could potentially stuff up other people's files. So my policy now is to use command-line CVS (through Cygwin) for commits, and to use GUI CVS only for refreshing my files (anonymously). I would advise all my fellow newbie-contributors to do the same thing: only make commits using command-line CVS! Especially since the handbook (to date) only has instructions for making commits using the command-line utility. Jaza.

5 5

[drupal-devel] [feature] common.inc Move textarea pre hook between title and textarea
by Dries 06 Apr '05

06 Apr '05

Issue status update for http://drupal.org/node/18828 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: Dries Status: patch Committed to HEAD. Thanks. Dries Previous comments: ------------------------------------------------------------------------ March 13, 2005 - 11:52 : jbond Attachment: http://drupal.org/files/issues/common.inc_10.patch (1.8 KB) This patch moves the textarea hook for 'pre' between the title and the textarea. This makes it easier for simply textarea enhancements like quicktags to add a toolbar just above the textarea. It doesn't appear to have any effect on the fckeditor or htmlarea modules. It doesn't introduce any new hooks. ------------------------------------------------------------------------ March 13, 2005 - 19:56 : killes(a)www.drop.org Guess that is a patch. ------------------------------------------------------------------------ March 14, 2005 - 15:38 : Bèr Kessels +1 From me. Any module that adds something, will want to add it after the title. I really cannot think of any case where aditional content should sit above the title, but I can think of loads of cases where content needs to sit between the title and textarea. ------------------------------------------------------------------------ March 15, 2005 - 01:20 : stefan nagtegaal Indeed, nice and simple patch! +1 from me either.. ------------------------------------------------------------------------ March 15, 2005 - 16:13 : jbond http://www.voidstar.com/node.php?id=2263 [1] If this patch gets accepted I'll drop this into contrib. It's similar to quicktags but *I* like it better. ;-) [1] http://www.voidstar.com/node.php?id=2263 ------------------------------------------------------------------------ March 29, 2005 - 12:09 : TDobes +1... I'm pretty sure the current positioning was accidental anyway... it was always meant to go directly above the textarea. ------------------------------------------------------------------------ March 29, 2005 - 16:33 : Bèr Kessels Dries, All people who use this, seem to agree. Any chance this gets in soon? Bèr ------------------------------------------------------------------------ March 29, 2005 - 18:23 : Dries Attachment: http://drupal.org/files/issues/textarea.patch (1.88 KB) Ber: while all people seem to agree, it is unclear how many people tested/reviewed this patch. One ought to be careful. For example, the patch introduces a new variable, $form_element, without properly initializing it ... How about the attached patch? It is slightly cleaner, slightly faster and properly initializes all variables. I haven't tested it with the WYSIWYG editors but maybe someone else (Julian?) can? Will commit after it has been tested. ------------------------------------------------------------------------ April 3, 2005 - 14:38 : Dries Anyone to test this? ------------------------------------------------------------------------ April 6, 2005 - 09:21 : TDobes Attachment: http://drupal.org/files/issues/textarea_updated.patch (1.97 KB) The patch no longer applied, so I updated it. I also tested it with: * Quicktags * TinyMCE * Areatags (mentioned earlier by jbond) It worked with all three... +1 for applying Dries' cleaner patch. jbond: Your module's browser detection code does not work on my server. You seem to expect a $HTTP_USER_AGENT global variable, which does not exist... I think you should instead be using $_SERVER['HTTP_USER_AGENT']. Perhaps your code was created with the assumption that "register_globals" is turned on in php.ini? That setting is off by default, so I wouldn't rely on it.

1 0

[drupal-devel] [feature] common.inc Move textarea pre hook between title and textarea
by TDobes 06 Apr '05

06 Apr '05

Issue status update for http://drupal.org/node/18828 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: TDobes Status: patch Attachment: http://drupal.org/files/issues/textarea_updated.patch (1.97 KB) The patch no longer applied, so I updated it. I also tested it with: * Quicktags * TinyMCE * Areatags (mentioned earlier by jbond) It worked with all three... +1 for applying Dries' cleaner patch. jbond: Your module's browser detection code does not work on my server. You seem to expect a $HTTP_USER_AGENT global variable, which does not exist... I think you should instead be using $_SERVER['HTTP_USER_AGENT']. Perhaps your code was created with the assumption that "register_globals" is turned on in php.ini? That setting is off by default, so I wouldn't rely on it. TDobes Previous comments: ------------------------------------------------------------------------ March 13, 2005 - 03:52 : jbond Attachment: http://drupal.org/files/issues/common.inc_10.patch (1.8 KB) This patch moves the textarea hook for 'pre' between the title and the textarea. This makes it easier for simply textarea enhancements like quicktags to add a toolbar just above the textarea. It doesn't appear to have any effect on the fckeditor or htmlarea modules. It doesn't introduce any new hooks. ------------------------------------------------------------------------ March 13, 2005 - 11:56 : killes(a)www.drop.org Guess that is a patch. ------------------------------------------------------------------------ March 14, 2005 - 07:38 : Bèr Kessels +1 From me. Any module that adds something, will want to add it after the title. I really cannot think of any case where aditional content should sit above the title, but I can think of loads of cases where content needs to sit between the title and textarea. ------------------------------------------------------------------------ March 14, 2005 - 17:20 : stefan nagtegaal Indeed, nice and simple patch! +1 from me either.. ------------------------------------------------------------------------ March 15, 2005 - 08:13 : jbond http://www.voidstar.com/node.php?id=2263 [1] If this patch gets accepted I'll drop this into contrib. It's similar to quicktags but *I* like it better. ;-) [1] http://www.voidstar.com/node.php?id=2263 ------------------------------------------------------------------------ March 29, 2005 - 04:09 : TDobes +1... I'm pretty sure the current positioning was accidental anyway... it was always meant to go directly above the textarea. ------------------------------------------------------------------------ March 29, 2005 - 08:33 : Bèr Kessels Dries, All people who use this, seem to agree. Any chance this gets in soon? Bèr ------------------------------------------------------------------------ March 29, 2005 - 10:23 : Dries Attachment: http://drupal.org/files/issues/textarea.patch (1.88 KB) Ber: while all people seem to agree, it is unclear how many people tested/reviewed this patch. One ought to be careful. For example, the patch introduces a new variable, $form_element, without properly initializing it ... How about the attached patch? It is slightly cleaner, slightly faster and properly initializes all variables. I haven't tested it with the WYSIWYG editors but maybe someone else (Julian?) can? Will commit after it has been tested. ------------------------------------------------------------------------ April 3, 2005 - 06:38 : Dries Anyone to test this?

1 0

[drupal-devel] [bug] Cannot delete users
by moshe weitzman 06 Apr '05

06 Apr '05

Issue status update for http://drupal.org/node/19750 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: AtomicMaestro Updated by: moshe weitzman Status: patch Attachment: http://drupal.org/files/issues/menu_set_location.patch (2.23 KB) here is a different patch suggested by UnConed. Uses menu_set_location() to remove the tabs on the delete confirmation page for both nodes and users. moshe weitzman Previous comments: ------------------------------------------------------------------------ March 31, 2005 - 04:33 : AtomicMaestro I can't seem to delete users. To reproduce: 1. Create a user. 2. View the user created in 1. 3. Click Delete I would expect to be told I have to block the user first, but instead, I'm sent back to the user report. There's no message, nothing in the log. ------------------------------------------------------------------------ April 1, 2005 - 02:40 : asimmonds Attachment: http://drupal.org/files/issues/fix_delete_user.patch (581 bytes) Patch attached to fix this, the delete code in node.module works the same way ------------------------------------------------------------------------ April 3, 2005 - 09:15 : moshe weitzman when one deletes a user from list of users in admin, he expects to return back to that list after successfully deleting. thats the intent of the $_REQUEST['destination']. I think this patch will defeat that behavior. There certainly is a bug here, but I don't think we have found the right fix yet. I suggest testing a delete from both admin and user/edit pages. make sure you arrive at the expected page after a successful delete. ------------------------------------------------------------------------ April 4, 2005 - 02:19 : asimmonds There are two methods to enter the user edit page as a admin: 1/ View a user, then select the edit tab. 2/ Click 'edit' for the user in the admin/user list. The 2nd method sets destination=admin/user in the URL, when the user edit page is shown. If the Delete button is clicked, it calls drupal_goto("user/$account->uid/delete") (the code's comment mentions this is done to make the tabs disappear). As destination is already set, drupal_goto() redirects to that ie. "admin/user" instead of "user/$account->uid/delete" If after successfully deleting a user, the code calls drupal_goto("admin/user"). I looked at how node.module does the node delete/confirm sequence and it has this unset($_REQUEST['destination']) in there as well. Maybe this delete/confirm sequence pattern needs a re-think for 4.7 ------------------------------------------------------------------------ April 5, 2005 - 23:01 : moshe weitzman Attachment: http://drupal.org/files/issues/user_15.patch (1020 bytes) here is an alternative. this one properly maintains the destination parameter which is useful especially when you are not on the 1st page of your user listing. the redirect insures that you return to the page you were on. another advantage is that i was able to delete a few lines of code which were performing a drupal_goto(). the downside is that the pupose of the drupal_goto() was to get rid of the tabs. I don't mind the tabs on the delete confirm page, so I think my patch is better, and removes a couple lines of code. either patch presented here would work ok.

1 0

[drupal-devel] [bug] Cannot delete users
by moshe weitzman 06 Apr '05

06 Apr '05

Issue status update for http://drupal.org/node/19750 Project: Drupal Version: cvs Component: user.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: AtomicMaestro Updated by: moshe weitzman Status: patch Attachment: http://drupal.org/files/issues/user_15.patch (1020 bytes) here is an alternative. this one properly maintains the destination parameter which is useful especially when you are not on the 1st page of your user listing. the redirect insures that you return to the page you were on. another advantage is that i was able to delete a few lines of code which were performing a drupal_goto(). the downside is that the pupose of the drupal_goto() was to get rid of the tabs. I don't mind the tabs on the delete confirm page, so I think my patch is better, and removes a couple lines of code. either patch presented here would work ok. moshe weitzman Previous comments: ------------------------------------------------------------------------ March 31, 2005 - 04:33 : AtomicMaestro I can't seem to delete users. To reproduce: 1. Create a user. 2. View the user created in 1. 3. Click Delete I would expect to be told I have to block the user first, but instead, I'm sent back to the user report. There's no message, nothing in the log. ------------------------------------------------------------------------ April 1, 2005 - 02:40 : asimmonds Attachment: http://drupal.org/files/issues/fix_delete_user.patch (581 bytes) Patch attached to fix this, the delete code in node.module works the same way ------------------------------------------------------------------------ April 3, 2005 - 09:15 : moshe weitzman when one deletes a user from list of users in admin, he expects to return back to that list after successfully deleting. thats the intent of the $_REQUEST['destination']. I think this patch will defeat that behavior. There certainly is a bug here, but I don't think we have found the right fix yet. I suggest testing a delete from both admin and user/edit pages. make sure you arrive at the expected page after a successful delete. ------------------------------------------------------------------------ April 4, 2005 - 02:19 : asimmonds There are two methods to enter the user edit page as a admin: 1/ View a user, then select the edit tab. 2/ Click 'edit' for the user in the admin/user list. The 2nd method sets destination=admin/user in the URL, when the user edit page is shown. If the Delete button is clicked, it calls drupal_goto("user/$account->uid/delete") (the code's comment mentions this is done to make the tabs disappear). As destination is already set, drupal_goto() redirects to that ie. "admin/user" instead of "user/$account->uid/delete" If after successfully deleting a user, the code calls drupal_goto("admin/user"). I looked at how node.module does the node delete/confirm sequence and it has this unset($_REQUEST['destination']) in there as well. Maybe this delete/confirm sequence pattern needs a re-think for 4.7

1 0

[drupal-devel] Re: [contributions:weitzman] /modules/firefox_counter firefox_counter.module
by Dries Buytaert 06 Apr '05

06 Apr '05

On 05 Apr 2005, at 04:02, drupal-cvs(a)drupal.org wrote: > User: weitzman Branch: HEAD Date: Tue, 5 Apr 2005 02:02:12 +0000 > > Modified files: > /modules/firefox_counter firefox_counter.module Is this module useful for non-SFX sites? If so, can we please use a generic module name? Or is this not the SFX counter module? -- Dries Buytaert :: http://www.buytaert.net/

3 3