- Development - lists.drupal.org

[drupal-devel] [task] merging feedback.module into contact.module
by Tobias Maier 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/27633 Post a follow up: http://drupal.org/project/comments/add/27633 Project: Drupal Version: cvs Component: contact.module Category: tasks Priority: normal Assigned to: Anonymous Reported by: Tobias Maier Updated by: Tobias Maier -Status: active +Status: patch Attachment: http://drupal.org/files/issues/contact.module_2.patch (11.02 KB) contact.module updated again -->now it runs :D Tobias Maier Previous comments: ------------------------------------------------------------------------ Wed, 27 Jul 2005 23:00:09 +0000 : Tobias Maier The contact.module of the Drupal HEAD does now nearly the same as the feedback.module. kbahey [1] and I talked about to bring them together. To have just one module. a) Here comes a list of features which you can find in feedback.module and which are currently missing in contacts.module * add the following fields to contacts.module: * Postal Address * Phone Number * A real "Message Subject" (You say "What?? we have one!" - this one is used in the false way. Be patient i'll tell you later what i mean) * make it configurable if these fields are shown on the /Sites Contact-Page/ and/or on the /Users Contact-Page/ * Make it configurable which field is required and which one not * The Subject field is currently used to select on which team/department the message belongs to. this field should be renamed to /topic/category/department/ (just one of them / maybe let the user decide) and a Subject field with the default behavour should be introduced. * let the "Additional information:"-field be formatted. So add form_format() * Feedback has a feature "Log all feedback attempts to watchdog" * it also allows you to add an special "Subject Prefix:" to the e-mail which will be sent. * and to customize the Message which will be shown after the user pressed submit. ("Result Message - Success". "Result Message - Failure") (personally i think this is not really needed) * it also allows you to define a "Navigation link text" and a "Feedback Page Header" - but the most users (including me) were a little bit confused about what that means (personally i think this is not really needed) b) here comes my list what i want to see beside the things mentioned above in contact.module: * why does contact have two places to configure it (/admin/contact/ and /admin/settings/contact/) i think they should be merged into one. So that it is easier for the User to get into this. * Help texts, everywhere :D * a new permission:"Let me use all Users Contact page" - allow specific Roles to contact the User through the Contact-Page, also if he deactivated it Please tell me what you think about it and if you have other ideas. I want to start to merge the feedback module into the contact module soon Yours sincerely Tobias Maier [1] http://drupal.org/user/4063 ------------------------------------------------------------------------ Thu, 28 Jul 2005 08:40:21 +0000 : Tobias Maier i forgot to mention that it also sends the referrer in the E-Mail what I also want to include ------------------------------------------------------------------------ Thu, 28 Jul 2005 10:30:36 +0000 : lennart Hi Tobias, I am currently using both feedback.module and contact.module, so for me a merging would generally make sense. I agree with most of your ideas /except/; I do not think " the Message which will be shown after the user pressed submit. ("Result Message - Success". "Result Message - Failure") " is not needed. I think this should stay. It gives comfort and certainty to the user to know that the mail has been sent succesfully Regards Lennart ------------------------------------------------------------------------ Thu, 28 Jul 2005 10:48:13 +0000 : Tobias Maier i think also that this messages should stay there, but I think they don't have to be customizable, like in Feedback. ------------------------------------------------------------------------ Thu, 28 Jul 2005 13:03:54 +0000 : kbahey Tobias, Thanks for the comparison. As the author of Feedback, I see a lot of overlap between contact and feedback. I would like to see them merged, and become part of core. contact is a good base to build on, and has some extra features (most importantly the ability to contact a specific user, as well as list different topic/category and route the message accordingly (think of sales, support, marketing, ..etc or complaint, comment, request, ...etc.) Add to all that one feature present to neither: a checkbox to send a copy of the email to the originator for filing. If both merge and add the above feature, I will be very happy, and feedback can then rest in peace starting from 4.7. ------------------------------------------------------------------------ Sat, 30 Jul 2005 02:32:58 +0000 : Tobias Maier here are the first patches regarding this: * [bugfix] if contact.module is unconfigured the form gets shown [2] * [bugfix/new feature] hide subject if there is just one [3] * [new feature] input format for contact.module [4] * [bugfix] Side-wide contact form: doesn't save entered text on input error reload [5] please test them all and integrate them all as fast as possible, because i want to develop the next steps on top of them Thanks [2] http://drupal.org/node/27757 [3] http://drupal.org/node/27822 [4] http://drupal.org/node/27824 [5] http://drupal.org/node/27139 ------------------------------------------------------------------------ Sat, 30 Jul 2005 13:30:40 +0000 : Tobias Maier Attachment: http://drupal.org/files/issues/contact.module_1.patch (10.38 KB) and here comes the first all-in-one patch: please try it, and tell me if it works for you: This is just the first step to solve the list above so there come much more enhancements later... Changelog: * Includes bugfix: if contact.module is unconfigured the form gets shown [6] * includes bugfix: if contact.module is unconfigured the form gets shown [7] * includes bugfix: Side-wide contact form: doesn't save entered text on input error reload [8] * renamed subject to category * added a real Subject-field * includes input format for contact.module [9] * includes hide subject if there is just one [10] * changes in contact-table (just MYSQL) * subject renamed to category * category is now PRIMARY KEY [6] http://drupal.org/node/27757 [7] http://drupal.org/node/27757 [8] http://drupal.org/node/27139 [9] http://drupal.org/node/27824 [10] http://drupal.org/node/27822 ------------------------------------------------------------------------ Sat, 30 Jul 2005 13:31:33 +0000 : Tobias Maier Attachment: http://drupal.org/files/issues/database.mysql_5.patch (720 bytes) the patch for the mysql-table

1 0

[drupal-devel] [bug] Don't import global $theme in bluemarine's page.tpl.php
by Dries 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/27784 Post a follow up: http://drupal.org/project/comments/add/27784 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: Dries Status: patch Is there any theme that uses the $theme variable? Only bluemarine seems to be using it and according to http://drupal.org/node/27791 it might be dead code. Dries Previous comments: ------------------------------------------------------------------------ Fri, 29 Jul 2005 17:07:53 +0000 : robertDouglass Attachment: http://drupal.org/files/issues/global_theme_patch.txt (1.9 KB) It seems like bad style to use <?php global $theme ?> in .tpl.php files. If $theme is needed in the page template, let's send it in as a variable so that it is consistent across all themes.

1 0

[drupal-devel] [bug] Simple patch to bootstrap.inc
by kubaZygmunt 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/27845 Post a follow up: http://drupal.org/project/comments/add/27845 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: kubaZygmunt Updated by: kubaZygmunt Status: patch Attachment: http://drupal.org/files/issues/bootstrap.inc_3.patch (508 bytes) I added patch which elimitate error: Notice: Undefined index: count in **\includes\bootstrap.inc on line 38 kubaZygmunt

1 0

[drupal-devel] [bug] Pushbutton doesn't handle primary and secondary links correctly.
by robertDouglass 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/27844 Post a follow up: http://drupal.org/project/comments/add/27844 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: robertDouglass Status: patch Attachment: http://drupal.org/files/issues/pushbutton_prim_secondary_links.txt (1.29 KB) The current foreach in the page.tpl.php of Pushbutton results in one pipe too many |. It also complicates the template with too much logic code. This patch uses the same method that Bluemarine uses, which produces better results. robertDouglass

1 0

[drupal-devel] [feature] Add CSS id for each forum on top-level forum page.
by leafish_dylan 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/27776 Post a follow up: http://drupal.org/project/comments/add/27776 Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: leafish_dylan Reported by: leafish_dylan Updated by: leafish_dylan Status: patch Attachment: http://drupal.org/files/issues/forum.module_4.patch (1.14 KB) Here's a patch that gives each forum a CSS ID on the top level (www.whatever.com/forum) page. The wrapper div that indents the sub-forums now contains an ID of the format "forum-forum-$tid", similar to the block ids. This will allow customisation of the forum display. It will allow themes to add forum icons using background-images, which is a popular feature of other forum software, or could be used to highlight a support/FAQ forum in some way. leafish_dylan

2 4

[drupal-devel] [feature] New API function: truncate_utf8_conc
by Bèr Kessels 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/21576 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/common_inc_truncate_utf8_conc.diff (1.63 KB) This function truncates the string, but adds a string to the end, when requested. For example to concenate three dots (...) to a long username. For example to turn the long username * johndoe(a)www.personalweblog.com into johndoe(a)www.johndo... Its possible with the current truncate_utf8(), but than you need to do string comparison and some more truncation afterwards, which is not optimal. And please mark this as wontfix if not appropriate. I do not have time to maintain this patch, so if its not up to standards or so, just close this issue. Bèr Kessels

4 10

[drupal-devel] [bug] Side-wide contact form: doesn't save entered text on input error reload
by Tobias Maier 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/27139 Post a follow up: http://drupal.org/project/comments/add/27139 Project: Drupal Version: cvs Component: contact.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Tobias Maier Status: patch Attachment: http://drupal.org/files/issues/contact_saveenteredtext_0.patch (1.94 KB) this one is better Tobias Maier Previous comments: ------------------------------------------------------------------------ Wed, 20 Jul 2005 14:53:02 +0000 : m3avrck When using the site-wide contact form: click 'Add a subject' and type in just a subject, with no recieptents listed. Page will reload saying recieptents are required, yet will clear all text typed into the subject field. Form should preserve any data typed when page needs to reload because of an user input error. ------------------------------------------------------------------------ Sat, 30 Jul 2005 02:24:26 +0000 : Tobias Maier Attachment: http://drupal.org/files/issues/contact_saveenteredtext.patch (1.96 KB) here comes the patch :D it's part of http://drupal.org/node/27633

1 0

[drupal-devel] [task] Improvments to Filter UI
by robrechtj 30 Jul '05

30 Jul '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: Anonymous Reported by: Bèr Kessels Updated by: robrechtj Status: patch 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... robrechtj 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.

1 0

[drupal-devel] [task] Remove a useless form_group()
by drumm 30 Jul '05

30 Jul '05

Issue status update for http://drupal.org/node/27647 Post a follow up: http://drupal.org/project/comments/add/27647 Project: Drupal Version: cvs Component: throttle.module Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/throttle.module.diff (4.51 KB) The entire throttle settings page is enclosed in a single form_group(). That shouldn't happen since the title of the group and the border aren't doing anything to help scanability of the page. drumm

3 3

[drupal-devel] [task] Usability tweaks: INSTALL.txt, .htaccess, settings.php.
by Morbus Iff 29 Jul '05

29 Jul '05

Issue status update for http://drupal.org/node/18641 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch The following patches clear up a number of minor inconsistencies during a Drupal installation. Largely, this is related to internal documentation and "where things go", but should help organize, clearup, and ease the installation. These aren't features, so they're eligible for a 4.6 commit. The INSTALL.txt no longer contains the SERVER CONFIGURATION block. These settings are now hardcoded into sites/default/settings.php, and are merely scary technical junk here. The INSTALL.txt has been updated with the latest system requirements. A whole sentence was struck regarding differing versions of PHP for the OSs. The INSTALL.txt contains URLs to MySQL and PostgreSQL. If we're including the URL for PHP in the same sentence, then there's no reason why we wouldn't include them for the database engines. What are the minimal requirements for the RDBMS? Those should be included here too. The INSTALL.txt's OPTIONAL COMPONENTS has renamed to OPTIONAL REQUIREMENTS. The only difference between the meaning is the amount of user confusion. The INSTALL.txt has a new CONTENTS OF THIS FILE, in hopes that people will more immediately notice that there are upgrade instructions at the bottom. The INSTALL.txt had some potentially confusing lines adjusted, including further clarifications, standarding to "userid" (instead of using both userid and username interchangebly) and so on. I've moved most of .htaccess php_value's to the ini_set system for /sites/. There are a few reasons for this, chiefly that it is centralizing all the PHP setting modifications to one place. But, this also clears up a few initial configuration issues: first, the user doesn't have to worry about whether they have Apache 1 or 2, and whether they need to change an IfModule line. Also, the running assumption is that these php_value's are /going to work by default anyways/, when the INSTALL.txt suggests otherwise (under OPTIONAL REQUIREMENTS, it talks about "the ability to use local .htaccess files", which suggests that "local .htaccess files" INCLUDING "mod_rewrite" are entirely optional.) Some variables, however, had to remain in .htaccess because they can't be overridden at runtime, but the amount was so small that duplicating them for both Apache 1 and Apache 2 possibilities is no longer a prohibitive concern. There are two variables in .htaccess that I'm concerned about: track_vars, and allow_call_time_pass_reference. track_vars appears to be no longer necessary (as of 4.0.3, track_vars is /always/ on [1], and my setting it here had no impact on the results of a phpinfo), and allow_call_time_pass_reference seems, at least here, to ONLY WORK if the .htaccess value is set to "1", and not "On" - meaning that Drupal installations are currently working correctly with its default value (off). According to the PHP docs, this feature is now deprecated. However, since both of these variables require further investigation, track_vars has been moved to settings.php, and allow_call_time_pass_reference has been "fixed" to a 1 (not 'On'). Along with the changes above for sites/default/settings.php, I've also removed the spacing indent in the documentation, as well as many a few grammatical/punctuation changes here and there. I don't think the leading spacing is "right" according to the style guidelines, but maybe there's a special need for it. Correct me if I'm wrong. These patches were made during the exploration and customization of Drupal by NHPR.org. In loving support of open source software, NHPR.org will continue to contribute patches they feel the community will benefit from. [1] http://us3.php.net/session Morbus Iff

10 30