- Development - lists.drupal.org

[drupal-devel] [task] Adding taxonomy terms has no feedback
by m3avrck 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/31151 Post a follow up: http://drupal.org/project/comments/add/31151 Project: Drupal Version: cvs Component: taxonomy.module Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: m3avrck -Status: patch (code needs review) +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/terms_0.patch (943 bytes) Tested patch, definetly improves usability of taxonomy module and adding terms. Before, it wasn't clear if a term was added or not. This also makes adding a term more consistent with how the rest of Drupal works (e.g., taking you back to the main add term page instead of a blank form wondering what just happened). Fixed coding style of patch. Ready to go. m3avrck Previous comments: ------------------------------------------------------------------------ Wed, 14 Sep 2005 02:08:31 +0000 : drumm Adding a taxonomy term should trigger a drupal_set_message() so people know somehting happened. ------------------------------------------------------------------------ Wed, 14 Sep 2005 17:25:27 +0000 : Souvent22 Drumm, I have it fixed/patched, but before I post, we got some options: Current way is that after adding a term, it stays on the "add terms" page.... So... A) After adding, take me back to add terms for another one. B) After adding, take me back to my list of terms for that vocab. C) Give me a check box that says "Add another after sumbission" During SAT's, they always said B was the right answer...or was it C..hmm....ideas suggestions? ------------------------------------------------------------------------ Wed, 14 Sep 2005 17:31:40 +0000 : m3avrck I would say go with B. That is the general behavior in the rest of Drupal, might as well be consistent. And the checkbox doesn't help that much... extra click (I'm assumed off by default) and the user can just click 'add' again anywho. ------------------------------------------------------------------------ Wed, 14 Sep 2005 17:32:42 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/terms.patch (943 bytes) B it is.

1 0

[drupal-devel] [feature] New field type for profile: taxonomy
by wiz 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/19014 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: wiz Updated by: wiz Status: patch Attachment: http://drupal.org/files/issues/profile-taxonomy.patch (3.87 KB) A new type of field in the profile: taxonomy, useful for a field to select zero or more terms from a vocabulary. This works like the type "selection" but multiple selection is possible, and the list of choices comes from a taxonomy. Unfortunately there is no field in the table profile_fields to store single/multiple selection - which would be nice for the type "selection", too. The selection is stored in a new table (profile_values_term) additionally to the column profile_values.value. This allows for easy processing of the selection the user made. I have not defined any indexes on this new table, which possibly would be required for large data sets. It has a small bug: when nothing is selected, it will automatically select the first entry. The fix would probably have to modify _taxonomy_term_select in taxonomy.module. wiz

2 2

[drupal-devel] [feature] Comment approval queue a pain to use
by mrowe 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/28595 Post a follow up: http://drupal.org/project/comments/add/28595 Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: mrowe Reported by: robertDouglass Updated by: mrowe Status: patch (code needs review) Attachment: http://drupal.org/files/issues/comment_bulk_approval_1.patch (2.43 KB) Oh, so you're saying I should have read the style guide... ;) I've fixed the brace position, and I've redone the db_query as you suggested. Thanks! mrowe Previous comments: ------------------------------------------------------------------------ Wed, 10 Aug 2005 08:29:14 +0000 : robertDouglass When using the comment approval queue the workflow for approving comments is awful. You have to click administer->comments->approval queue to get a list of comments awaiting approval. Then you have to click edit on one of the comments, click the collabsible field-set for the publishing controls, click to published and save the comment. Then repeat the process for the next comment. I'd say that this workflow is a significant deterrent to anyone using this functionality. To make it better, there would be checkboxes next to each comment in the table on the approval queue page, and a set of operators analogous to the content overview page. Better yet would be if each comment in the table was an AJAX link to the comment's body and info which would expand right there in the table itself, since it is usually impossible just from the comment title to know whether to publish or not. If one could click the various comments open, right there in the table, then mass publish or delete, we'd have a real approval queue. Perhaps the spam module could tie into the actions that can be taken on comments so a mass "mark as spam" could be done too. ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:32:47 +0000 : mrowe Attachment: http://drupal.org/files/issues/comment_bulk_approval.patch (2.24 KB) Here's a patch (against HEAD) that gives you the cheap-and-dirty approach (checkboxes that allow bulk approval/unapproval of comments). I'll leave the gold-plated AJAX solution to someone with more time. :) ------------------------------------------------------------------------ Wed, 14 Sep 2005 21:17:21 +0000 : Dries - Don't use tabs. - SQL queries might be vularnable to SQL injection attacks. Use db_query()'s %s and %d directives. ------------------------------------------------------------------------ Thu, 15 Sep 2005 02:24:17 +0000 : mrowe Attachment: http://drupal.org/files/issues/comment_bulk_approval_0.patch (2.38 KB) Ok, I think I got rid of all the tabs this time... I've had to use db_escape_string, rather than the sprintf params to db_query, but it should have the same effect. ------------------------------------------------------------------------ Thu, 15 Sep 2005 03:28:50 +0000 : moshe weitzman minor nits: we use an extra line in our else clauses. this should be two lines: } else { also, you can almost always avoid using db_escape_string() directly. you will need to do a str_repeat('%d, ', count($unpublish)) in the SQL(for unpublish query) and then pass a an array as the last argument to db_query. This is the seldom used 'pass all values in an array' feature of db_query: http://drupaldocs.org/api/head/function/db_query

1 0

[drupal-devel] [task] Use thead and tbody in theme_table()
by drumm 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/28777 Post a follow up: http://drupal.org/project/comments/add/28777 Project: Drupal Version: cvs Component: theme system Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Attachment: http://drupal.org/files/issues/theme.inc_2.diff (1.26 KB) For extra accessibility and semanticity we should throw in a thead tag if there is a header row and always put in a tbody tag. drumm

4 7

[drupal-devel] [feature] Comment approval queue a pain to use
by moshe weitzman 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/28595 Post a follow up: http://drupal.org/project/comments/add/28595 Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: mrowe Reported by: robertDouglass Updated by: moshe weitzman Status: patch (code needs review) minor nits: we use an extra line in our else clauses. this should be two lines: } else { also, you can almost always avoid using db_escape_string() directly. you will need to do a str_repeat('%d, ', count($unpublish)) in the SQL(for unpublish query) and then pass a an array as the last argument to db_query. This is the seldom used 'pass all values in an array' feature of db_query: http://drupaldocs.org/api/head/function/db_query moshe weitzman Previous comments: ------------------------------------------------------------------------ Wed, 10 Aug 2005 08:29:14 +0000 : robertDouglass When using the comment approval queue the workflow for approving comments is awful. You have to click administer->comments->approval queue to get a list of comments awaiting approval. Then you have to click edit on one of the comments, click the collabsible field-set for the publishing controls, click to published and save the comment. Then repeat the process for the next comment. I'd say that this workflow is a significant deterrent to anyone using this functionality. To make it better, there would be checkboxes next to each comment in the table on the approval queue page, and a set of operators analogous to the content overview page. Better yet would be if each comment in the table was an AJAX link to the comment's body and info which would expand right there in the table itself, since it is usually impossible just from the comment title to know whether to publish or not. If one could click the various comments open, right there in the table, then mass publish or delete, we'd have a real approval queue. Perhaps the spam module could tie into the actions that can be taken on comments so a mass "mark as spam" could be done too. ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:32:47 +0000 : mrowe Attachment: http://drupal.org/files/issues/comment_bulk_approval.patch (2.24 KB) Here's a patch (against HEAD) that gives you the cheap-and-dirty approach (checkboxes that allow bulk approval/unapproval of comments). I'll leave the gold-plated AJAX solution to someone with more time. :) ------------------------------------------------------------------------ Wed, 14 Sep 2005 21:17:21 +0000 : Dries - Don't use tabs. - SQL queries might be vularnable to SQL injection attacks. Use db_query()'s %s and %d directives. ------------------------------------------------------------------------ Thu, 15 Sep 2005 02:24:17 +0000 : mrowe Attachment: http://drupal.org/files/issues/comment_bulk_approval_0.patch (2.38 KB) Ok, I think I got rid of all the tabs this time... I've had to use db_escape_string, rather than the sprintf params to db_query, but it should have the same effect.

1 0

[drupal-devel] [feature] Comment approval queue a pain to use
by mrowe 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/28595 Post a follow up: http://drupal.org/project/comments/add/28595 Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: mrowe Reported by: robertDouglass Updated by: mrowe -Status: patch (code needs work) +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/comment_bulk_approval_0.patch (2.38 KB) Ok, I think I got rid of all the tabs this time... I've had to use db_escape_string, rather than the sprintf params to db_query, but it should have the same effect. mrowe Previous comments: ------------------------------------------------------------------------ Wed, 10 Aug 2005 08:29:14 +0000 : robertDouglass When using the comment approval queue the workflow for approving comments is awful. You have to click administer->comments->approval queue to get a list of comments awaiting approval. Then you have to click edit on one of the comments, click the collabsible field-set for the publishing controls, click to published and save the comment. Then repeat the process for the next comment. I'd say that this workflow is a significant deterrent to anyone using this functionality. To make it better, there would be checkboxes next to each comment in the table on the approval queue page, and a set of operators analogous to the content overview page. Better yet would be if each comment in the table was an AJAX link to the comment's body and info which would expand right there in the table itself, since it is usually impossible just from the comment title to know whether to publish or not. If one could click the various comments open, right there in the table, then mass publish or delete, we'd have a real approval queue. Perhaps the spam module could tie into the actions that can be taken on comments so a mass "mark as spam" could be done too. ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:32:47 +0000 : mrowe Attachment: http://drupal.org/files/issues/comment_bulk_approval.patch (2.24 KB) Here's a patch (against HEAD) that gives you the cheap-and-dirty approach (checkboxes that allow bulk approval/unapproval of comments). I'll leave the gold-plated AJAX solution to someone with more time. :) ------------------------------------------------------------------------ Wed, 14 Sep 2005 21:17:21 +0000 : Dries - Don't use tabs. - SQL queries might be vularnable to SQL injection attacks. Use db_query()'s %s and %d directives.

1 0

[drupal-devel] [task] Improvments to Filter UI
by Souvent22 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/27364 Post a follow up: http://drupal.org/project/comments/add/27364 Project: Drupal Version: cvs Component: filter.module Category: tasks Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Souvent22 -Status: patch (code needs review) +Status: patch (ready to be committed) +1. I honestly have not played around with the filter formats ever. I looked at them, adn they were a mess. Did the patch, and everything was clear as day. Anything that makes drupal easier to use...AND makes it easier to understand and make sense should def. be included. Souvent22 Previous comments: ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:30:54 +0000 : Bèr Kessels This is a mockup for the Filter UI. Currently it is soo complex, that I dare to call it broken. Please comment on this, for I will not ake any patches, when the general idea is disliked. The idea is t split filters and input formats better. Filters are filters, defined in modules. Input formats are bundles of filters. This is how we have it ATM, but the interface fails to communicate that. I tried to develop a consistent (with the rest of Drupal) interfce that makes it clearer what is what. The menu is as follows: * administer ** .... ** settings *** input formats *** filters ** ... ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:37:10 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_list1.png (16.34 KB) * administer ** .... ** settings *** input formats >> see attachement 1 *** filters ** ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:39:02 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_add.png (23.42 KB) * administer ** .... ** settings *** input formats >> see attachement 2, tab 2 *** filters ** Note: The default checkbox lmay seem a bit odd. But checking it will remove the "default status" from the current "default" one and make this one "default". The help text, and a drupal_set_message should explain this. ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:40:08 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit_format.png (22.17 KB) * administer ** .... ** settings *** input formats >> clicking a 'configure' link in the table of attachement 1 *** filters ** ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:40:55 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-filters_list.png (36.24 KB) * administer ** .... ** settings *** input formats *** filters >> see attachement 4 ** ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:41:40 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit.png (22.63 KB) * administer ** .... ** settings *** input formats *** filters >> clicking a 'configure' link in the table of attachement 4 ** ------------------------------------------------------------------------ Mon, 25 Jul 2005 14:46:27 +0000 : Bèr Kessels IMO this makes the interface easier. But other disagree. And because it also removes one feature: (being able to use E.g. HTML in different input formats, with different settings) I'll simply wont fix this :( ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:36:12 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy.patch (10.28 KB) I decided to go for it anyway. Be it in a slightly different way then my initial mockups. The difference is that I left the filters where they are, hidden beneath the formats. So, here is the patch that makes the filter UI more consistent with screens like blocs, menus, vocabularies et al also nice to note is that: 93 lines are added, 104 are removed. So netto we have less code :) (cvs diff filter.module | grep ^+ | wc -l) ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:37:02 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_list_html.png (44.64 KB) Here is how the listing now looks. ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:37:57 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit_format_html.png (113.71 KB) And the "configure" screen. The 'add' screen looks exactly the same, only with the default values pre-filled. ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:39:19 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit_format_too_long.png (121.82 KB) Oh, And here is a really nice example of why the current screen is no good. And here I "only" have four roles. I run a site with 12 roles, imagine this screen then! ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:48:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD.patch (10.24 KB) And here is a pathc for HEAD (I forgot that I developed this on a 4.6.2 codebase. Sorry) ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:55:25 +0000 : stefan nagtegaal I like this very, very much! This is - indeed - much better than the current UI. This always fits, and makes the life of people who use a fixed width theme much nicer.. Ber, FYI (you probably know this too), 'admin/access' does also break fixed width themes due to the fact that it expands the width of the table when more roles are being added.. Good catch! I like it much more this way.. +1 from me... ------------------------------------------------------------------------ Fri, 29 Jul 2005 07:27:34 +0000 : Dries The code style needs work (spaces, tabs, 'as' -> 'AS'), the code comments need work, and debug statements should be removed. Screenshots look good to me. db_query('UPDATE {filter_formats} SET cache = %d, name = \'%s\', roles = \'%s\' WHERE format = %d', (int)$cache, $name, $roles, $format); can be written better/shorter quote-wise. ------------------------------------------------------------------------ Fri, 29 Jul 2005 09:04:16 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD_0.patch (10.37 KB) Dries, thanks a lot for the review. OI fixed your comments. Or so I hope. code-style.pl was of no use (can that *please* be removed from core?) because it chokes on the help texts. It also pointed out a lot of old formatting isues, whic, when fixed wuold flood this patch with unrelated fixes. I tried to narow my style-searching to the areas I touched. And I made the comments more verbous. The query is fixed. it saves no characters, but looks better now. Thanks for the tip. The print_r..... blush. thats what I get for not running my default grep -r print_r on my code after finishing up... I could not find a lot of spaces and tabs. So it lmight be that i missed one. I triple checked it though. ------------------------------------------------------------------------ Fri, 29 Jul 2005 09:32:21 +0000 : Steven Moving the role settings inward does fix the wide-table problem, but it makes the filter configuration much more opaque. We could perhaps fix this by showing the roles as a comma-separate list in the input formats table. Such a list can wrap and will not stretch the table. Other than that: * Having the instructions for the Roles and Filters form_group() at the bottom is a bit weird. The distance is too big. * The table that was used for toggling filters on/off was much more compact before, and IMO a lot clearer. Why change to a flat list with the description staggered below each item? ------------------------------------------------------------------------ Fri, 29 Jul 2005 10:31:30 +0000 : Bèr Kessels consistancy, consistancy and more consistancy. There really is nothing worse that having a different 'concept' of UI for every thing in Drupal. We are going in the right direction, with the blocks being editable objects, menus acting like that, taxonomy, users, etc.. I wanted to make this act similar. I am not at all happy with the fact tah the list is still a form. But we need this, for setting the default. A big -1 for a comma-separate list. That is extremely hackish, even worse useabilitywise and just silly * we should avoid typing when not needed. * we should avoid errors on input, when they can be avoided (a typo is made very easy, I know all about it) Form set errors won't fix that usability -wise. I agree that you sort-of loose the overview. But IMO that is a minor loss comared to what we gain, usability-wise. The wtoo-wide was onlywhat triggered me. But do not think that I am noly making this patch to fix that issue. This patch is there to improve usability, through consistancy. o make drupal behave the same in most places in admin. If you know one screen, you know most of them. We really should move away from custom-hacks for every page, because that is useability rule #1: consistancy. Stadardisation, even if sometimes a custom hack might make things easier in that single case, it will reduce your overall usability so much that nearly ever it is worth that hack. That select-boxes instead of the table issue: consistancy. As well that it completely broke fluid CSS layouts, my solution is more consistant, and uses forms the way they are meant. If we cannot use $descritption in checkboxes they should be removed. but IMO it feels much more consistant. Tables are for tabular data, and this is simply a list of items, with additional data. And i do not really get what you mean with "too far down". Do you mean that you would like to see the order of the groups different? ------------------------------------------------------------------------ Fri, 29 Jul 2005 13:31:24 +0000 : Dries I haven't tested Ber's patch yet but looking at the screenshots, it like what I see. I remember being confused by the current filter UI, and often, I still am. ------------------------------------------------------------------------ Fri, 29 Jul 2005 19:53:26 +0000 : moshe weitzman I dislike the recent movement away from overview pages. I think we can still provide and overview while allowing editing to happen in a dedicated form. An example in the wrong direction is 'content types' admin. It is impossible to get an overview, and the listing page is worthless. I agree with Steven on this one. It is true that consistency is desirable. But consistent crap is not. ------------------------------------------------------------------------ Fri, 29 Jul 2005 20:02:39 +0000 : killes(a)www.drop.org I agree with Moshe. Getting a quick overview about what is set how is essential for an admin. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:27:15 +0000 : Robrecht Jacques Overall I like the screenshots. Did not test the patch. Bèr, what I think Steven (#15) meant by "showing the roles as a comma-separate list in the input formats table" is that as an overview page it would be better if you added a list (not an input box!) to screenshot "input-formats_list1.png" (comment #1). Add a column that reads "Roles" (or "Enabled for") and then for each row a comma seperated list of the roles that can use this input format (or maybe even better a HTML list). You would still need to click "configure" to _change_ the roles. The "Default" text (not a radio button) you already show in the "Options" column is something similar: it immediately shows that this input format is the default without you having to go to the "configure" page. Why not do the same for "roles"? If this is what Steven meant, then I tend to agree with him. And to help moshe and killes: maybe you could even add a column that _lists_ the used input filters. Again, only a list, not a way to change it. That's what the "operations" column is for. A table like that will "fluid" better than what we have now, still it is a _complete_ overview of the settings. I could have misunderstand someone... I have the tendency to do that... ------------------------------------------------------------------------ Mon, 22 Aug 2005 08:21:32 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements.patch (14.52 KB) by popular demand: a comma separated list. ------------------------------------------------------------------------ Mon, 22 Aug 2005 08:24:31 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/format_now_contains_roles.png (22.09 KB) and a screenshot ------------------------------------------------------------------------ Mon, 22 Aug 2005 18:39:44 +0000 : Dries Please check your use of print theme('page', $output). Normally, you just return $output. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:54:28 +0000 : Bèr Kessels All instances of theme('page',...) in filter.module are now changed to return ... ; furthermore, the patch is the same. ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:04:02 +0000 : Uwe Hermann Bèr, I think you forgot to attach your updated patch. ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:27:39 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements_2.patch (13.52 KB) my email client has this nice warning system for attachements. Maybe drupal should search for the word attachement too, and when no att. found give an error ;). Or maybe i should just learn to pay attention. Guess that is easier. Anyway, here it is. ------------------------------------------------------------------------ Thu, 08 Sep 2005 20:22:54 +0000 : Dries I wanted to apply this patch but: 1. I can't change the default input format. 'Save'-button doesn't work. 2. I got confused by the fact I can't change the roles of the default filter. I think the form group description should explain this. 3. form_group(t(filter)) should be form_group(t('filter'), ...). ------------------------------------------------------------------------ Thu, 08 Sep 2005 20:51:24 +0000 : m3avrck Found a few more issues: If I go into 'Configure' for 'PHP Code' and click the 'Configure' tab at the top and then click 'list filters' link in the text, I get this warning with PHP5 warning: Missing argument 1 for filter_admin_format() in \drupal\modules\filter.module on line 378. Also, it is sort of confusing as to what the 'List' tab implies. For example, if I click on 'input formats' in the admin menu, I get a list of the current filters. When I click 'configure' for one of those, I see the options for that filter. However, it says 'list' in one of the tab, which doesn't really mean much. I thought that was the list of filters, not the options for that filter. That should be cleaned up. Also, there is no way to get back to the full list of filters unless you click on 'input formats' in the admin menu. A setting/link to fix this would be great. Also, where is the link to add filters??? I think the options/layout/tabs should mimic of that of admin > users. So on admin > input formats, it has the tabs 'list', 'add format' ... very clear and consistent. On a configure page for a filter, it should have 'list', 'view', 'configure', 'rearrange' ... this would make it easier to navigate and get back to the original list of filters. Make sense? I think this and Dries' comments put this patch over the top :) ------------------------------------------------------------------------ Fri, 09 Sep 2005 01:48:55 +0000 : tag In my initial battle to figure out this module's (quite nice) functionality, what tripped me up the most was actually the nomenclature. The way I keep it straight in my head now is to translate "input format" to "filter set". If you view those (the current) screens with this in mind, I think it's a lot easier to understand what's what. It sort of describes this in the help text, but the terms "filter" and "input format" don't really convey the relationship between the two -- there's no way to intuit that an "input format" is a collection of "filters". Not to my mind at least... and well, we know nobody reads instructions... Are there any technicalities that make renaming "input format" to "filter set" not accurate? Or does someone have a better term/terms to better show the relationship of these elements? (I'm aware of filters in servlet architectures but I don't think there's much of a collision with that usage). Anyhow, I guess this doesn't quite address the UI controls and/or layout, but would still help a lot. ------------------------------------------------------------------------ Fri, 09 Sep 2005 06:35:34 +0000 : Bèr Kessels I prefer filter set. In fact: I like it a lot. Anyone else ideas on this? ------------------------------------------------------------------------ Fri, 09 Sep 2005 10:18:18 +0000 : Dries I too had problems with the terminology; it took me months to get used to 'input formats' versus 'filters'. Using 'filter sets' might improve the situation -- especially from an administrator's point of view when you have to wrap your head around the UI/difference. I'm not native English, but 'filter set' sounds more explanatory, yet slightly more geeky so I'm not sure if it flies for users who don't need to understand the underlying concepts (eg. under the node and comment submission forms). ------------------------------------------------------------------------ Fri, 09 Sep 2005 11:00:05 +0000 : Bèr Kessels a heads up: I ma redoing the patch. But decided no to change the name yet. That is a too big change. IT should be in a separate issue, IMO. ------------------------------------------------------------------------ Fri, 09 Sep 2005 15:27:43 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_2.patch (13.57 KB) * Bugs as reported by dries fixed. * The [add] tab not appearing is due to your menu caching, refresh that please. * Fixed an additional bug: Some agents do not send TRUE for disabled checkboxen. Also in current filter admin. and people: we have a problem. Deleting a filter trows errors, due to the revisions changes. that happens in filter module now, but also after this patch. I have too little knowledge of the filter system to fix that, and IMO that is a separate issue. It should be fixed right after this patch is committed. ------------------------------------------------------------------------ Fri, 09 Sep 2005 15:57:18 +0000 : Bèr Kessels FYI: the delete bug is waiting here: http://drupal.org/node/30781 ------------------------------------------------------------------------ Fri, 09 Sep 2005 18:18:17 +0000 : m3avrck Get this warning in PHP5: Warning: Missing argument 1 for filter_admin_format() in \modules\filter.module on line 379 I have traced this error back to line 240. Why are there no callback arguments like above on line 235? Looks like a source of a problem/bug here so needs to be addressed, not sure exactly how to fix it myself (otherwise I would). Should be easy it seems. Also, for a quick and easy usability improvement, on line 239, change t('list') to t('view') ... makes the menus less confusing. After those fixes, looks like this patch is ready to be committed :) ------------------------------------------------------------------------ Fri, 09 Sep 2005 18:23:27 +0000 : m3avrck Also, this dialog is a bit confusing: "Choose which roles may use this filter format You are editing the default format. For the default format, all roles must be enabled. Therefore you cannot change them. " Maybe make it so that first line doesn't appear there on that page? ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:35:50 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_2_0.patch (13.59 KB) changed that line of help. Can this please still be taken in consideration before the freeze? ------------------------------------------------------------------------ Tue, 13 Sep 2005 18:29:28 +0000 : m3avrck Can't apply patch, getting error: Patch malformed at line 287 ------------------------------------------------------------------------ Tue, 13 Sep 2005 19:10:07 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements_2_0.patch (14.19 KB) strange. the dowloaded one breaks too, yet the one i uploaded stll works. anyway, rerolled ------------------------------------------------------------------------ Tue, 13 Sep 2005 19:25:25 +0000 : Dries IMO, the form function needs more work. You need to group the form construction and the form saving. Right now, when you don't provide a title, you are given an error and an emptied form. This may be a left-over from the original code though but it would be cool if you could tidy this up. The form_group() description still need a trailing point. There is a broken link in the following help text on the 'add input format'-page: /If you notice some filters are causing conflicts in the output, you can [rearrange] them./. ------------------------------------------------------------------------ Tue, 13 Sep 2005 19:30:12 +0000 : Bèr Kessels dont have time anymore. sorry. ------------------------------------------------------------------------ Tue, 13 Sep 2005 20:50:34 +0000 : m3avrck new patch soon! ------------------------------------------------------------------------ Tue, 13 Sep 2005 22:10:25 +0000 : m3avrck Attachment: http://drupal.org/files/issues/filter.module_10.patch (20.27 KB) Ok here's a new patch. Lot's of fixes in this one (all of the ones from above except the one noted below), including support for the new revisions patch. Additionally, 'input formats' has been renamed to 'input filters'. After debate on IRC, and the above comments in this post, it seems that 'input formats' is somewhat misleading and doesn't make sense. 'input filters' clears this up and makes sense to both native and non-native English speakers (as tested in IRC anywho ;)). This also makes more sense since Drupal refers to everything as 'filters' and not 'formats'. However, there is one issue still left unresolved: If you create a new input filter, and don't specify a title, page reloads clearing all filled in fields and prompts the error message. Additionally, a blank filter is created. Wanted to get this patch posted, I'll look at it later today but if someone can get this fixed easily, please do, thanks! ------------------------------------------------------------------------ Tue, 13 Sep 2005 22:38:05 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements_3.patch (21.49 KB) this patch should fix the issue m3 rasies abuot amepty formats being created. Yes, i use a simple drupal_goto, in case of a for error. And no, it is not very easy to get the old posted data back. ------------------------------------------------------------------------ Tue, 13 Sep 2005 23:44:26 +0000 : moshe weitzman the most visible place for this 'input format' term is on the node form. thats where ordinary users see this stuff. in that context, i don't think 'input filters is an improvement over input formats. the question we are asking our users is 'what is the format of your post'?, not what filters do you want applied ... just my .02. sorry i wasn't in IRC when this came up. this need not hold up the whole patch. ------------------------------------------------------------------------ Wed, 14 Sep 2005 06:48:03 +0000 : Bèr Kessels Moshe. I agreed with you, and was against the name change. In this patch at least. However, it slipped in. Stetting code to be committed for it has gone trough so many review cycles that this patch has MUCH better code than the rest of the filter module, which REALLY needs a big overhaul :) ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:37:27 +0000 : Dries Are you saving the data before validating it? If we want to convert this form to the new form API, we have to fix this cleanly. Sorry. I agree with Moshe that 'input filters' is suboptimal. People want to select how their text is going to be /processed/. The word/filter/ sounds rather technical to me. Also, the difference between a single filter and a set of filters becomes rather blurry to the point it could be very confusing. ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:41:42 +0000 : m3avrck Well I was the one that changed 'input filters' to 'input formats' as that seemed to be the best thing we could come up. I guess it got confusing because people wanted this to change but maybe not in this patch. So I will revert that change in a forthecoming patch. Additinally, this patch is *not* ready. I was going through the form logic last night and it is a bit off, hence why errors are displayed along side a an empty form. I'm going to work as hard as I can and as fast to clean this patch up like I mentioned I would yesterday. I'll have some ready soon enough that will be commit worthy. ------------------------------------------------------------------------ Wed, 14 Sep 2005 14:22:41 +0000 : Bèr Kessels according to me its a go or leave. if m3 or anyone else wants to take over fine. I am out. no time. ------------------------------------------------------------------------ Wed, 14 Sep 2005 21:30:45 +0000 : m3avrck Attachment: http://drupal.org/files/issues/filter.module_11.patch (28.03 KB) Ok new patch! Everything is fixed. Code has been reworked and lots of bugs fixed. Code should also be simpler to read (or at least follow in terms of logic now). Ready to go!

1 0

[drupal-devel] [task] Improvments to Filter UI
by m3avrck 14 Sep '05

14 Sep '05

Issue status update for http://drupal.org/node/27364 Post a follow up: http://drupal.org/project/comments/add/27364 Project: Drupal Version: cvs Component: filter.module Category: tasks Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: m3avrck -Status: patch (code needs work) +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/filter.module_11.patch (28.03 KB) Ok new patch! Everything is fixed. Code has been reworked and lots of bugs fixed. Code should also be simpler to read (or at least follow in terms of logic now). Ready to go! m3avrck Previous comments: ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:30:54 +0000 : Bèr Kessels This is a mockup for the Filter UI. Currently it is soo complex, that I dare to call it broken. Please comment on this, for I will not ake any patches, when the general idea is disliked. The idea is t split filters and input formats better. Filters are filters, defined in modules. Input formats are bundles of filters. This is how we have it ATM, but the interface fails to communicate that. I tried to develop a consistent (with the rest of Drupal) interfce that makes it clearer what is what. The menu is as follows: * administer ** .... ** settings *** input formats *** filters ** ... ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:37:10 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_list1.png (16.34 KB) * administer ** .... ** settings *** input formats >> see attachement 1 *** filters ** ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:39:02 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_add.png (23.42 KB) * administer ** .... ** settings *** input formats >> see attachement 2, tab 2 *** filters ** Note: The default checkbox lmay seem a bit odd. But checking it will remove the "default status" from the current "default" one and make this one "default". The help text, and a drupal_set_message should explain this. ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:40:08 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit_format.png (22.17 KB) * administer ** .... ** settings *** input formats >> clicking a 'configure' link in the table of attachement 1 *** filters ** ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:40:55 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-filters_list.png (36.24 KB) * administer ** .... ** settings *** input formats *** filters >> see attachement 4 ** ------------------------------------------------------------------------ Sun, 24 Jul 2005 09:41:40 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit.png (22.63 KB) * administer ** .... ** settings *** input formats *** filters >> clicking a 'configure' link in the table of attachement 4 ** ------------------------------------------------------------------------ Mon, 25 Jul 2005 14:46:27 +0000 : Bèr Kessels IMO this makes the interface easier. But other disagree. And because it also removes one feature: (being able to use E.g. HTML in different input formats, with different settings) I'll simply wont fix this :( ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:36:12 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy.patch (10.28 KB) I decided to go for it anyway. Be it in a slightly different way then my initial mockups. The difference is that I left the filters where they are, hidden beneath the formats. So, here is the patch that makes the filter UI more consistent with screens like blocs, menus, vocabularies et al also nice to note is that: 93 lines are added, 104 are removed. So netto we have less code :) (cvs diff filter.module | grep ^+ | wc -l) ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:37:02 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_list_html.png (44.64 KB) Here is how the listing now looks. ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:37:57 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit_format_html.png (113.71 KB) And the "configure" screen. The 'add' screen looks exactly the same, only with the default values pre-filled. ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:39:19 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/input-formats_edit_format_too_long.png (121.82 KB) Oh, And here is a really nice example of why the current screen is no good. And here I "only" have four roles. I run a site with 12 roles, imagine this screen then! ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:48:35 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD.patch (10.24 KB) And here is a pathc for HEAD (I forgot that I developed this on a 4.6.2 codebase. Sorry) ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:55:25 +0000 : stefan nagtegaal I like this very, very much! This is - indeed - much better than the current UI. This always fits, and makes the life of people who use a fixed width theme much nicer.. Ber, FYI (you probably know this too), 'admin/access' does also break fixed width themes due to the fact that it expands the width of the table when more roles are being added.. Good catch! I like it much more this way.. +1 from me... ------------------------------------------------------------------------ Fri, 29 Jul 2005 07:27:34 +0000 : Dries The code style needs work (spaces, tabs, 'as' -> 'AS'), the code comments need work, and debug statements should be removed. Screenshots look good to me. db_query('UPDATE {filter_formats} SET cache = %d, name = \'%s\', roles = \'%s\' WHERE format = %d', (int)$cache, $name, $roles, $format); can be written better/shorter quote-wise. ------------------------------------------------------------------------ Fri, 29 Jul 2005 09:04:16 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD_0.patch (10.37 KB) Dries, thanks a lot for the review. OI fixed your comments. Or so I hope. code-style.pl was of no use (can that *please* be removed from core?) because it chokes on the help texts. It also pointed out a lot of old formatting isues, whic, when fixed wuold flood this patch with unrelated fixes. I tried to narow my style-searching to the areas I touched. And I made the comments more verbous. The query is fixed. it saves no characters, but looks better now. Thanks for the tip. The print_r..... blush. thats what I get for not running my default grep -r print_r on my code after finishing up... I could not find a lot of spaces and tabs. So it lmight be that i missed one. I triple checked it though. ------------------------------------------------------------------------ Fri, 29 Jul 2005 09:32:21 +0000 : Steven Moving the role settings inward does fix the wide-table problem, but it makes the filter configuration much more opaque. We could perhaps fix this by showing the roles as a comma-separate list in the input formats table. Such a list can wrap and will not stretch the table. Other than that: * Having the instructions for the Roles and Filters form_group() at the bottom is a bit weird. The distance is too big. * The table that was used for toggling filters on/off was much more compact before, and IMO a lot clearer. Why change to a flat list with the description staggered below each item? ------------------------------------------------------------------------ Fri, 29 Jul 2005 10:31:30 +0000 : Bèr Kessels consistancy, consistancy and more consistancy. There really is nothing worse that having a different 'concept' of UI for every thing in Drupal. We are going in the right direction, with the blocks being editable objects, menus acting like that, taxonomy, users, etc.. I wanted to make this act similar. I am not at all happy with the fact tah the list is still a form. But we need this, for setting the default. A big -1 for a comma-separate list. That is extremely hackish, even worse useabilitywise and just silly * we should avoid typing when not needed. * we should avoid errors on input, when they can be avoided (a typo is made very easy, I know all about it) Form set errors won't fix that usability -wise. I agree that you sort-of loose the overview. But IMO that is a minor loss comared to what we gain, usability-wise. The wtoo-wide was onlywhat triggered me. But do not think that I am noly making this patch to fix that issue. This patch is there to improve usability, through consistancy. o make drupal behave the same in most places in admin. If you know one screen, you know most of them. We really should move away from custom-hacks for every page, because that is useability rule #1: consistancy. Stadardisation, even if sometimes a custom hack might make things easier in that single case, it will reduce your overall usability so much that nearly ever it is worth that hack. That select-boxes instead of the table issue: consistancy. As well that it completely broke fluid CSS layouts, my solution is more consistant, and uses forms the way they are meant. If we cannot use $descritption in checkboxes they should be removed. but IMO it feels much more consistant. Tables are for tabular data, and this is simply a list of items, with additional data. And i do not really get what you mean with "too far down". Do you mean that you would like to see the order of the groups different? ------------------------------------------------------------------------ Fri, 29 Jul 2005 13:31:24 +0000 : Dries I haven't tested Ber's patch yet but looking at the screenshots, it like what I see. I remember being confused by the current filter UI, and often, I still am. ------------------------------------------------------------------------ Fri, 29 Jul 2005 19:53:26 +0000 : moshe weitzman I dislike the recent movement away from overview pages. I think we can still provide and overview while allowing editing to happen in a dedicated form. An example in the wrong direction is 'content types' admin. It is impossible to get an overview, and the listing page is worthless. I agree with Steven on this one. It is true that consistency is desirable. But consistent crap is not. ------------------------------------------------------------------------ Fri, 29 Jul 2005 20:02:39 +0000 : killes(a)www.drop.org I agree with Moshe. Getting a quick overview about what is set how is essential for an admin. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:27:15 +0000 : Robrecht Jacques Overall I like the screenshots. Did not test the patch. Bèr, what I think Steven (#15) meant by "showing the roles as a comma-separate list in the input formats table" is that as an overview page it would be better if you added a list (not an input box!) to screenshot "input-formats_list1.png" (comment #1). Add a column that reads "Roles" (or "Enabled for") and then for each row a comma seperated list of the roles that can use this input format (or maybe even better a HTML list). You would still need to click "configure" to _change_ the roles. The "Default" text (not a radio button) you already show in the "Options" column is something similar: it immediately shows that this input format is the default without you having to go to the "configure" page. Why not do the same for "roles"? If this is what Steven meant, then I tend to agree with him. And to help moshe and killes: maybe you could even add a column that _lists_ the used input filters. Again, only a list, not a way to change it. That's what the "operations" column is for. A table like that will "fluid" better than what we have now, still it is a _complete_ overview of the settings. I could have misunderstand someone... I have the tendency to do that... ------------------------------------------------------------------------ Mon, 22 Aug 2005 08:21:32 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements.patch (14.52 KB) by popular demand: a comma separated list. ------------------------------------------------------------------------ Mon, 22 Aug 2005 08:24:31 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/format_now_contains_roles.png (22.09 KB) and a screenshot ------------------------------------------------------------------------ Mon, 22 Aug 2005 18:39:44 +0000 : Dries Please check your use of print theme('page', $output). Normally, you just return $output. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:54:28 +0000 : Bèr Kessels All instances of theme('page',...) in filter.module are now changed to return ... ; furthermore, the patch is the same. ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:04:02 +0000 : Uwe Hermann Bèr, I think you forgot to attach your updated patch. ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:27:39 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements_2.patch (13.52 KB) my email client has this nice warning system for attachements. Maybe drupal should search for the word attachement too, and when no att. found give an error ;). Or maybe i should just learn to pay attention. Guess that is easier. Anyway, here it is. ------------------------------------------------------------------------ Thu, 08 Sep 2005 20:22:54 +0000 : Dries I wanted to apply this patch but: 1. I can't change the default input format. 'Save'-button doesn't work. 2. I got confused by the fact I can't change the roles of the default filter. I think the form group description should explain this. 3. form_group(t(filter)) should be form_group(t('filter'), ...). ------------------------------------------------------------------------ Thu, 08 Sep 2005 20:51:24 +0000 : m3avrck Found a few more issues: If I go into 'Configure' for 'PHP Code' and click the 'Configure' tab at the top and then click 'list filters' link in the text, I get this warning with PHP5 warning: Missing argument 1 for filter_admin_format() in \drupal\modules\filter.module on line 378. Also, it is sort of confusing as to what the 'List' tab implies. For example, if I click on 'input formats' in the admin menu, I get a list of the current filters. When I click 'configure' for one of those, I see the options for that filter. However, it says 'list' in one of the tab, which doesn't really mean much. I thought that was the list of filters, not the options for that filter. That should be cleaned up. Also, there is no way to get back to the full list of filters unless you click on 'input formats' in the admin menu. A setting/link to fix this would be great. Also, where is the link to add filters??? I think the options/layout/tabs should mimic of that of admin > users. So on admin > input formats, it has the tabs 'list', 'add format' ... very clear and consistent. On a configure page for a filter, it should have 'list', 'view', 'configure', 'rearrange' ... this would make it easier to navigate and get back to the original list of filters. Make sense? I think this and Dries' comments put this patch over the top :) ------------------------------------------------------------------------ Fri, 09 Sep 2005 01:48:55 +0000 : tag In my initial battle to figure out this module's (quite nice) functionality, what tripped me up the most was actually the nomenclature. The way I keep it straight in my head now is to translate "input format" to "filter set". If you view those (the current) screens with this in mind, I think it's a lot easier to understand what's what. It sort of describes this in the help text, but the terms "filter" and "input format" don't really convey the relationship between the two -- there's no way to intuit that an "input format" is a collection of "filters". Not to my mind at least... and well, we know nobody reads instructions... Are there any technicalities that make renaming "input format" to "filter set" not accurate? Or does someone have a better term/terms to better show the relationship of these elements? (I'm aware of filters in servlet architectures but I don't think there's much of a collision with that usage). Anyhow, I guess this doesn't quite address the UI controls and/or layout, but would still help a lot. ------------------------------------------------------------------------ Fri, 09 Sep 2005 06:35:34 +0000 : Bèr Kessels I prefer filter set. In fact: I like it a lot. Anyone else ideas on this? ------------------------------------------------------------------------ Fri, 09 Sep 2005 10:18:18 +0000 : Dries I too had problems with the terminology; it took me months to get used to 'input formats' versus 'filters'. Using 'filter sets' might improve the situation -- especially from an administrator's point of view when you have to wrap your head around the UI/difference. I'm not native English, but 'filter set' sounds more explanatory, yet slightly more geeky so I'm not sure if it flies for users who don't need to understand the underlying concepts (eg. under the node and comment submission forms). ------------------------------------------------------------------------ Fri, 09 Sep 2005 11:00:05 +0000 : Bèr Kessels a heads up: I ma redoing the patch. But decided no to change the name yet. That is a too big change. IT should be in a separate issue, IMO. ------------------------------------------------------------------------ Fri, 09 Sep 2005 15:27:43 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_2.patch (13.57 KB) * Bugs as reported by dries fixed. * The [add] tab not appearing is due to your menu caching, refresh that please. * Fixed an additional bug: Some agents do not send TRUE for disabled checkboxen. Also in current filter admin. and people: we have a problem. Deleting a filter trows errors, due to the revisions changes. that happens in filter module now, but also after this patch. I have too little knowledge of the filter system to fix that, and IMO that is a separate issue. It should be fixed right after this patch is committed. ------------------------------------------------------------------------ Fri, 09 Sep 2005 15:57:18 +0000 : Bèr Kessels FYI: the delete bug is waiting here: http://drupal.org/node/30781 ------------------------------------------------------------------------ Fri, 09 Sep 2005 18:18:17 +0000 : m3avrck Get this warning in PHP5: Warning: Missing argument 1 for filter_admin_format() in \modules\filter.module on line 379 I have traced this error back to line 240. Why are there no callback arguments like above on line 235? Looks like a source of a problem/bug here so needs to be addressed, not sure exactly how to fix it myself (otherwise I would). Should be easy it seems. Also, for a quick and easy usability improvement, on line 239, change t('list') to t('view') ... makes the menus less confusing. After those fixes, looks like this patch is ready to be committed :) ------------------------------------------------------------------------ Fri, 09 Sep 2005 18:23:27 +0000 : m3avrck Also, this dialog is a bit confusing: "Choose which roles may use this filter format You are editing the default format. For the default format, all roles must be enabled. Therefore you cannot change them. " Maybe make it so that first line doesn't appear there on that page? ------------------------------------------------------------------------ Tue, 13 Sep 2005 13:35:50 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_2_0.patch (13.59 KB) changed that line of help. Can this please still be taken in consideration before the freeze? ------------------------------------------------------------------------ Tue, 13 Sep 2005 18:29:28 +0000 : m3avrck Can't apply patch, getting error: Patch malformed at line 287 ------------------------------------------------------------------------ Tue, 13 Sep 2005 19:10:07 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements_2_0.patch (14.19 KB) strange. the dowloaded one breaks too, yet the one i uploaded stll works. anyway, rerolled ------------------------------------------------------------------------ Tue, 13 Sep 2005 19:25:25 +0000 : Dries IMO, the form function needs more work. You need to group the form construction and the form saving. Right now, when you don't provide a title, you are given an error and an emptied form. This may be a left-over from the original code though but it would be cool if you could tidy this up. The form_group() description still need a trailing point. There is a broken link in the following help text on the 'add input format'-page: /If you notice some filters are causing conflicts in the output, you can [rearrange] them./. ------------------------------------------------------------------------ Tue, 13 Sep 2005 19:30:12 +0000 : Bèr Kessels dont have time anymore. sorry. ------------------------------------------------------------------------ Tue, 13 Sep 2005 20:50:34 +0000 : m3avrck new patch soon! ------------------------------------------------------------------------ Tue, 13 Sep 2005 22:10:25 +0000 : m3avrck Attachment: http://drupal.org/files/issues/filter.module_10.patch (20.27 KB) Ok here's a new patch. Lot's of fixes in this one (all of the ones from above except the one noted below), including support for the new revisions patch. Additionally, 'input formats' has been renamed to 'input filters'. After debate on IRC, and the above comments in this post, it seems that 'input formats' is somewhat misleading and doesn't make sense. 'input filters' clears this up and makes sense to both native and non-native English speakers (as tested in IRC anywho ;)). This also makes more sense since Drupal refers to everything as 'filters' and not 'formats'. However, there is one issue still left unresolved: If you create a new input filter, and don't specify a title, page reloads clearing all filled in fields and prompts the error message. Additionally, a blank filter is created. Wanted to get this patch posted, I'll look at it later today but if someone can get this fixed easily, please do, thanks! ------------------------------------------------------------------------ Tue, 13 Sep 2005 22:38:05 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/filter_interface_improvements_3.patch (21.49 KB) this patch should fix the issue m3 rasies abuot amepty formats being created. Yes, i use a simple drupal_goto, in case of a for error. And no, it is not very easy to get the old posted data back. ------------------------------------------------------------------------ Tue, 13 Sep 2005 23:44:26 +0000 : moshe weitzman the most visible place for this 'input format' term is on the node form. thats where ordinary users see this stuff. in that context, i don't think 'input filters is an improvement over input formats. the question we are asking our users is 'what is the format of your post'?, not what filters do you want applied ... just my .02. sorry i wasn't in IRC when this came up. this need not hold up the whole patch. ------------------------------------------------------------------------ Wed, 14 Sep 2005 06:48:03 +0000 : Bèr Kessels Moshe. I agreed with you, and was against the name change. In this patch at least. However, it slipped in. Stetting code to be committed for it has gone trough so many review cycles that this patch has MUCH better code than the rest of the filter module, which REALLY needs a big overhaul :) ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:37:27 +0000 : Dries Are you saving the data before validating it? If we want to convert this form to the new form API, we have to fix this cleanly. Sorry. I agree with Moshe that 'input filters' is suboptimal. People want to select how their text is going to be /processed/. The word/filter/ sounds rather technical to me. Also, the difference between a single filter and a set of filters becomes rather blurry to the point it could be very confusing. ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:41:42 +0000 : m3avrck Well I was the one that changed 'input filters' to 'input formats' as that seemed to be the best thing we could come up. I guess it got confusing because people wanted this to change but maybe not in this patch. So I will revert that change in a forthecoming patch. Additinally, this patch is *not* ready. I was going through the form logic last night and it is a bit off, hence why errors are displayed along side a an empty form. I'm going to work as hard as I can and as fast to clean this patch up like I mentioned I would yesterday. I'll have some ready soon enough that will be commit worthy. ------------------------------------------------------------------------ Wed, 14 Sep 2005 14:22:41 +0000 : Bèr Kessels according to me its a go or leave. if m3 or anyone else wants to take over fine. I am out. no time.

1 0

[drupal-devel] [feature] Block query consolidation
by Allie Micka 14 Sep '05

14 Sep '05

Issue status update for http://drupal.org/node/30801 Post a follow up: http://drupal.org/project/comments/add/30801 Project: Drupal Version: 4.6.0 Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Allie Micka Updated by: Allie Micka Status: patch (code needs review) Attachment: http://drupal.org/files/issues/block_query.patch (1.25 KB) The blocks module is running a separate query for each region, e.g.: SELECT * FROM blocks WHERE theme = 'bluemarine' AND status = 1 AND region='left' ORDER BY weight, module SELECT * FROM blocks WHERE theme = 'bluemarine' AND status = 1 AND region='right' ORDER BY weight, module SELECT * FROM blocks WHERE theme = 'bluemarine' AND status = 1 AND region='header' ORDER BY weight, module SELECT * FROM blocks WHERE theme = 'bluemarine' AND status = 1 AND region='footer' ORDER BY weight, module Ultimately, we're going to need all of these so let's save a few queries. I have changed the query to: SELECT * FROM blocks WHERE theme = 'bluemarine' AND status = 1 ORDER BY region, weight, module And set all results to the static $blocks array on the first pass. Allie Micka

6 23

[drupal-devel] [feature] Comment approval queue a pain to use
by Dries 14 Sep '05

14 Sep '05

Issue status update for http://drupal.org/node/28595 Post a follow up: http://drupal.org/project/comments/add/28595 Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: mrowe Reported by: robertDouglass Updated by: Dries -Status: patch (code needs review) +Status: patch (code needs work) - Don't use tabs. - SQL queries might be vularnable to SQL injection attacks. Use db_query()'s %s and %d directives. Dries Previous comments: ------------------------------------------------------------------------ Wed, 10 Aug 2005 08:29:14 +0000 : robertDouglass When using the comment approval queue the workflow for approving comments is awful. You have to click administer->comments->approval queue to get a list of comments awaiting approval. Then you have to click edit on one of the comments, click the collabsible field-set for the publishing controls, click to published and save the comment. Then repeat the process for the next comment. I'd say that this workflow is a significant deterrent to anyone using this functionality. To make it better, there would be checkboxes next to each comment in the table on the approval queue page, and a set of operators analogous to the content overview page. Better yet would be if each comment in the table was an AJAX link to the comment's body and info which would expand right there in the table itself, since it is usually impossible just from the comment title to know whether to publish or not. If one could click the various comments open, right there in the table, then mass publish or delete, we'd have a real approval queue. Perhaps the spam module could tie into the actions that can be taken on comments so a mass "mark as spam" could be done too. ------------------------------------------------------------------------ Wed, 14 Sep 2005 13:32:47 +0000 : mrowe Attachment: http://drupal.org/files/issues/comment_bulk_approval.patch (2.24 KB) Here's a patch (against HEAD) that gives you the cheap-and-dirty approach (checkboxes that allow bulk approval/unapproval of comments). I'll leave the gold-plated AJAX solution to someone with more time. :)

1 0