Ticket #11189 (assigned Bug)
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
Change History
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
-
attachment
diffs.patch
added
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:6 Changed 5 years ago by fulviocasali
- Owner changed from msmith64 to fulviocasali
- Status changed from new to assigned
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:11 Changed 4 years ago by fulviocasali
Submitted the following pull requests:
- https://github.com/plone/plone.app.portlets/pull/3
- https://github.com/plone/Products.CMFPlone/pull/5
- https://github.com/plone/buildout.coredev/pull/20
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.