August 2005 - Development - lists.drupal.org

[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

[drupal-devel] [feature] create system option to prevent users from changing the theme
by Bèr Kessels 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: Bèr Kessels Status: patch (code needs work) 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. Bèr Kessels 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?

1 0

[drupal-devel] [bug] No more floating node admin groups
by Bèr Kessels 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/26311 Post a follow up: http://drupal.org/project/comments/add/26311 Project: Drupal Version: 4.6.0 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/non_floating_node_admin.patch (835 bytes) For me -konqueror user- the floats on the "admin groups" of the node edit forms was always annoying. The textfields were inaccessible. But witth the collapsible parts they becme even moer annyoing: They now jump around on teh page when collapsed or folded out. This patch simply removes all the floats frolm these groups. I beleive theis looks and feels much better. It appears more stable on your page. It feels more like one expects: only a single row of collapses, instead of some odd row with columns. And last but not least: that part was amoungst the hardests to theme. I think this is a good moment to get rid of them. Oh, and it removes quite some code/cruft from drupal.css :) Bèr Kessels

5 14

[drupal-devel] [bug] PHP highlighting and break tag
by Uwe Hermann 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/13599 Post a follow up: http://drupal.org/project/comments/add/13599 Project: Drupal -Version: 4.5.0 +Version: cvs Component: node.module Category: bug reports Priority: normal -Assigned to: DocSavage +Assigned to: Uwe Hermann Reported by: chrisada Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/node_32.patch (1017 bytes) This is still a problem in HEAD. Attached patch (slightly modified version of the patch by DocSavage) fixes the bug. Please review / test. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Sun, 28 Nov 2004 17:02:42 +0000 : chrisada Using the PHP highlighting feature stops Drupa'ls break tag from working. No matter how long the post, or where the user manually put the break tag, the page will never break. The code tag does not suffer from this. ------------------------------------------------------------------------ Sat, 05 Feb 2005 17:16:55 +0000 : DocSavage Attachment: http://drupal.org/files/issues/node_25.patch (646 bytes) The current version of node.module, when crafting teasers without any helper teaser module, looks for the break tag and simply uses the entire body for a teaser if any php code is present. It does that to prevent breaking php code in the middle, but when php code is included for documentary purposes, this is unnecessary. This bug is most obvious when using the codefilter module, since php code is specifically used for documentation. This patch to node.module replaces the "if any php code then use body as teaser" with code that sets teaser break points to the beginning of the php block. It's assumed that there will be some comment before showing the code, which suffices for a teaser. ------------------------------------------------------------------------ Fri, 04 Mar 2005 18:50:57 +0000 : Steven Your patch does not comply to code standards (don't use tabs, don't add comments about who added it). Reclassifying under node.module / core.

1 0

[drupal-devel] [bug] Tabs disappear in user.module settings after saving a role
by Uwe Hermann 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/26641 Post a follow up: http://drupal.org/project/comments/add/26641 Project: Drupal -Version: 4.6.1 +Version: cvs Component: user.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: Sean Fuller Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user_30.patch (650 bytes) This is still a problem in HEAD. Here's a patch which should fix it. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 19:39:42 +0000 : Sean Fuller When you edit a user role at admin/access/roles, the local task tabs disappear after saving the edit. Very minor point, but I thought I would include it in the spirit of making drupal more client friendly/consistent. I think the user.module needs this line right around line 1557: drupal_goto('admin/access/roles');

1 0

[drupal-devel] [bug] fuzzy cache flushes cache too frequently
by Jeremy 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/29274 Post a follow up: http://drupal.org/project/comments/add/29274 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Jeremy(a)kerneltrap.org Reported by: Jeremy(a)kerneltrap.org Updated by: Jeremy(a)kerneltrap.org -Status: active +Status: patch (code needs review) Patch needs review. Jeremy(a)kerneltrap.org Previous comments: ------------------------------------------------------------------------ Sun, 21 Aug 2005 00:20:39 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/bootstrap.inc_7.patch (2.08 KB) The "fuzzy cache" mechanism is supposed to enforce a minimum time before the cache table is flushed. Logical errors in the fuzzy cache implementation are leading to the cache table being flushed more frequently. With this patch and the fuzzy cache enabled, when an event leads to cache_clear_all() being called: - the cache is invalidated for the current user (simulating the cache being cleared for that user) - a 5 minutes timer is started Once five minutes passes, the cache is finally cleared for all users. Thus, with this patch the cache should never be cleared more than once every five minutes. Testing needs to be done to determine if 5 minutes is a long enough delay. Optionally, this delay time could be made configurable.

1 0

[drupal-devel] nodeapi validate
by Karoly Negyesi 21 Aug '05

21 Aug '05

Hi! We call nodeapi validate in the following situations: a) We are about to create a node. This is the first time nodeapi called on the page, before 'form pre'. b) We have just submitted the form. The node exists in $_POST only. c) We are about to edit a node. This is the first time nodeapi called on the page, before 'form pre'. d) We have just submitted the form. The node exists in the database and there is some update in $_POST. I propose that a) and c) begone and b) and d) be distincted. Regards NK

1 0

[drupal-devel] [feature] support for path alias chains in drupal_get_path_alias.
by aws 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/21239 Project: Drupal Version: 4.6.0 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: aws Updated by: aws Status: patch Attachment: http://drupal.org/files/issues/includes_bootstrap.inc_0.patch (739 bytes) This is a small patch for function drupal_get_path_alias in bootstrap.inc. This allows a path to have a non-cyclic chain of aliases, and enables the path alias finder to walk up the chain to the top level alias. For example: taxonomy_menu/4/1/50 | topics/whats_new/events taxonomy/term/50 | taxonomy_menu/4/1/50 Now I can have all references to taxonomy/term/50 automatically point to the top-level alias, topics/whats_new/events. I am also posting a patch against Pathauto module which creates these multi-links automatically for categories when taxonomy_menu is present. (I will add followup with a link to that patch). Note that the inverse case (alias => path) is *not* necessary (in fact it would break the intention of this patch... --- There are several other ways to accomplish this; all of which are more involved. YMMV. I won't be insulted if this patch is rejected. :) An alternative solution would be to allow the destination column to accept non-unique entries. This would also require some sort of weighting otherwise the final resolution would be indefinate. A second alternative would be to have drupal generate taxonomy links in a more general manner, so that the taxonomy_menu module could change all the taxonomy links via the proper hooks. A *third* alternative would be to fix the menu system so that it does not require nested paths in the hiearchy, this way taxonomy_menu would not need to create its own paths. aws

3 4