On some pages (for example, "do you really want to do XYZ" confirm forms), the "add to shortcuts" link looks confusing and out of place. See the attached screenshot (inspired by #609122: shortcut_set_save() no longer deletes existing links when a new set of links is passed in), which shows a particularly confusing example...

It would be nice if we had some good way to hide those on a page by page basis.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jim0203’s picture

There doesn't seem to me to be anything intrinsic to particular pages to say whether they should have an "add to shortcuts" link - so it is overly simplistic to add a line near the top of shortcut_page_build() like:

if (!shortcut_check_link($link)) {
  return;
}

Where shortcut_check_link() is a new function which returns TRUE if the link should be displayed and FALSE otherwise? Then all the different conditions could be bundled into that function.

webchick’s picture

This is still an issue. I think the wrapper function makes sense, I'm just not sure what would go inside it. Confirmation forms, for sure. What else?

Bojhan’s picture

Confirmation forms
Admin/config/system/shortcut/
All top level sections

That's all I could think of, the last is somewhat questionable but apart from Dashboard and Content I see no reason why one would duplicate these links.

bleen’s picture

subscribe

casey’s picture

Status: Active » Needs review
FileSize
1.75 KB

Status: Needs review » Needs work

The last submitted patch, shortcut-hide.patch, failed testing.

casey’s picture

Status: Needs work » Needs review
FileSize
1.85 KB
bleen’s picture

Issue tags: +Needs tests

tagging ... I'll volunteer to write the tests once we have a working patch

David_Rothstein’s picture

Status: Needs review » Needs work

Looks like a good start! Although since showing the button is the most common case, I think the logic should be reversed - i.e., I would call the function shortcut_hide_add_remove_button().

And for this:

+  if (isset($page['content']['system_main']['#type'], $page['content']['system_main']['#theme'])
+    && $page['content']['system_main']['#type'] == 'form' && $page['content']['system_main']['#theme'] == 'confirm_form') {

I realize this is hard to detect, but I don't think we want to assume a particular location in the $page array, or base it off the theme function - both of those can easily be different.

To solve this, can we put this in an #after_build function attached to all forms, perhaps? (The overlay module does this, for example.) Then, to identify the confirm form, maybe something as simple as modifying the confirm_form() function to set $form['#confirm_form'] = TRUE, which gives us a clean thing to check for. I think there are other modules besides this one that might want to react to a confirm form, so this would be of general use.

Otherwise, I think this makes sense - it is probably the best we're going to be able to do. I wonder if there are some confirm forms where it wouldn't make sense to do this, but can't think of any off the top of my head, and in the worst case, they can always find a way to add it back via the API function that the patch provides...

casey’s picture

Status: Needs work » Needs review
FileSize
1.81 KB

I think we should only hide the shortcut button if the page main content is a confirm_form (not when there is a confirm_form somewhere else on the page).

David_Rothstein’s picture

Some modules (e.g. Panels) might have a different concept of the "main page content" than Drupal core does, so I don't think we should hardcode it to an area of the page array like that.

From the user's perspective, what is a scenario where a confirm form would appear on the page but not be the main intended focus of the page? I can't think of too many situations like that ... that's why I suggested just determining it based on the presence of the form anywhere on the page. (I guess there are AJAX-y scenarios where that might happen, but if the confirm form is being added via AJAX, then it won't really affect us here anyway.)

Status: Needs review » Needs work

The last submitted patch, shortcut-hide.patch, failed testing.

Bojhan’s picture

Status: Needs work » Closed (won't fix)

Lets won't fix this, I dont think its likely users will do this purposely anyway - its only a side affect of the badly placed shortcut icon.