When creating a campaign, if you go to "insert content" and add a node with a specific view mode, then the rendered html includes the contextual links of that node. This has been fixed on 77b677a, nevertheless, the patch fixes the bug partially, there's still a bug when there's an entity reference field on the content added.
Here's the steps to reproduce it:
1- Add a content type with an entity reference field
2- Create a display mode 'example_display' and display the entity reference field as Rendered Entity.
3- Create a node of that content type
4- Create a campaign and on a region hit on: insert site content, Entity Type = content, choose the created node, choose the created view mode ('example_display')
Then the output on MailChimp template renders the Contextual Links.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | mailchimp_campaign-contextual_links_in_display-2356065-7.patch | 1.7 KB | chiebert |
| #2 | contextual_links_in_display-2356065-2.patch | 1.19 KB | jpamental |
Comments
Comment #1
basvredelingThe campaign is rendered as the admin user who sent it or as user 1. Something like that. That's also why the campaign gets sent in the administration theme. We should probably try to do the whole newsletter rendering as an anonymous user (with the front-end theme).
Comment #2
jpamental commentedI can confirm this is still an issue in 3.11. I found a fix from 2.x here: https://www.drupal.org/node/1871726
In the Mailchimp Campaign module there is a comment around line 631 with code that is supposed to remove contextual links, but it's not working. I made a new patch that brings in the code from the older fix, and I just tested it and it worked perfectly to not display the contextual links in the rendered content.
Comment #3
jpamental commentedUpdating the version to 3.11 as it's still an issue there.
Comment #4
ruscoe commentedComment #5
chiebert commentedCurrently, as of 7.x-3.2+14-dev (2015-Jan-30), the outer layer of #contextual_links of embedded content are removed, but if the view mode itself also includes a further rendered entity (in my case it's a file_entity image), then that nested entity's #contextual_links are still rendered - unless the patch in #2 is applied, which simply renders the whole thing as an anonymous user.
The problem I can see with the simply forcing rendering as the anonymous user (as #2 does), is the use case where a Campaign includes content from, say, a private Organic Group, and is sent to a list segment that consists of members of that group. In this situation, I would want to render the content as user 1 - or at least as a member of the group - but still without the contextual links. Otherwise, wouldn't it refuse to render at all?
If someone follows a link in the Campaign email and doesn't have access to the content (i.e., isn't logged in, or whatever), then it's up to the site-builder to handle that business logic appropriately (e.g., use Login Toboggan or some such with an appropriate message).
So, I'd vote for not taking the approach of #2 (which is a re-roll of #1871726: Drupal Core's Contextual Links Module Must Be Turned Off for Campaigns to Work Properly from 7.x-2.x), but rather find a way to recurse through entities-within-entities, etc... Not that I know how to do that yet, but I'm working on it...
Comment #6
chiebert commentedComment #7
chiebert commentedOkay, here's a patch that simply expands on the existing (in -dev) approach to remove #contextual_links keys from the $render_array. I've added a helper function that recursively drills down through an array (passed by reference) and unsets a given key when found. Then I use that helper function instead of the existing single-layer unset(). I think this is a better approach, since it fixes the underlying issue (contextual links), and leaves the question of access as a separate issue - even a feature request, maybe...
Comment #8
Anonymous (not verified) commentedComment #10
Anonymous (not verified) commentedPatch works smoothly; has been committed to the
7.x-3.xbranch. Thanks everyone!