When a site admin goes to Admin>Site Configuration>Input Formats (admin/settings/filters) and choses the configure option for a input format, the admin lands on the view page instead of the configure page and has to click configure one more time on the horizontal tabs to get to the configure page. It is a bit disorientating and first time users could believe they are on the configure page when they are actually on just the view settings page.
To avoid heavy changes, I think the Operation on the workflow of Admin>Site Configuration>Input Formats (admin/settings/filters) could be renamed from 'Configure' into 'View Settings'
Comment | File | Size | Author |
---|---|---|---|
#25 | 219584.patch | 1.51 KB | keith.smith |
#17 | 219584.patch | 1.16 KB | Bevan |
#16 | filterep6.patch | 1.08 KB | SteveBayerIN |
#11 | filtermodule6RC4-sjb.patch | 1.06 KB | SteveBayerIN |
#10 | filtermodule57-sjb.patch | 1.07 KB | SteveBayerIN |
Comments
Comment #1
SteveBayerIN CreditAttribution: SteveBayerIN commentedComment #2
SteveBayerIN CreditAttribution: SteveBayerIN commentedI changed the component from base system into filter.module
in Drupal 5.6 line 318 in forum.module can be changed from:
-- $form[$format->name]['configure'] = array('#value' => l(t('configure'), 'admin/settings/filters/'. $id));
++ $form[$format->name]['configure'] = array('#value' => l(t('view configuration'), 'admin/settings/filters/'. $id));
Comment #3
keith.smith CreditAttribution: keith.smith commentedIf I click on "configure" for Full HTML, I can change the name, choose roles, what filters are applied, etc. Why would "view" (which really implies a read-only kind of thing) be more appropriate (since you really can do more than just view, here)?
Comment #4
SteveBayerIN CreditAttribution: SteveBayerIN commentedThe main reason behind the request for the name change is because after a user clicks configure (in operations on admin/settings/filters), the user lands on the view page in Drupal 5.x (edit page in Drupal 6.x) which has another tab called configure next to view tab (for Drupal 5.6 or edit for Drupal 6.x)
If the user were to click on configure operation in admin/settings/filters they should land on the page with the configure tab highlighted or the operation title (configure) should be renamed according to the page the user lands on after clicking (view for 5.6, edit for 6.0.)
While configure is a better description of whats on the page/form/node, the user should then land on a page/form/node that is titled configure instead of a view or edit page.
The names of the pages that the user lands on right now is can remain unchanged and the settings they have access can remain unchanged on that page, its the title of the operations link (on admin/settings/filters) that needs to be renamed with the title of the page to which the link leads to.
As in Drupal 6.0, edit is a better title for the page than the title of view in Drupal 5.6
If title Edit was carried over to Drupal 7, then the operation title in admin/settings/filters should be renamed from configure to edit.
Comment #5
keith.smith CreditAttribution: keith.smith commentedOK. That sounds reasonable. But, for D6 and beyond, why not change the "configure" on /admin/settings/filters to "edit" so that it will match the highlighted tab when one clicks it.
Comment #6
SteveBayerIN CreditAttribution: SteveBayerIN commentedI just added that (in a more recent edit before seeing your query) to the post above:
Comment #7
SteveBayerIN CreditAttribution: SteveBayerIN commentedI made the suggestion for the operation title of view after checking the page title in 5.6 but before checking the title of the page in Drupal 6.0
After looking at Drupal 6.0, the operation title of edit sounds more reasonable.
line 34 of filter.admin.inc
-- $form[$format->name]['configure'] = array('#value' => l(t('configure'), 'admin/settings/filters/'. $id));
++ $form[$format->name]['configure'] = array('#value' => l(t('edit'), 'admin/settings/filters/'. $id));
Comment #8
keith.smith CreditAttribution: keith.smith commentedCool. Make a patch. IMHO, it would be A Good Thing(tm).
Comment #9
SteveBayerIN CreditAttribution: SteveBayerIN commentedAwesome!
Comment #10
SteveBayerIN CreditAttribution: SteveBayerIN commentedDrupal 5.7 Patch
Manually changing the line works on a live site, I haven't tested it using auto patching.
Comment #11
SteveBayerIN CreditAttribution: SteveBayerIN commentedDrupal 6.0 RC 4 Patch
Same as above, manually changing the line works on a live site, yet to be tested using auto patching.
Comment #12
SteveBayerIN CreditAttribution: SteveBayerIN commentedPatch for Drupal Head (I'm assuming head patches make it to Drupal 7)
Comment #13
SteveBayerIN CreditAttribution: SteveBayerIN commentedComment #14
keith.smith CreditAttribution: keith.smith commentedWhile this (the patch for Drupal 6) is past string freeze, it uses the same string ("edit") as, say, menu items on admin/build/menu-customize/navigation page (and possibly others).
As stated, it does clear up the confusion where one clicks on "configure", but lands on a page named "Edit", where a "Configure" tab is also shown, but not selected.
Since it removes a usability problem without inconveniencing translators, I'm moving this to a 6.x bug report.
Comment #15
Bevan CreditAttribution: Bevan commentedPatch should to be created from root of drupal so that it can be applied from the root of drupal.
Otherwise this applied cleanly, fixes said bug, and is RTBC IMO.
Comment #16
SteveBayerIN CreditAttribution: SteveBayerIN commentedHere's the patch for Drupal 6.0
I think its created in root. I went with the instructions on http://drupal.org/node/113172 for the earlier patches. For the latest patch I opened the drupal folder, right clicked the whitespace on the window and then chose CVS>Patch using Tortoise CVS.
The patch should be ready to commit if it can be applied from root. I'd like to thank Greggles for letting me know how to get started with patching (http://groups.drupal.org/node/8745)
Comment #17
Bevan CreditAttribution: Bevan commentedHmm. I'm not sure what command your using or where from, but when I apply your patch from drupal root with
www $ patch -p0 < filterep6.patch
, patch asks me where filter.admin.inc is and I have to specify modules/filter/filter.admin.inc.I created this patch with
www $ cvs diff -up modules/filter > 219584.patch
and it applies fine without needing me to specify the location of filter.admin.inc. I hope that helps.I didn't make any code changes in this patch.
Comment #18
keith.smith CreditAttribution: keith.smith commentedUnfortunately, this didn't get into Drupal 6 before release, so we'll try for 7.x-dev (and work backwards, if Gabor chooses).
Comment #19
SteveBayerIN CreditAttribution: SteveBayerIN commentedThanks for fixing up the patch.
I wouldn't mind which release the patch gets integrated into.
Comment #20
webchickComment #21
ScoutBaker CreditAttribution: ScoutBaker commented@SteveJB: TortoiseCVS doesn't create patches from the root in the way that they refer to it here. Yes, it does start from the root of the directory structure and will create patches for all of the changed files. However, it doesn't include the pathing in the patch file indicating the directory where the file being patched is located. I haven't found any way to change the settings for this functionality.
Comment #22
SteveBayerIN CreditAttribution: SteveBayerIN commentedWell Scoutbaker, Tortoise was the quickest way to make a patch. I'd rather have a somewhat working patch out right now (that could be tested and adapted into a working patch) rather than wait around till I am able to work with WinCVS.
WinCVS seems to be the best for patching from windows. Tortoise was used to get a patch out ASAP and as quick and easy to use as it is, it isn't as functional as WinCVS.
Comment #23
ScoutBaker CreditAttribution: ScoutBaker commented@SteveJB: I was not judging the patch, I was merely providing information about the functionality of TortoiseCVS that I had discovered in my own use of that tool. In #16 you seemed unsure, and Bevan mentioned it in #17.
Comment #24
Dries CreditAttribution: Dries commentedI want to hold of committing this patch until http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drup... lands. Gabor is making some additional UI changes to the input formats so I'd recommend that you follow up with him.
Comment #25
keith.smith CreditAttribution: keith.smith commentedAttached is a rerolled patch, changing the "configure" link to "edit" so that it conforms with the default tab on the linked page.
I'm going to ask Gabor to comment here; and will leave this marked 'postponed' until he decides to change it.
Comment #26
Gábor HojtsyI think this is a simple improvement which is not in the way of any other improvements planned. Drupal 6+ indeed says "Edit" on this page, so linking to that as "edit" seem to be most logical to do.
Comment #28
lilou CreditAttribution: lilou commentedSee: #335122: Test clean HEAD after every commit and http://pastebin.ca/1258476
Comment #29
catchThe change is good and filter tests pass.
Comment #30
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks! :)