- Development - lists.drupal.org

[drupal-devel] [task] list_themes() improvements
by drumm 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/29002 Post a follow up: http://drupal.org/project/comments/add/29002 Project: Drupal Version: cvs Component: theme system Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Attachment: http://drupal.org/files/issues/list_themes.patch (2.77 KB) list_themes() currently returns all themes, not just enabled themes. This functionality is only used in one place- configuration for disabled themes. These configuration pages can be removed with a usability improvement since you shouldn't be able to configure things which are disabled. Additionally, this allows us to remove some extra logic in system_user(). And it it more consistent with the module API which only lists enabled modules. list_themes() sorts the results by name. This uses filesort in MySQL since there aren't any indexes. Sorting is not used except in system_user(). This one use can be handled with ksort since it is not often executed (only on the user edit screen when multiple themes are enabled). And a one line fix to remove a variable in system_user() is in here too. drumm

4 4

[drupal-devel] [bug] Inaccurate Temp Directory Description
by Uwe Hermann 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/26778 Post a follow up: http://drupal.org/project/comments/add/26778 Project: Drupal -Version: 4.6.2 +Version: cvs Component: system.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Alex Reisner Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/tmp_path.patch (2.09 KB) Here's a patch for HEAD which fixes the documentation. Not sure whether the docs or the code should be fixed. Comments? Uwe Hermann Previous comments: ------------------------------------------------------------------------ Fri, 15 Jul 2005 16:18:44 +0000 : Alex Reisner On the admin/settings page the help text for the Temporary Directory field reads: "Location where uploaded files will be kept during previews. Relative paths will be resolved relative to the file system path." However, this does not seem to be the case. Just above the code which generates this message (system.module line 237) the temp directory is checked as relative to the site root. Similar interpretation is found in file_create_path($dest) (file.inc line 52): // check if the destination is instead inside the Drupal temporary files directory. else if (file_check_location($dest, variable_get('file_directory_temp', FILE_DIRECTORY_TEMP))) { return $dest; I believe the code in both places works as it should; the help text on this field should be revised to something like: "Location where uploaded files will be kept during previews. Relative paths are interpreted from the Drupal installation directory."

1 0

[drupal-devel] [feature] Taxonomy rewrite
by chx 21 Aug '05

21 Aug '05

Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/taxonomy_db_rewrite.patch (6.71 KB) I'd like to present a use for db_rewrite_sql: taxonomy rewrites. If this goes through, it will be possible to create an access mechanism, languages and whatever for taxonomy. This is a very small change, I think, much smaller than the node_rewrite_sql megpatch was 'cos at the moment nothing changes. There are no DISTINCTs deleted. But this opens a door for future things. Also, this only affects taxonomy.module, 'cos no other module deals with term_data and vocabulary tables (well, forum.module does, but those queries does not need a rewrite). chx -- View: http://drupal.org/node/16452 Edit: http://drupal.org/project/comments/add/16452

8 21

[drupal-devel] [bug] User should be redirected once logged in [SOLUTION-COREERROR]
by Tobias Maier 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/24587 Post a follow up: http://drupal.org/project/comments/add/24587 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: Tobias Maier Status: patch (code needs review) Attachment: http://drupal.org/files/issues/issue24587_2_common.inc.patch (1.46 KB) i dont like it too but this was the fastest way to do it :D here comes a new patch but this changes drupal_get_destination() a little bit cu tobias Tobias Maier Previous comments: ------------------------------------------------------------------------ Wed, 08 Jun 2005 17:39:26 +0000 : nysus When a user logs in after viewing the custom 403 page, the 403 page is still displayed. The user should instead see the page they were trying to request. ------------------------------------------------------------------------ Wed, 08 Jun 2005 18:23:30 +0000 : Dublin Drupaller as opposed to a patch..you could try this.... <?php // get referrer from _SERVER array $ref = $_SERVER["HTTP_REFERER"]; ?> and insert this into your form action line: form action="user/login?destination=$ref" method="post" The php script at the top catches the reffering url and assigns to to the $ref variable... I haven't tested the above, so it's only a suggestion...might be easier to implement that in your custom 403 page rather than wait for a patch. Dub ------------------------------------------------------------------------ Wed, 08 Jun 2005 20:27:32 +0000 : nysus Attachment: http://drupal.org/files/issues/customerror.patch (2.73 KB) Thanks, Dub. But I have a patch here. Give it a shot if you want. It's probably a little more convoluted than it needs to be but it appears to work. The good part about it is that you don't have to hack the core. The bad part about it is that I had to get rid of the $may_cache variable for it to work. The other quirk about it is that let's say you have user 1 and he gets a 403 error for trying to view admin/block without authorization. Then user 2 comes along and gets a 403 error for trying view admin/settings without authorization. Then when user 1 logs in, he will see admin/settings instead of admin/block (the page he was originally trying to view). This will only be a problem on busy sites. If you look at the code, you'll see that I drew heavily from some menu functions to determine if the user is now authorized to look at a page. Basically they way it works is this: If you get a 403 error, the module does a variable_set to see what path you were trying to access. When you login, the customerror module basically runs the same two functions as the menu module to see if the user has access. If so, the module does a redirect to the page by pulling the old path out with variable get. I'll leave it to a pro with better than ideas to polish this up. Hopefully this code has helped pave the way. ------------------------------------------------------------------------ Thu, 09 Jun 2005 02:03:22 +0000 : kbahey Thanks for the patch nysus. I don't mind removing the $maycache, but it may be a performance hit for some large sites. I think the patch as it exists, is overly overcomplicated. Too much code in there. The reason you were getting different users getting each other's path is that it is saved in the database. I was thinking of something along the lines of what Dub said. Check if the referrer is set, and then issue a drupal_goto(). Try to replace the customerror_page function with the version below, merged to the original module (not the nysus modified one). I did not test it though. <?php function customerror_page() { $error = arg(1); switch($error) { case 404: drupal_set_title(variable_get('customerror_'. $error .'_title', _customerror_fetch_error($error))); $body = variable_get('customerror_' . $error, _customerror_fetch_error($error)); case 403: // $referer = $_SERVER["HTTP_REFERER"]; if ($referer) { drupal_goto($referer); } break; default: drupal_set_title(t('undefined error: ') . $error); $body = _customerror_fetch_error($error); break; } print theme('page', $body); } ?> ------------------------------------------------------------------------ Thu, 09 Jun 2005 02:04:59 +0000 : kbahey Just realize that this may cause a redirection loop (403 -> original page -> 403 -> ...). Oh well. Someone may think of something better. ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:08:10 +0000 : nysus Yes, infinite redirects are a problem. I ran into it quite frequently while developing this solution. Like I said, there is probably a better way. I don't see any way around using the database, however. You need to be able to remember the initial page the user tried to come through. To avoid the problem I mentioned above of one user clobbering the other user's redirect is to use info in the user's cookie to give him a unique "redirect identifier." But then the database will get littered with redirect data. You would have to set up a cron to delete the old ones. I'll also try Dublin's idea at some point and see how it goes. ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:28:13 +0000 : kbahey The session ID is a good unique identifier. So, we could use the Session ID to identify the original page that we would redirect to. However, if we use variable_get() this means there will be one entry per session, and on a large site, this can be a) too big, and b) a significant overhead Unless we delete it from the table upon redirect, which solves a) but worsens b) (more db operations). Perhaps we can make this a config option. If the site is small, then this is a good option to turn on. If it is a large site, then the site admin should turn this off. ------------------------------------------------------------------------ Mon, 04 Jul 2005 14:52:37 +0000 : spiff06 +1 ------------------------------------------------------------------------ Mon, 04 Jul 2005 17:36:40 +0000 : kbahey Please do not change the title. It will make it difficult for others to find the issues. As for a solution, the patches provided seem to work, but they are overly complex. I am not going to apply them as is, unless a simpler and cleaner patch arise. ------------------------------------------------------------------------ Sun, 17 Jul 2005 02:14:04 +0000 : ymcp Has there been any progress on this? It may seem like a minor issue, but it is a real show-stopper for a site that I am trying to port to drupal. Users are not permitted to see any content without being logged in, so the custom 403 page serves very well as a "welcome, please log in" screen... but when they log in they still see the "please log in" message. They're going to find that very confusing. ------------------------------------------------------------------------ Sun, 17 Jul 2005 07:58:38 +0000 : kbahey As far as the solutions mentioned, they are too complex and not simple and clean. I am waiting for someone to put a better patch, since I am not working actively on this at the moment. ------------------------------------------------------------------------ Tue, 19 Jul 2005 07:22:25 +0000 : kbahey When this patch is in core, it could be the basis of a better solution. Maybe the previous patch to CustomError can be reworked in the future to use this. ------------------------------------------------------------------------ Thu, 21 Jul 2005 07:19:13 +0000 : kbahey Redirection is now in core. Check it here http://drupal.org/node/26467 Anyone cares for a patch based on that? ------------------------------------------------------------------------ Sun, 21 Aug 2005 12:40:15 +0000 : Tobias Maier I'm investigating this issue as far as I can say now it is _no_ error of customerror its an error of the user-login-block and a little bit of menu_set_active_item() (the form-destination is set to the URL of the error-page) maybe youll get a solution today. but this will affect the core. i dont want to change the Project/component by now. but if I have a solution cu tobias ------------------------------------------------------------------------ Sun, 21 Aug 2005 13:10:22 +0000 : Tobias Maier Attachment: http://drupal.org/files/issues/issue24587_common.inc.patch (612 bytes) I found a solution 1. As I mentioned this is no error of customerror! 2. this is a bug and no new feature witch should come (because it is done the right way if you are not using any other errorpage the patch adds the line $_REQUEST['destination'] = urldecode(substr(drupal_get_destination(),12)); to drupal_access_denied() --> the $_REQUEST['destination'] is now set before user_block() asks for destionation Ciao Tobias ------------------------------------------------------------------------ Sun, 21 Aug 2005 13:21:26 +0000 : kbahey Attachment: http://drupal.org/files/issues/issue24587_common.inc_0.patch (606 bytes) The patch is garbled (DOS editor?) Here is the same patch in a proper format so others can review it. What I do not like is the 12 in the substr. This kind of hard coded numbers has to be at least documented so it can be changed in the future if need be.

1 0

[drupal-devel] [bug] User should be redirected once logged in [SOLUTION-COREERROR]
by kbahey 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/24587 Post a follow up: http://drupal.org/project/comments/add/24587 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: kbahey Status: patch (code needs review) Attachment: http://drupal.org/files/issues/issue24587_common.inc_0.patch (606 bytes) The patch is garbled (DOS editor?) Here is the same patch in a proper format so others can review it. What I do not like is the 12 in the substr. This kind of hard coded numbers has to be at least documented so it can be changed in the future if need be. kbahey Previous comments: ------------------------------------------------------------------------ Wed, 08 Jun 2005 17:39:26 +0000 : nysus When a user logs in after viewing the custom 403 page, the 403 page is still displayed. The user should instead see the page they were trying to request. ------------------------------------------------------------------------ Wed, 08 Jun 2005 18:23:30 +0000 : Dublin Drupaller as opposed to a patch..you could try this.... <?php // get referrer from _SERVER array $ref = $_SERVER["HTTP_REFERER"]; ?> and insert this into your form action line: form action="user/login?destination=$ref" method="post" The php script at the top catches the reffering url and assigns to to the $ref variable... I haven't tested the above, so it's only a suggestion...might be easier to implement that in your custom 403 page rather than wait for a patch. Dub ------------------------------------------------------------------------ Wed, 08 Jun 2005 20:27:32 +0000 : nysus Attachment: http://drupal.org/files/issues/customerror.patch (2.73 KB) Thanks, Dub. But I have a patch here. Give it a shot if you want. It's probably a little more convoluted than it needs to be but it appears to work. The good part about it is that you don't have to hack the core. The bad part about it is that I had to get rid of the $may_cache variable for it to work. The other quirk about it is that let's say you have user 1 and he gets a 403 error for trying to view admin/block without authorization. Then user 2 comes along and gets a 403 error for trying view admin/settings without authorization. Then when user 1 logs in, he will see admin/settings instead of admin/block (the page he was originally trying to view). This will only be a problem on busy sites. If you look at the code, you'll see that I drew heavily from some menu functions to determine if the user is now authorized to look at a page. Basically they way it works is this: If you get a 403 error, the module does a variable_set to see what path you were trying to access. When you login, the customerror module basically runs the same two functions as the menu module to see if the user has access. If so, the module does a redirect to the page by pulling the old path out with variable get. I'll leave it to a pro with better than ideas to polish this up. Hopefully this code has helped pave the way. ------------------------------------------------------------------------ Thu, 09 Jun 2005 02:03:22 +0000 : kbahey Thanks for the patch nysus. I don't mind removing the $maycache, but it may be a performance hit for some large sites. I think the patch as it exists, is overly overcomplicated. Too much code in there. The reason you were getting different users getting each other's path is that it is saved in the database. I was thinking of something along the lines of what Dub said. Check if the referrer is set, and then issue a drupal_goto(). Try to replace the customerror_page function with the version below, merged to the original module (not the nysus modified one). I did not test it though. <?php function customerror_page() { $error = arg(1); switch($error) { case 404: drupal_set_title(variable_get('customerror_'. $error .'_title', _customerror_fetch_error($error))); $body = variable_get('customerror_' . $error, _customerror_fetch_error($error)); case 403: // $referer = $_SERVER["HTTP_REFERER"]; if ($referer) { drupal_goto($referer); } break; default: drupal_set_title(t('undefined error: ') . $error); $body = _customerror_fetch_error($error); break; } print theme('page', $body); } ?> ------------------------------------------------------------------------ Thu, 09 Jun 2005 02:04:59 +0000 : kbahey Just realize that this may cause a redirection loop (403 -> original page -> 403 -> ...). Oh well. Someone may think of something better. ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:08:10 +0000 : nysus Yes, infinite redirects are a problem. I ran into it quite frequently while developing this solution. Like I said, there is probably a better way. I don't see any way around using the database, however. You need to be able to remember the initial page the user tried to come through. To avoid the problem I mentioned above of one user clobbering the other user's redirect is to use info in the user's cookie to give him a unique "redirect identifier." But then the database will get littered with redirect data. You would have to set up a cron to delete the old ones. I'll also try Dublin's idea at some point and see how it goes. ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:28:13 +0000 : kbahey The session ID is a good unique identifier. So, we could use the Session ID to identify the original page that we would redirect to. However, if we use variable_get() this means there will be one entry per session, and on a large site, this can be a) too big, and b) a significant overhead Unless we delete it from the table upon redirect, which solves a) but worsens b) (more db operations). Perhaps we can make this a config option. If the site is small, then this is a good option to turn on. If it is a large site, then the site admin should turn this off. ------------------------------------------------------------------------ Mon, 04 Jul 2005 14:52:37 +0000 : spiff06 +1 ------------------------------------------------------------------------ Mon, 04 Jul 2005 17:36:40 +0000 : kbahey Please do not change the title. It will make it difficult for others to find the issues. As for a solution, the patches provided seem to work, but they are overly complex. I am not going to apply them as is, unless a simpler and cleaner patch arise. ------------------------------------------------------------------------ Sun, 17 Jul 2005 02:14:04 +0000 : ymcp Has there been any progress on this? It may seem like a minor issue, but it is a real show-stopper for a site that I am trying to port to drupal. Users are not permitted to see any content without being logged in, so the custom 403 page serves very well as a "welcome, please log in" screen... but when they log in they still see the "please log in" message. They're going to find that very confusing. ------------------------------------------------------------------------ Sun, 17 Jul 2005 07:58:38 +0000 : kbahey As far as the solutions mentioned, they are too complex and not simple and clean. I am waiting for someone to put a better patch, since I am not working actively on this at the moment. ------------------------------------------------------------------------ Tue, 19 Jul 2005 07:22:25 +0000 : kbahey When this patch is in core, it could be the basis of a better solution. Maybe the previous patch to CustomError can be reworked in the future to use this. ------------------------------------------------------------------------ Thu, 21 Jul 2005 07:19:13 +0000 : kbahey Redirection is now in core. Check it here http://drupal.org/node/26467 Anyone cares for a patch based on that? ------------------------------------------------------------------------ Sun, 21 Aug 2005 12:40:15 +0000 : Tobias Maier I'm investigating this issue as far as I can say now it is _no_ error of customerror its an error of the user-login-block and a little bit of menu_set_active_item() (the form-destination is set to the URL of the error-page) maybe youll get a solution today. but this will affect the core. i dont want to change the Project/component by now. but if I have a solution cu tobias ------------------------------------------------------------------------ Sun, 21 Aug 2005 13:10:22 +0000 : Tobias Maier Attachment: http://drupal.org/files/issues/issue24587_common.inc.patch (612 bytes) I found a solution 1. As I mentioned this is no error of customerror! 2. this is a bug and no new feature witch should come (because it is done the right way if you are not using any other errorpage the patch adds the line $_REQUEST['destination'] = urldecode(substr(drupal_get_destination(),12)); to drupal_access_denied() --> the $_REQUEST['destination'] is now set before user_block() asks for destionation Ciao Tobias

1 0

[drupal-devel] [bug] User should be redirected once logged in [SOLUTION-COREERROR]
by Tobias Maier 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/24587 Post a follow up: http://drupal.org/project/comments/add/24587 -Project: CustomError +Project: Drupal -Version: 4.6.0 +Version: cvs -Component: User interface +Component: base system -Category: feature requests +Category: bug reports Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: Tobias Maier -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/issue24587_common.inc.patch (612 bytes) I found a solution 1. As I mentioned this is no error of customerror! 2. this is a bug and no new feature witch should come (because it is done the right way if you are not using any other errorpage the patch adds the line $_REQUEST['destination'] = urldecode(substr(drupal_get_destination(),12)); to drupal_access_denied() --> the $_REQUEST['destination'] is now set before user_block() asks for destionation Ciao Tobias Tobias Maier Previous comments: ------------------------------------------------------------------------ Wed, 08 Jun 2005 17:39:26 +0000 : nysus When a user logs in after viewing the custom 403 page, the 403 page is still displayed. The user should instead see the page they were trying to request. ------------------------------------------------------------------------ Wed, 08 Jun 2005 18:23:30 +0000 : Dublin Drupaller as opposed to a patch..you could try this.... <?php // get referrer from _SERVER array $ref = $_SERVER["HTTP_REFERER"]; ?> and insert this into your form action line: form action="user/login?destination=$ref" method="post" The php script at the top catches the reffering url and assigns to to the $ref variable... I haven't tested the above, so it's only a suggestion...might be easier to implement that in your custom 403 page rather than wait for a patch. Dub ------------------------------------------------------------------------ Wed, 08 Jun 2005 20:27:32 +0000 : nysus Attachment: http://drupal.org/files/issues/customerror.patch (2.73 KB) Thanks, Dub. But I have a patch here. Give it a shot if you want. It's probably a little more convoluted than it needs to be but it appears to work. The good part about it is that you don't have to hack the core. The bad part about it is that I had to get rid of the $may_cache variable for it to work. The other quirk about it is that let's say you have user 1 and he gets a 403 error for trying to view admin/block without authorization. Then user 2 comes along and gets a 403 error for trying view admin/settings without authorization. Then when user 1 logs in, he will see admin/settings instead of admin/block (the page he was originally trying to view). This will only be a problem on busy sites. If you look at the code, you'll see that I drew heavily from some menu functions to determine if the user is now authorized to look at a page. Basically they way it works is this: If you get a 403 error, the module does a variable_set to see what path you were trying to access. When you login, the customerror module basically runs the same two functions as the menu module to see if the user has access. If so, the module does a redirect to the page by pulling the old path out with variable get. I'll leave it to a pro with better than ideas to polish this up. Hopefully this code has helped pave the way. ------------------------------------------------------------------------ Thu, 09 Jun 2005 02:03:22 +0000 : kbahey Thanks for the patch nysus. I don't mind removing the $maycache, but it may be a performance hit for some large sites. I think the patch as it exists, is overly overcomplicated. Too much code in there. The reason you were getting different users getting each other's path is that it is saved in the database. I was thinking of something along the lines of what Dub said. Check if the referrer is set, and then issue a drupal_goto(). Try to replace the customerror_page function with the version below, merged to the original module (not the nysus modified one). I did not test it though. <?php function customerror_page() { $error = arg(1); switch($error) { case 404: drupal_set_title(variable_get('customerror_'. $error .'_title', _customerror_fetch_error($error))); $body = variable_get('customerror_' . $error, _customerror_fetch_error($error)); case 403: // $referer = $_SERVER["HTTP_REFERER"]; if ($referer) { drupal_goto($referer); } break; default: drupal_set_title(t('undefined error: ') . $error); $body = _customerror_fetch_error($error); break; } print theme('page', $body); } ?> ------------------------------------------------------------------------ Thu, 09 Jun 2005 02:04:59 +0000 : kbahey Just realize that this may cause a redirection loop (403 -> original page -> 403 -> ...). Oh well. Someone may think of something better. ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:08:10 +0000 : nysus Yes, infinite redirects are a problem. I ran into it quite frequently while developing this solution. Like I said, there is probably a better way. I don't see any way around using the database, however. You need to be able to remember the initial page the user tried to come through. To avoid the problem I mentioned above of one user clobbering the other user's redirect is to use info in the user's cookie to give him a unique "redirect identifier." But then the database will get littered with redirect data. You would have to set up a cron to delete the old ones. I'll also try Dublin's idea at some point and see how it goes. ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:28:13 +0000 : kbahey The session ID is a good unique identifier. So, we could use the Session ID to identify the original page that we would redirect to. However, if we use variable_get() this means there will be one entry per session, and on a large site, this can be a) too big, and b) a significant overhead Unless we delete it from the table upon redirect, which solves a) but worsens b) (more db operations). Perhaps we can make this a config option. If the site is small, then this is a good option to turn on. If it is a large site, then the site admin should turn this off. ------------------------------------------------------------------------ Mon, 04 Jul 2005 14:52:37 +0000 : spiff06 +1 ------------------------------------------------------------------------ Mon, 04 Jul 2005 17:36:40 +0000 : kbahey Please do not change the title. It will make it difficult for others to find the issues. As for a solution, the patches provided seem to work, but they are overly complex. I am not going to apply them as is, unless a simpler and cleaner patch arise. ------------------------------------------------------------------------ Sun, 17 Jul 2005 02:14:04 +0000 : ymcp Has there been any progress on this? It may seem like a minor issue, but it is a real show-stopper for a site that I am trying to port to drupal. Users are not permitted to see any content without being logged in, so the custom 403 page serves very well as a "welcome, please log in" screen... but when they log in they still see the "please log in" message. They're going to find that very confusing. ------------------------------------------------------------------------ Sun, 17 Jul 2005 07:58:38 +0000 : kbahey As far as the solutions mentioned, they are too complex and not simple and clean. I am waiting for someone to put a better patch, since I am not working actively on this at the moment. ------------------------------------------------------------------------ Tue, 19 Jul 2005 07:22:25 +0000 : kbahey When this patch is in core, it could be the basis of a better solution. Maybe the previous patch to CustomError can be reworked in the future to use this. ------------------------------------------------------------------------ Thu, 21 Jul 2005 07:19:13 +0000 : kbahey Redirection is now in core. Check it here http://drupal.org/node/26467 Anyone cares for a patch based on that? ------------------------------------------------------------------------ Sun, 21 Aug 2005 12:40:15 +0000 : Tobias Maier I'm investigating this issue as far as I can say now it is _no_ error of customerror its an error of the user-login-block and a little bit of menu_set_active_item() (the form-destination is set to the URL of the error-page) maybe youll get a solution today. but this will affect the core. i dont want to change the Project/component by now. but if I have a solution cu tobias

1 0

[drupal-devel] [bug] node.module can be disabled; but the server breaks if this happens
by Uwe Hermann 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/28827 Post a follow up: http://drupal.org/project/comments/add/28827 Project: Drupal -Version: 4.6.0 +Version: cvs Component: node.module Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: Uwe Hermann Reported by: merlinofchaos Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/system_7.patch (661 bytes) I'd say merlinofchaos is right. Here's a patch. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Sat, 13 Aug 2005 22:53:41 +0000 : merlinofchaos node.module is a critical module, because everything is based on nodes. I'd even consider saying that the module is really part of the very core of what makes Drupal Drupal -- since without nodes, there is very little content. This module can be disabled in the modules. But a LOT of modules use node_ functions -- such as node_load() -- without checking to see if the module is active. If one of these modules is enabled, and node.module is disabled, all pages will stop on a PHP error. I think the node module should be set to required.

1 0

[drupal-devel] [bug] Can't delete users
by Uwe Hermann 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/27651 Post a follow up: http://drupal.org/project/comments/add/27651 Project: Drupal Version: cvs Component: user.module Category: bug reports -Priority: normal +Priority: critical Assigned to: Anonymous Reported by: wiz Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user_delete_1.patch (587 bytes) I can confirm this bug. It's critical IMHO. The patch seems broken, so here's a rerolled one for HEAD which works for me. Please test. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Thu, 28 Jul 2005 01:58:08 +0000 : wiz Attachment: http://drupal.org/files/issues/user_delete.path (447 bytes) During testing of current CVS code I noted that trying to delete a user has no effect. Whether it is a good idea to delete users is another question (see http://drupal.org/node/19055) in modules/user.module:user_edit(), when the admin clicks on the "Delete" button at the end of a user's page, this happens: drupal_goto("user/$account->uid/delete"); Unfortunately, at least in my situation, the GET variable "destination" was set to "admin/user", so what drupal_goto() does is use this address rather than the parameter it receives. The net effect is that when you click Delete you end up on the user admin page again. The obvious fix seems to unset() the destination, see enclosed patch. ------------------------------------------------------------------------ Mon, 01 Aug 2005 22:25:42 +0000 : Tobias Maier saw the same problem please fix it Thanks

1 0

[drupal-devel] [feature] create system option to prevent users from changing the theme
by TDobes 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/26302 Post a follow up: http://drupal.org/project/comments/add/26302 Project: Drupal Version: 4.6.0 Component: system.module Category: feature requests Priority: normal Assigned to: Torenware Reported by: Torenware Updated by: TDobes Status: patch (code needs work) In response to Bèr: "* Does anyone actually allow his users to choose his or her theme in the profile? I have never come across a drupal site that does this. Never! " Well, I use the feature. In fact, it was the reason I got interested in the Drupal theming system to begin with. I was extremely frustrated by users' inability to switch between chameleon styles and xtemplate templates in Drupal prior the the last major theming patch. However, I tend to agree with you that this feature could be removed from core. This sort of functionality could be added to the user profile page by a contrib module and implemented by using the $custom_theme variable. TDobes Previous comments: ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:50:45 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option.diff (1.86 KB) >From the forum thread How To Prevent Users From Changing The Theme. I asked: " I'm working on a module that uses organic groups. I want to allow different groups to choose different themes, but I don't want individual users to have that capability. I'm assuming that this is easy to do, but I can't find a setting. Can anybody point me in the right direction? Thanks, Rob " At sepeck's suggestion, I'm submitting a patch to do this. It's against 4.6.0, and modifies theme.inc and system.module. It creates a variable 'configurable_user_themes' which defaults to "enabled" (4.6.0's current behavior), and if activated, makes system.module remove the UI for selected a theme, and also causes theme.inc to ignore any setting for $user->theme if it exists. ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:54:40 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option_0.diff (1.86 KB) Didn't set this to "patch" initially, so I'm including the patch again. Not sure what the procedure is just yet. ------------------------------------------------------------------------ Mon, 04 Jul 2005 05:07:44 +0000 : TDobes -1 -- sorry, but I feel that we should use a different method for this sort of thing. Any theme that is checked in the admin-> themes screen should be selectable by users. Modules should get their list of available themes from list_themes(), which provides a list of all available themes, not just those that are selected for use by users. ------------------------------------------------------------------------ Mon, 04 Jul 2005 09:21:57 +0000 : Bèr Kessels I think we should simply rename the "enabled" into "selecatble". Or any better term. For the only thing tha checkbox does is enable it for users to select. It does not enable or disable the theme at all. ------------------------------------------------------------------------ Mon, 04 Jul 2005 18:56:53 +0000 : Torenware A couple of comments: To TDobbs: for most applications, you're right. But for some applications where it's important to the site that user experience is well tested, letting individual users set the theme is something of a nightmare; a problem with the theme is perceived as a problem with the site. So for /those/ sites (such as the one I'm currently working on), letting the user set the theme was APITA. Still, for a community site, I agree that the current behavior is fine. So I made the current behavior the default. To Bèr Kessels: Let me see if I understand what you mean. Currently, I've coded the UI to say in its English default: User theme settings Configurable Themes: * Disabled * Enabled Enable or disable user-configurable themes. When enabled, users can set their own theme to override the site's default theme. Would you prefer: User theme settings Selectable Themes: * Disabled * Enabled Enable or disable user-selectable themes. When enabled, users can select their own theme to override the site's default theme. I don't really want to lose the "Disable"/"Enable" part, because if you look at the current UI in 4.6, all similar settings are done that way. So using a checkbox would be inconsistent with the rest of the page. How's that? Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 21:31:14 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/theme.png (17.19 KB) you indeed misunderstood me. We have a "enable theme" checkbox in the theme overview. That checkbos *does not enable anything* it only gives users the opportunity to select that theme. Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox. Ber ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:20:55 +0000 : Torenware Ber, I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me. The problem with your solution is that if a theme is deactivated, it is not available for anyone. I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:28:27 +0000 : Torenware Ber, /Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox./ I'm not following you. Could you please explain a bit more? Thanks, Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:37:13 +0000 : TDobes /I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me./ Sure it is! Deactivating themes in admin->theme removes them *ONLY* from the list of themes available for users to select. It should not remove them from the list of available themes for modules to use (via. the $custom_theme variable). If themes are disappearing from the modules' lists, these are bugs in the modules and should be reported elsewhere. I was under the impression that you were writing your own module, which is why I suggested you use the list_themes function. This function returns all available themes, not just those that are selected in admin->themes. Ber has mentioned that the term "enabled" is poorly chosen and should be replaced with something else, such as "user-selectable". I agree with him. /The problem with your solution is that if a theme is deactivated, it is not available for anyone./ This is completely false. It is not available to be chosen in the "my account" screen, but it is still very readily available for use by modules through the $custom_theme variable. /I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that./ Yes they do. How are you determining the list of available themes in your module? If the themes are disappearing when you deselect them from admin->themes, then your module is working improperly. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:59:25 +0000 : Torenware OK, if I'm understanding you, then indeed the UI in admin/themes is bad done enough to fool a native English speaker. What y'all from Europe make of some of the terms, I can't even guess :-) I'll see if the UI disappears if all of the items are "deactivated" makes the UI go away (and doesn't break Organic Groups...). But it sounds like the real "bug" is in the documentation. This string: / Select which themes are available to your users and specify the default theme. To configure site-wide display settings, click the "configure" task above. Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme. / needs changing. Perhaps something like "Choose a default theme for your site, and select which themes your users can choose to override the default." For the record: I do not have a clue what "Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme.". If someone will tell me what that means, maybe some of us can translate it into English :-) Then someone can translate it into whatever else we need to support. ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:22:53 +0000 : TDobes Please see the patch I've attached to this issue [1], which renames "enabled" to "user-selectable"... this should hopefully clear up a lot of confusion. [1] http://drupal.org/node/29002 ------------------------------------------------------------------------ Sat, 20 Aug 2005 07:52:28 +0000 : robertDouglass I'd like to propose a different solution; create a "can select own theme" permission for users. I agree that there are cases where some people should be able to choose their theme and others shouldn't. Personally, I don't make many sites where you get to "skin" the site just for fun. More likely, I use theme selection for development purposes (I develop the next version of a site's theme and can switch back and forth, and so can the developer, but nobody else). If we had a permission that could be given to roles, then og group administrators could be given this permission, if I'm not mistaken. Would this fit the bill, Torenware? ------------------------------------------------------------------------ Sat, 20 Aug 2005 17:30:29 +0000 : Bèr Kessels personally I am all for removing that option alltogether. "for development reasons" is simply not a reason to leave this in. What about getting rid of this "let users select their alternative theme". And focus more on sections/themeswitchers ? ------------------------------------------------------------------------ Sat, 20 Aug 2005 18:52:03 +0000 : robertDouglass I'm not for removing it. There are a lot of efforts going forward to do things like theme an individual's blog differently (blog_theme module, I think), and this is very interesting, especially if combined with some form of theme editor. The best interface we have for choosing themes is part of the user edit page. Let's not get rid of it. What's wrong with an permission to allow users to choose their own theme? ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:56:32 +0000 : Bèr Kessels There is nothnig wrong witha permission. But with the options in your profile. * Does anyone actually allow his users to choose his or her theme in the profile? I have never come across a drupal site that does this. Never! * As you state, there are loads of much better uses of personal themes, like letting a user choose a theme for his blog. Or a print theme, or a theme for better visibility. Or even a theme special for bots. sections, admin themes, etc. None of these cases benefit from the in-profile theme choice. I think this is some odd *nuke ripoff feature, that is only there, because no-one took the time to remove it. Really, have you ever seen this being used on a site? So to conclude: IMO the in-profile theme choice should go. We should focus on writing or improving modules that do advanced themeswitching. ------------------------------------------------------------------------ Sun, 21 Aug 2005 09:07:02 +0000 : robertDouglass Ok, I agree that the in-profile theme changing stuff is cruft. Better would be a module that lets users do this. It could even show up in the same place, but at least it wouldn't be in core.

1 0

[drupal-devel] [feature] create system option to prevent users from changing the theme
by robertDouglass 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/26302 Post a follow up: http://drupal.org/project/comments/add/26302 Project: Drupal Version: 4.6.0 Component: system.module Category: feature requests Priority: normal Assigned to: Torenware Reported by: Torenware Updated by: robertDouglass Status: patch (code needs work) Ok, I agree that the in-profile theme changing stuff is cruft. Better would be a module that lets users do this. It could even show up in the same place, but at least it wouldn't be in core. robertDouglass Previous comments: ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:50:45 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option.diff (1.86 KB) >From the forum thread How To Prevent Users From Changing The Theme. I asked: " I'm working on a module that uses organic groups. I want to allow different groups to choose different themes, but I don't want individual users to have that capability. I'm assuming that this is easy to do, but I can't find a setting. Can anybody point me in the right direction? Thanks, Rob " At sepeck's suggestion, I'm submitting a patch to do this. It's against 4.6.0, and modifies theme.inc and system.module. It creates a variable 'configurable_user_themes' which defaults to "enabled" (4.6.0's current behavior), and if activated, makes system.module remove the UI for selected a theme, and also causes theme.inc to ignore any setting for $user->theme if it exists. ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:54:40 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option_0.diff (1.86 KB) Didn't set this to "patch" initially, so I'm including the patch again. Not sure what the procedure is just yet. ------------------------------------------------------------------------ Mon, 04 Jul 2005 05:07:44 +0000 : TDobes -1 -- sorry, but I feel that we should use a different method for this sort of thing. Any theme that is checked in the admin-> themes screen should be selectable by users. Modules should get their list of available themes from list_themes(), which provides a list of all available themes, not just those that are selected for use by users. ------------------------------------------------------------------------ Mon, 04 Jul 2005 09:21:57 +0000 : Bèr Kessels I think we should simply rename the "enabled" into "selecatble". Or any better term. For the only thing tha checkbox does is enable it for users to select. It does not enable or disable the theme at all. ------------------------------------------------------------------------ Mon, 04 Jul 2005 18:56:53 +0000 : Torenware A couple of comments: To TDobbs: for most applications, you're right. But for some applications where it's important to the site that user experience is well tested, letting individual users set the theme is something of a nightmare; a problem with the theme is perceived as a problem with the site. So for /those/ sites (such as the one I'm currently working on), letting the user set the theme was APITA. Still, for a community site, I agree that the current behavior is fine. So I made the current behavior the default. To Bèr Kessels: Let me see if I understand what you mean. Currently, I've coded the UI to say in its English default: User theme settings Configurable Themes: * Disabled * Enabled Enable or disable user-configurable themes. When enabled, users can set their own theme to override the site's default theme. Would you prefer: User theme settings Selectable Themes: * Disabled * Enabled Enable or disable user-selectable themes. When enabled, users can select their own theme to override the site's default theme. I don't really want to lose the "Disable"/"Enable" part, because if you look at the current UI in 4.6, all similar settings are done that way. So using a checkbox would be inconsistent with the rest of the page. How's that? Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 21:31:14 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/theme.png (17.19 KB) you indeed misunderstood me. We have a "enable theme" checkbox in the theme overview. That checkbos *does not enable anything* it only gives users the opportunity to select that theme. Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox. Ber ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:20:55 +0000 : Torenware Ber, I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me. The problem with your solution is that if a theme is deactivated, it is not available for anyone. I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:28:27 +0000 : Torenware Ber, /Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox./ I'm not following you. Could you please explain a bit more? Thanks, Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:37:13 +0000 : TDobes /I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me./ Sure it is! Deactivating themes in admin->theme removes them *ONLY* from the list of themes available for users to select. It should not remove them from the list of available themes for modules to use (via. the $custom_theme variable). If themes are disappearing from the modules' lists, these are bugs in the modules and should be reported elsewhere. I was under the impression that you were writing your own module, which is why I suggested you use the list_themes function. This function returns all available themes, not just those that are selected in admin->themes. Ber has mentioned that the term "enabled" is poorly chosen and should be replaced with something else, such as "user-selectable". I agree with him. /The problem with your solution is that if a theme is deactivated, it is not available for anyone./ This is completely false. It is not available to be chosen in the "my account" screen, but it is still very readily available for use by modules through the $custom_theme variable. /I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that./ Yes they do. How are you determining the list of available themes in your module? If the themes are disappearing when you deselect them from admin->themes, then your module is working improperly. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:59:25 +0000 : Torenware OK, if I'm understanding you, then indeed the UI in admin/themes is bad done enough to fool a native English speaker. What y'all from Europe make of some of the terms, I can't even guess :-) I'll see if the UI disappears if all of the items are "deactivated" makes the UI go away (and doesn't break Organic Groups...). But it sounds like the real "bug" is in the documentation. This string: / Select which themes are available to your users and specify the default theme. To configure site-wide display settings, click the "configure" task above. Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme. / needs changing. Perhaps something like "Choose a default theme for your site, and select which themes your users can choose to override the default." For the record: I do not have a clue what "Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme.". If someone will tell me what that means, maybe some of us can translate it into English :-) Then someone can translate it into whatever else we need to support. ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:22:53 +0000 : TDobes Please see the patch I've attached to this issue [1], which renames "enabled" to "user-selectable"... this should hopefully clear up a lot of confusion. [1] http://drupal.org/node/29002 ------------------------------------------------------------------------ Sat, 20 Aug 2005 07:52:28 +0000 : robertDouglass I'd like to propose a different solution; create a "can select own theme" permission for users. I agree that there are cases where some people should be able to choose their theme and others shouldn't. Personally, I don't make many sites where you get to "skin" the site just for fun. More likely, I use theme selection for development purposes (I develop the next version of a site's theme and can switch back and forth, and so can the developer, but nobody else). If we had a permission that could be given to roles, then og group administrators could be given this permission, if I'm not mistaken. Would this fit the bill, Torenware? ------------------------------------------------------------------------ Sat, 20 Aug 2005 17:30:29 +0000 : Bèr Kessels personally I am all for removing that option alltogether. "for development reasons" is simply not a reason to leave this in. What about getting rid of this "let users select their alternative theme". And focus more on sections/themeswitchers ? ------------------------------------------------------------------------ Sat, 20 Aug 2005 18:52:03 +0000 : robertDouglass I'm not for removing it. There are a lot of efforts going forward to do things like theme an individual's blog differently (blog_theme module, I think), and this is very interesting, especially if combined with some form of theme editor. The best interface we have for choosing themes is part of the user edit page. Let's not get rid of it. What's wrong with an permission to allow users to choose their own theme? ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:56:32 +0000 : Bèr Kessels There is nothnig wrong witha permission. But with the options in your profile. * Does anyone actually allow his users to choose his or her theme in the profile? I have never come across a drupal site that does this. Never! * As you state, there are loads of much better uses of personal themes, like letting a user choose a theme for his blog. Or a print theme, or a theme for better visibility. Or even a theme special for bots. sections, admin themes, etc. None of these cases benefit from the in-profile theme choice. I think this is some odd *nuke ripoff feature, that is only there, because no-one took the time to remove it. Really, have you ever seen this being used on a site? So to conclude: IMO the in-profile theme choice should go. We should focus on writing or improving modules that do advanced themeswitching.

1 0