- Development - lists.drupal.org

[drupal-devel] [feature] move user-selected themes out of core
by TDobes 22 Aug '05

22 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: cvs -Component: system.module +Component: theme system Category: feature requests Priority: normal -Assigned to: Torenware +Assigned to: TDobes Reported by: Torenware Updated by: TDobes -Status: patch (code needs work) +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/no_more_user_selectable_themes.patch (5.39 KB) I've attached a patch which removes the option for selecting themes from the _user hook and the special handling of $user->theme from init_theme. While I did consider removing the "enabled" field, I decided against it. When all themes are always enabled, the number of sub-tabs of "configure" can become unmanagable. drumm's recent usability improvement [1] to the theme admin involved hiding tabs for those themes which are not enabled. Additionally, contrib modules which manipulate $custom_theme should be obtaining their list of selections by using list_themes(). Therefore, they too would benefit by displaying only those themes which have been enabled by the site admin. For example, a site admin may wish to make only certain themes available to other site developers who have the ability to switch themes in certain sections of the site. [1] http://drupal.org/node/29002 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 [2], which renames "enabled" to "user-selectable"... this should hopefully clear up a lot of confusion. [2] 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. ------------------------------------------------------------------------ Sun, 21 Aug 2005 09:13:59 +0000 : TDobes 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. ------------------------------------------------------------------------ Sun, 21 Aug 2005 21:37:56 +0000 : Dries Agreed. Let's move this to a contributed module and let's tidy up the theme configuration page (unless I'm mistaken, the enabled-checkboxes could probably be removed?). ------------------------------------------------------------------------ Sun, 21 Aug 2005 21:43:23 +0000 : killes(a)www.drop.org Moving to cvs. I am delighted about this change. This "feature" annoyed me right from when I started to use Drupal...

1 0

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

22 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: patch (code needs review) Attachment: http://drupal.org/files/issues/cache_3.patch (7.15 KB) Based on a brief conversation with Dries, here is an updated version of this patch. Configuration is simplified by removing all references to "strict" and "loose" caches. Instead, the cache is either "disabled" or "enabled". Additionally, the site administrator can now configure the "minimum cache lifetime", the minimum amount of time cached data will remain cached. The patch updates the system.module and bootstrap.inc. 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. ------------------------------------------------------------------------ Sun, 21 Aug 2005 00:21:01 +0000 : Jeremy(a)kerneltrap.org Patch needs review. ------------------------------------------------------------------------ Sun, 21 Aug 2005 23:06:47 +0000 : chx Jeremy, I love this patch. Can't wait for Dries to install and test on drupal.org -- alas I can't test as I do not have a site with enough visitors...

1 0

[drupal-devel] [bug] wrong search indexing in some cases
by robertgarrigos 22 Aug '05

22 Aug '05

Issue status update for http://drupal.org/node/25923 Post a follow up: http://drupal.org/project/comments/add/25923 Project: Drupal Version: 4.5.5 Component: search.module Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: robertgarrigos Reported by: robertgarrigos Updated by: robertgarrigos -Status: active +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/search.module_0.patch (607 bytes) I enclose a patch for this. Please, forgive me if this is not the right way of doing. It's the first time I'm using cvs with my macosx. Also the first time I'm using diff to get a patch file, so take it as a simple "hello world" patch file, which should work and fix the problem anyway. robertgarrigos Previous comments: ------------------------------------------------------------------------ Tue, 28 Jun 2005 15:16:10 +0000 : robertgarrigos In some cases, search module doesn't index some words, for instance, when there are only tags between words. In that case they are indexed all together: This is part of a real node text in one of my web pages (in catalan): 1732/1735<br\><b>Instrumentació:</b> this got indexed like this in the search_index table: 17321735instrumentació 169 1 which means I couldn't get a search result over 'instrumentació' I fixed that by adding a white space into the code of search.moulde file: original file (lines 253-254): // Strip heaps of stuff out of it. $wordlist = preg_replace("'<[\/\!]*?[^<>]*?>'si", '', $wordlist); fixed file (lines 253-254): // Strip heaps of stuff out of it. $wordlist = preg_replace("'<[\/\!]*?[^<>]*?>'si", ' ', $wordlist); ------------------------------------------------------------------------ Wed, 29 Jun 2005 21:12:59 +0000 : benshell Have you tried this on 4.6.x? I read this issue because I'm also having search indexing problems, but this particular problem looks like it has been fixed on 4.6.1. On line 344 on the search.module, I'm reading this: // Strip off all ignored tags to speed up processing, but insert space before/after // them to keep word boundaries. $text = str_replace(array('<', '>'), array(' <', '> '), $text); $text = strip_tags($text, '<'. implode('><', array_keys($tags)) .'>'); ------------------------------------------------------------------------ Thu, 30 Jun 2005 06:02:29 +0000 : robertgarrigos No, I haven't. The web page I was having this problem is on a shared server running php 4, thus no way to get drupal 4.6 on it. ------------------------------------------------------------------------ Mon, 22 Aug 2005 00:08:03 +0000 : robertgarrigos This is not yet fixed with 4.5.5. Apparently there is no problem with 4.6.x versions.

1 0

[drupal-devel] [feature] Template file extension addition to base .htaccess
by Uwe Hermann 22 Aug '05

22 Aug '05

Issue status update for http://drupal.org/node/29344 Post a follow up: http://drupal.org/project/comments/add/29344 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tclineks Updated by: Uwe Hermann Status: patch (code needs review) See also http://drupal.org/node/28776 which adds more stuff to .htaccess. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Sun, 21 Aug 2005 23:26:37 +0000 : tclineks Attachment: http://drupal.org/files/issues/tpl_file_hiding.patch (439 bytes) Here's patch/proposal to add the .tpl file extension (used for smarty theme/module templates) to the list of those denied in the base .htaccess file. --- .htaccess 2005-08-22 18:22:14.799176000 +0000 +++ .htaccess_old 2005-08-22 18:22:48.287329600 +0000 @@ -3,7 +3,7 @@ # # Protect files and directories from prying eyes. -<Files ~ "(\.(inc|module|pl|sh|sql|theme|engine|xtmpl|tpl)|Entries|Repositories|Root|scripts|updates)$"> +<Files ~ "(\.(inc|module|pl|sh|sql|theme|engine|xtmpl)|Entries|Repositories|Root|scripts|updates)$"> Order deny,allow Deny from all </Files> ------------------------------------------------------------------------ Sun, 21 Aug 2005 23:28:12 +0000 : tclineks Attachment: http://drupal.org/files/issues/tpl_file_hiding_0.patch (439 bytes) Ahem... ------------------------------------------------------------------------ Sun, 21 Aug 2005 23:31:47 +0000 : killes(a)www.drop.org It's a patch.

1 0

[drupal-devel] [feature] Template file extension addition to base .htaccess
by killes 22 Aug '05

22 Aug '05

Issue status update for http://drupal.org/node/29344 Post a follow up: http://drupal.org/project/comments/add/29344 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tclineks Updated by: killes(a)www.drop.org -Status: active +Status: patch (code needs review) It's a patch. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Sun, 21 Aug 2005 23:26:37 +0000 : tclineks Attachment: http://drupal.org/files/issues/tpl_file_hiding.patch (439 bytes) Here's patch/proposal to add the .tpl file extension (used for smarty theme/module templates) to the list of those denied in the base .htaccess file. --- .htaccess 2005-08-22 18:22:14.799176000 +0000 +++ .htaccess_old 2005-08-22 18:22:48.287329600 +0000 @@ -3,7 +3,7 @@ # # Protect files and directories from prying eyes. -<Files ~ "(\.(inc|module|pl|sh|sql|theme|engine|xtmpl|tpl)|Entries|Repositories|Root|scripts|updates)$"> +<Files ~ "(\.(inc|module|pl|sh|sql|theme|engine|xtmpl)|Entries|Repositories|Root|scripts|updates)$"> Order deny,allow Deny from all </Files> ------------------------------------------------------------------------ Sun, 21 Aug 2005 23:28:12 +0000 : tclineks Attachment: http://drupal.org/files/issues/tpl_file_hiding_0.patch (439 bytes) Ahem...

1 0

[drupal-devel] [bug] fuzzy cache flushes cache too frequently
by chx 22 Aug '05

22 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: chx Status: patch (code needs review) Jeremy, I love this patch. Can't wait for Dries to install and test on drupal.org -- alas I can't test as I do not have a site with enough visitors... chx 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. ------------------------------------------------------------------------ Sun, 21 Aug 2005 00:21:01 +0000 : Jeremy(a)kerneltrap.org Patch needs review.

1 0

[drupal-devel] [bug] Remove message_access function and introduce better worded situation aware messages
by killes 22 Aug '05

22 Aug '05

Issue status update for http://drupal.org/node/17592 Post a follow up: http://drupal.org/project/comments/add/17592 Project: Drupal Version: cvs Component: other Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: Hivemindz Magazine Updated by: killes(a)www.drop.org -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/message-access-1.patch (2.98 KB) Updated the patch. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Sat, 19 Feb 2005 17:50:27 +0000 : Hivemindz Magazine Attachment: http://drupal.org/files/issues/common_11.patch (503 bytes) There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable. It adds the flexibility in phrasology that is necessary in internationalizing Drupal. It creates more usability in that better text instructions can be delivered to the user based on the situation of the process. I have made this slight change in my install which allows me to give a descriptive message based on the url tried. This can be done in both english and swedish without me having to use gettext and the like. <?php --- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); } *Warning*: Unterminated comment starting line 13 in */home/www/drupal.org/modules/codefilter/codefilter.module* on line *47* ------------------------------------------------------------------------ Sat, 19 Feb 2005 19:47:12 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/message-access.patch (2.99 KB) The original description is a bit unclear, but the underlying concern seems to be that the error messages are not specific to the situation they occur in. I share this concern. The attached patch removes the function message_access() (which hails from 2001) and replaces the six calls to it by hopefully better chosen strings. Since I do not use blogapi.module I welcome suggestions for better phrases. Since this is actually a usability bug fix i hope this can get into 4.6. ------------------------------------------------------------------------ Sat, 19 Feb 2005 23:35:15 +0000 : chx Attachment: http://drupal.org/files/issues/message-access_0.patch (3.2 KB) While we are at it, we could open up drupal_access_denied so that the title can be changed per call. It costs almost nothing, breaks nothing, so why not? ------------------------------------------------------------------------ Sun, 20 Feb 2005 02:47:37 +0000 : Steven Can someone point out to me how this is related to i18n, at all? ------------------------------------------------------------------------ Wed, 23 Mar 2005 22:01:17 +0000 : Dries As discussued, this is not going to work as is. ------------------------------------------------------------------------ Wed, 23 Mar 2005 22:06:48 +0000 : killes(a)www.drop.org My patch still applies just fine and I am not aware of any discussion. ------------------------------------------------------------------------ Fri, 08 Apr 2005 16:03:25 +0000 : killes(a)www.drop.org Dries said, he will look at it again after 4.6 got released. ------------------------------------------------------------------------ Thu, 05 May 2005 13:18:22 +0000 : stefan nagtegaal While the patch does not apply anymore, I like the idea very much.. Not every '404' or '403' error page is the same, and a nice message saying what is really wrong improves userfriendlyness.. I am all for such a patch.. :-) Stefan

1 0

[drupal-devel] [feature] create system option to prevent users from changing the theme
by killes 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 +Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: Torenware Reported by: Torenware Updated by: killes(a)www.drop.org Status: patch (code needs work) Moving to cvs. I am delighted about this change. This "feature" annoyed me right from when I started to use Drupal... killes(a)www.drop.org 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. ------------------------------------------------------------------------ Sun, 21 Aug 2005 09:13:59 +0000 : TDobes 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. ------------------------------------------------------------------------ Sun, 21 Aug 2005 21:37:56 +0000 : Dries Agreed. Let's move this to a contributed module and let's tidy up the theme configuration page (unless I'm mistaken, the enabled-checkboxes could probably be removed?).

1 0

[drupal-devel] [feature] create system option to prevent users from changing the theme
by Dries 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: Dries Status: patch (code needs work) Agreed. Let's move this to a contributed module and let's tidy up the theme configuration page (unless I'm mistaken, the enabled-checkboxes could probably be removed?). Dries 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. ------------------------------------------------------------------------ Sun, 21 Aug 2005 09:13:59 +0000 : TDobes 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.

1 0

[drupal-devel] [bug] When I delete a user, any forum in which s/he has commented also disappears.
by Uwe Hermann 21 Aug '05

21 Aug '05

Issue status update for http://drupal.org/node/17428 Post a follow up: http://drupal.org/project/comments/add/17428 Project: Drupal Version: 4.5.0 Component: comment.module Category: bug reports Priority: critical Assigned to: Jill6q Reported by: Jill6q Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Updating status. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Wed, 16 Feb 2005 17:43:53 +0000 : Jill6q Hi, I'm an administrator, and I've discovered that when I delete a user, drupal deletes a) all the forums that the user has created and b) if the user has made any comments in someone else's forum, that forum gets deleted too. i.e. if Dan has commented in the Italian Food forum (the forum was created by admin), and I delete Dan's account, the Italian Food forum disappears entirely from the "Forums" page. Any help for this? Many thanks! (I love drupal) Jill ------------------------------------------------------------------------ Thu, 21 Apr 2005 12:10:33 +0000 : menesis Attachment: http://drupal.org/files/issues/comment_author_delete.patch (996 bytes) I've run into such problem before, with nodes authored by deleted user which dissapear, see http://drupal.org/node/19055 . I've fixed that for myself by resetting node's author to Anonymous, so that the node remains visible. Neither nodes nor comments aren't deleted, they are still there in database, but queries break and nodes or whole forums are not shown. Same fix could be done to comments. Since comments have author's name as well as uid, changing their uid to 0 still leaves the comment with poster's name, so they look the same, and forums or any other nodes the user commented on don't disappear. This fixes a problem with broken forums, but others don't like such approach because if they delete the user, that's because he abused or spammed the site, so they want to delete his/her nodes/comments as well. You could do that same way as in my patches, changing queries from UPDATE to DELETE.

1 0