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'

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

SteveBayerIN’s picture

Component: base system » filter.module
SteveBayerIN’s picture

Title: Please rename operation in Input Formats from 'Configure' to 'View Settings' » Please rename operation in Input Formats from 'Configure' to 'View Configuration'

I 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));

keith.smith’s picture

Title: Please rename operation in Input Formats from 'Configure' to 'View Configuration' » Rename operation in Input Formats from 'Configure' to 'View Configuration'

If 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)?

SteveBayerIN’s picture

The 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.

keith.smith’s picture

OK. 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.

SteveBayerIN’s picture

I just added that (in a more recent edit before seeing your query) to the post above:

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.

SteveBayerIN’s picture

I 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));

keith.smith’s picture

Cool. Make a patch. IMHO, it would be A Good Thing(tm).

SteveBayerIN’s picture

Awesome!

SteveBayerIN’s picture

Status: Needs review » Active
FileSize
1.07 KB

Drupal 5.7 Patch

Manually changing the line works on a live site, I haven't tested it using auto patching.

SteveBayerIN’s picture

FileSize
1.06 KB

Drupal 6.0 RC 4 Patch

Same as above, manually changing the line works on a live site, yet to be tested using auto patching.

SteveBayerIN’s picture

FileSize
1.06 KB

Patch for Drupal Head (I'm assuming head patches make it to Drupal 7)

SteveBayerIN’s picture

Status: Active » Needs review
keith.smith’s picture

Version: 7.x-dev » 6.x-dev
Category: feature » bug
Status: Active » Needs review

While 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.

Bevan’s picture

Status: Needs review » Needs work

Patch 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.

SteveBayerIN’s picture

Version: 6.x-dev » 6.0
Status: Needs work » Needs review
FileSize
1.08 KB

Here'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)

Bevan’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
1.16 KB

Hmm. 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.

keith.smith’s picture

Version: 6.0 » 7.x-dev

Unfortunately, this didn't get into Drupal 6 before release, so we'll try for 7.x-dev (and work backwards, if Gabor chooses).

SteveBayerIN’s picture

Thanks for fixing up the patch.

I wouldn't mind which release the patch gets integrated into.

webchick’s picture

Component: filter.module » user interface text
ScoutBaker’s picture

@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.

SteveBayerIN’s picture

Well 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.

ScoutBaker’s picture

@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.

Dries’s picture

Status: Reviewed & tested by the community » Postponed

I 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.

keith.smith’s picture

FileSize
1.51 KB

Attached 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.

Gábor Hojtsy’s picture

Status: Postponed » Needs review

I 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.

Status: Needs review » Needs work

The last submitted patch failed testing.

lilou’s picture

Status: Needs work » Needs review
catch’s picture

Status: Needs review » Reviewed & tested by the community

The change is good and filter tests pass.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.