Ticket #11189 (assigned Bug)

Opened 5 years ago

Last modified 3 years ago

Link objects do not open in a new window

Reported by: cwainwright Owned by: fulviocasali
Priority: minor Milestone: 4.x
Component: JavaScript Version: 4.2
Keywords: TuneUp Cc: TuneUp, greenbelt, gbastien@…, bryanw, fulv

Description

from #10305, created this ticket for Plone 4

If 'External links open in new window' has been turned on in Site Setup, this does not work on the Link type.

Attachments

diffs.patch Download (2.8 KB) - added by gbastien 5 years ago.
Apply this using "patch -p0 < diffs.patch" in plone/app/portlets/portlets
cmfplone-11189_partialpatch.diff Download (3.2 KB) - added by fulviocasali 5 years ago.

Change History

comment:1 Changed 5 years ago by jessilfp

  • Keywords TuneUp greenbelt added

comment:2 Changed 5 years ago by gbastien

  • Cc TuneUp, greenbelt, gbastien@… added; TuneUp greenbelt removed

comment:3 Changed 5 years ago by gbastien

We had that need and we solved it in the navigation portlet by applying the patch I attached. We just changed 5 lines as the getRemoteUrl is already available in the passed dict but not used... Apply the patch in plone/app/portlets/portlets with a Plone4.0.1 instance...

Changed 5 years ago by gbastien

Apply this using "patch -p0 < diffs.patch" in plone/app/portlets/portlets

comment:4 Changed 5 years ago by gbastien

Or maybe would it be possible to apply the javascript that do the work for page content to the entire page, not just the content? So link that would appear anywhere in the site (navigation, portlets, ...) would open in a new window if necessary...

Happy new year to everyone! ;-)

comment:5 Changed 5 years ago by msmith64

  • Owner set to msmith64

comment:6 Changed 5 years ago by fulviocasali

  • Owner changed from msmith64 to fulviocasali
  • Status changed from new to assigned

Changed 5 years ago by fulviocasali

comment:7 follow-up: ↓ 8 Changed 5 years ago by fulviocasali

Bryan Wilson and I worked on this today and have a fix for the global sections viewlet.

Here is a table of all the places we could think of where a Link content object might be listed. Respects can_edit means that when a user has permission to edit the Link content object, clicking it should load the normal content object view, instead of loading the URL stored in the Link. Respects new_window means that clicking the link opens a new window loading the URL stored in the Link (provided the box for External links open in new window is checked in Theme Settings, and the user is anonymous, or has no permission to edit the Link).

Context Priority Respects can_edit Respects new_window
global sections viewlet High Yes No
nav portlet High Yes No
live search Medium Yes No
search results Medium Yes No
folder_listing Low Yes No
folder_contents Low Yes N/A
collection views Low Yes No
collection portlet Low Yes No
recent changes portlet Low Yes N/A
site map Works Yes Yes

The context marked N/A in the 4th column are only available for logged-in users, so the external URL would never be loaded, anyway.

There is a javascript in Products.CMFPlone called mark_special_links.js, which appends a target="_blank" to all links on a page that point to an external URL (if that setting is enabled). This script itself is also disabled in the portal_javascript registry if the setting is disabled.

This suggests a possible solution, which we have implemented for the global_sections viewlet: for Link content objects, use the remote URL in the href instead of the Link object's own URL. Then the mark_special_links.js will make it open in a new window. Then the only logic required is to decide whether the current user should be able to edit the Link object or not.

The way the sitemap does it is by checking whether the current user is the owner of the Link object. Presumably, this is done because the Creator attribute is available on the brains, so it's inexpensive. Waking up the object to check whether the user has edit permissions on it seems like it would be too expensive. Thus, we have followed the same approach in the global_sections viewlet.

By the way, the diffs.patch attached by gbastien on Nov 4, 2010 uses a different logic: it checks whether the user can edit the current context, not the Link object.

comment:8 in reply to: ↑ 7 Changed 5 years ago by bryanw

  • Cc bryanw added

adding myself for cc:s

comment:9 Changed 5 years ago by fulviocasali

  • Cc fulv added

adding myself for cc:s

comment:10 Changed 4 years ago by fulviocasali

  • Keywords TuneUp50 added

comment:11 Changed 4 years ago by fulviocasali

Submitted the following pull requests:

This fixes the two scenarios estimated to be highest priority above, namely global sections viewlet and navigation portlet.

I can keep working on the other scenarios before we resolve this closed.

comment:12 Changed 3 years ago by eleddy

  • Keywords greenbelt TuneUp50 removed
  • Version set to 4.2
Note: See TracTickets for help on using tickets.