Modules dealing with themeable HTML email including simplenews and swiftmailer need a way to consistently and reliably perform rendering using a predetermined theme, regardless of the other things going on in the environment that invoked the mailer (such as call via cron, drush, or URL path having admin as the active theme)
As an experimental solution, I wrote a patch for simplenews that defined another service backed by Drupal\Core\Render\Renderer so that I'd have another instance of Renderer to use for the email content rendering. I was free then to just configure in the yml for it to get a ThemeManager that used Drupal\Core\Theme\DefaultNegotiator -- so my Renderer instance was being told always to use the site's default theme, without regard to things like invoking path.
But I found some small issues in the Registry and ThemeRegistry classes, mostly that ThemeRegistry gets a Registry instance always by direct \Drupal::service('theme.registry');
and that one will pull templates from whatever the active theme is.
I'm including a patch intended to non-disruptively enhance ThemeRegistry / Registry to handle use cases such as described where setting up a separate rendering path from the primary one for page output is needed.
Comment | File | Size | Author |
---|---|---|---|
#4 | 2621018-4.patch | 4.85 KB | mbaynton |
#4 | 2621018-2-4.interdiff.txt | 1.05 KB | mbaynton |
#2 | 2621018-2.patch | 3.81 KB | mbaynton |
Comments
Comment #2
mbayntonComment #4
mbayntonFix test
Comment #10
markhalliwellThis is something that has been needed, very badly, for a very long time.
However, it mainly centers around properly setting the active theme to something else and then restoring it to the previously active theme.
So mostly, just boilerplate code that many contrib modules could use.
That being said, I think it may be easier to implement this once #2869859: [PP-1] Refactor theme hooks/registry into plugin managers happens.
Then it could potentially just be a matter of doing something like:
And all the switching happens automatically, internally, if it's not the currently active theme.
Comment #11
BerdirMailsystem supports this in 8.x since the beginning, there were initially some issues but it has been improved and works fine now.
https://cgit.drupalcode.org/mailsystem/tree/src/MailsystemManager.php#n59
Sure, we could add a wrapper that does the switching and then rendering, but I think the 90% use case here is e-mails and that now just works out of the box with the configured e-mail theme.
Not sure what other use cases there are, maybe the e-mail setting could i simply be moved into core instead of coming up with a completely new API.
Comment #12
markhalliwell