Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When configuring WYSIWYG profiles (/admin/config/content/wysiwyg/profile/[name]/edit) with IMCE WYSIWYG bridge enabled the IMCE label in the Buttons and plugins section is a link to http://drupal.org/project/imce
This is poor usability because it makes the label useless. The common user expectation is that clicking the label would check the checkbox, in this case the user is taken to drupal.org without any warning. The user is likely to be well aware of what IMCE is given that they have installed it already.
Comment | File | Size | Author |
---|---|---|---|
#7 | wysiwyg-remove_links_on_buton_labels-967400-7.patch | 1.69 KB | rocketeerbkw |
#6 | wysiwyg-967400-6-labels-fix.patch | 1.92 KB | helmo |
#5 | wysiwyg-967400-labels-fix.diff | 2.2 KB | skwashd |
#1 | imce_wysiwyg-967400-fix-labels.diff | 1.31 KB | skwashd |
Comments
Comment #1
skwashd CreditAttribution: skwashd commentedThe attached patch fixes this in 7.x-1.x-dev using current CVS.
Comment #2
sunNeeds to be fixed in Wysiwyg instead.
Comment #3
skwashd CreditAttribution: skwashd commentedI don't see why this needs to be fixed in WYSIWYG, the issue is with how the bridge prepares its label.
The attached patch deals with the problem in the bridge.
Comment #4
TwoDThe patch does not fix the usability problem you mention, it only avoids it by removing the URL stating where the plugin originates from. That information should still be there so Wysiwyg can inform users of this. A better approach would be patching Wysiwyg to not turn the labels into links - which is done for any plugin wrapper providing an URL - and show the link somewhere else.
Comment #5
skwashd CreditAttribution: skwashd commentedThe attached patch moves the fix into WYSIWYG. When the URL is specified it will display "Visit project page." as the #description for the checkbox. I have only tested it with IMCE and couldn't find any WYSIWYG button plugins for D7.
Unlike the the existing code, this version opens the link in a new window. I am not sure this is the best idea, but it keeps the intention of the existing code.
Comment #6
helmo CreditAttribution: helmo commentedI tried to re-roll this patch but ran into a problem.
I saw no effect from the #description attribute you are adding.
To get a similar result I now append a link to the #title attribute.
This results in something like: [] IMCE (project page)
Comment #7
rocketeerbkw CreditAttribution: rocketeerbkw commentedI've rerolled against 7.x-2.x HEAD and moved links back to checkbox
#description
.Comment #8
helmo CreditAttribution: helmo commented@rocketeerbkw: your new patch is missing the 'attributes' => array('target' => '_blank') part.
Are you opposed to using that?
I had also added 'title' => t('Visit project page.'), but that's less important ...
Comment #9
rocketeerbkw CreditAttribution: rocketeerbkw commentedI am (not strongly) opposed to
target=_blank
. It doesn't match the convention in other areas like the WYSIWYG Installation Instructions where links to editors open in the same page and on Available Updates "download" and "Release Notes" open in the same page.If the Links were next to the button name, I would keep "Visit project page," but now that they're on a separate line I think it's better that you can see the actual URL (this is a usability patch after all).
Comment #10
helmo CreditAttribution: helmo commentedI had "Visit project page" as title attribute, not the link text. Showing the url is indeed a good thing.
Comment #11
TwoDThe patch looks good and I like seeing the URL, as that should clearly indicate you are not going to stay within the site if you click that link. I just hope they won't become too long. Do we need to implement shortening of the displayed url or is that overkill?
I think the main thing that makes this form different from the forms on Installation Instructions, Available Updates, etc, is the sheer number of options you'd potentially have to go over again if you haven't saved before clicking the links. The amount of checkboxes does increase the risk of hitting a link by mistake. On the other hand, I don't like links which open in new windows by default either.
Comment #12
rocketeerbkw CreditAttribution: rocketeerbkw commented@helmo ahh I missed the title attribute, I thought you were talking about the
(project page)
link text. I guess I don't think it's necessary anymore with the link visible. And any URL can be placed there, could be to someones homepage, not a project page.@TwoD I was on a 900px wide monitor when I took the screenshot and I didn't think they were too long. What I hate about truncating is seeing a bunch of
http://drupal.org/project/...
links. Since the most important bit of d.o links is at the end and the most important part of any other link is the beginning.I could be convinced to open links in a new window if it's better UX on a settings page.
Comment #13
TwoDI was thinking about shortening them more like
http://drupal.org/.../wysiwyg
, to keep both ends intact, but yeah, that is starting to sound more like overkill anyway.So, to open or not to open in a new window? If we can't decide or argue for or against, let's just leave it the way it is and wait for someone with a stronger opinion. ;)
Comment #14
helmo CreditAttribution: helmo commentedLets indeed keep the link behavior like it is.
When we change that we should also change it in the Installation Instructions, so it would warrant a separate issue.
Comment #15
sunThanks for reporting, reviewing, and testing! Committed to 7.x-2.x.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.