When sending newsletter mails, if the subscriber is a user, this module switches to the user account for rendering the issue entity. This allows the output to vary, for example some users might see extra fields because they have a related permission.
The disadvantage of this is that it reduces performance, because the entity cannot be cached. In some cases, Drupal knows that the rendered entity could vary per user, so won't cache it, but the site admin knows that in reality there is no noticeable variation. In this case it would be useful to have a setting to disable the user switching.
The situation is made much worse because of a core bug 🐛 Can only intentionally re-render an entity with references 20 times RTBC . The bug will be hit if the issue entity contains an entity reference, and there are more than 20 authenticated subscribers. The proposed setting would avoid hitting the bug.
Hello There
We create a newsletter content. On this we have a reference field (referenced to the a Simple Page).
We render this page as a teaser.
Wenn we send the newsletter as default by cron, some of the 400 recipient get the newsletter rendered correct. Some of them only get the content of the newsletter node and not of the rendered simple page. We get the Following error:
Recursive rendering detected when rendering entity node: 49, using the field_newsletter_content field on the simplenews_issue bundle. Aborting rendering.
It is not a problem of the mail client. We also have sent the 400 newsletter to one singe account, who get the mail rendert correct.
Also on this account, when we send all 400 news we get some rendered incorrectly.
Any Ideas, why the newsletter is not correct on every recipient?
Thanks for ur help.
Active
3.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
In my view #17 is not the complete solution.
The comment says
Site builders need to ensure that newsletter content is rendered identical for all users before enabling this cache backend.
It's rather easy for the site builder to make a mistake and break this rule, which could be a security bug. So the remaining part of the fix is to disable the account switch in MailEntity::setContext().