Problem/Motivation

hook_custom_theme() fails to work under certain circumstances.
Call stack that causes the issue:

  • On boot the redirect module checks for redirect: redirect_load_entity_from_path()
  • This builds the node, which attaches the fields
  • Having a text field with media token support triggers media_token_to_markup()
  • Loading the file to create the markup triggers file_entity_file_load()
  • This triggers token_replace() for the alt / title tags.
  • Token replacement triggers system_token_info()
  • This creates a link using l()
  • l() wants to know the current theme thus drupal_theme_initialize() is called.
  • drupal_theme_initialize() defines global variables e.g. $theme, $theme_key. Once those variables are set the main part of the function is skipped. Unfortunately drupal_theme_initialize() doesn't force menu_get_custom_theme() to initialize.

Now what's the problem with that:
The call of the redirect module is made before menu_set_custom_theme() was called, which is normally called after drupal_path_initialize() in _drupal_bootstrap_full().
And the redirect module acts on hook_url_inbound_alter() which is triggered by drupal_path_initialize().
Because that call is skipped hook_custom_theme() never is invoked and we lose the control over the theme.

Proposed resolution

I see two approaches:

  1. Add a force flag to drupal_theme_initialize() to be able to re-set the global theming variables when calling the function in _drupal_bootstrap_full()
  2. Change drupal_theme_initialize() to force the initialization when calling menu_get_custom_theme()

I think the first one is more unobtrusive and is the one I've added as patch.

Remaining tasks

Reviews needed.

User interface changes

None.

API changes

The function signature of drupal_theme_initialize() has changed but in a transparent way. This means already existing code will work as before.

CommentFileSizeAuthor
#66 bootstrap_marker-2086335-66.patch1.68 KBKeyboardCowboy
#58 drupal-n2086335-58.interdiff.txt3.2 KBDamienMcKenna
#58 drupal-n2086335-58.patch7.61 KBDamienMcKenna
#57 drupal-n2086335-57.patch6.38 KBDamienMcKenna
#57 drupal-n2086335-49-57.interdiff.txt1.88 KBDamienMcKenna
#53 drupal-n2086335-34-49.interdiff.txt10.72 KBDamienMcKenna
#52 drupal-n2086335-49.interdiff.txt4.04 KBDamienMcKenna
#49 interdiff-2086335-34-49.txt10.72 KBtnathanjames
#49 drupal-bootstrap_theme_init_issue-2086335-49.patch6.36 KBtnathanjames
#47 interdiff-2086335-34-47.txt10.72 KBtnathanjames
#47 drupal-bootstrap_theme_init_issue-2086335-47.patch6.54 KBtnathanjames
#34 drupal-bootstrap_theme_init_issue-2086335-34.patch11.53 KBdas-peter
#30 interdiff-2086335-27-30-do-not-test.diff783 bytesdas-peter
#30 drupal-bootstrap_theme_init_issue-2086335-30.patch7.03 KBdas-peter
#27 drupal-bootstrap_theme_init_issue-2086335-27.patch6.27 KBdas-peter
#27 drupal-bootstrap_theme_init_issue-2086335-27-test-only.patch4.24 KBdas-peter
#24 core-bootstrap_theme_init_issue-2086335-24.patch2.79 KBsrclarkx
#22 core-bootstrap_theme_init_issue-2086335-22.patch2.98 KBsrclarkx
#20 core-bootstrap_theme_init_issue-2086335-20.patch2.12 KBsrclarkx
#19 core-bootstrap_theme_init_issue-2086335-19.patch2.08 KBsrclarkx
#15 custom_theme_1.patch1.66 KBsmitarai
#8 core-bootstrap_theme_init_issue-2086335-8.patch1.84 KBsrclarkx
#3 custom_theme.patch1.32 KBsmitarai
drupal-bootstrap-issue-with-theme-initialization.patch1.25 KBdas-peter
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

das-peter’s picture

IRC Conversation with Daniel:

[08:28] das-peter: it does use hook_custom_theme for the redirect and not hook_init?
[08:32] dawehner: redirect acts on hook_url_inbound_alter() that's before hook_custom_theme() - and because it uses token (in some cases), which needs a theme it initializes the theme what leads to a stall theme because the proper call to menu_set_custom_theme() is missing.
[08:32] das-peter: but yeah it would be interesting to be able to roll back theme initialization, as even t() can trigger it
[08:33] dawehner: I tried to outline the whole call stack in the issue I mentioned - but I know it's confusing :)
[08:36] das-peter: on general problem is that resetting a theme might cause all kind of side-effects like having a css file already added
[08:38] dawehner: Well then the only thing I can imagine to solve this is that a call to drupal_theme_initialize() has to trigger menu_set_custom_theme() - then the chain would be complete again.

According to this we probably should change the approach to fix this and ensure that drupal_theme_initialize() calls menu_set_custom_theme().

smitarai’s picture

FileSize
1.32 KB

I am encountering similar issues on a project.

To replicate on vanilla Drupal, I created a module (garland and stark are enabled themes)
<?php

function mymodule_custom_theme() {
if (arg(0) == 'node' && is_numeric(arg(1))) {
$node = node_load(arg(1));
if ($node->type == 'page') {
return 'garland';
}
else if ($node->type == 'article') {
return 'stark';
}
}
}

function mymodule_entity_load($entities, $type) {
if ($type == 'node') {
foreach ($entities as $entity) {
/** this is going to initialize the theme and break everything * */
$entity->foo = l(t('foo'), '');
}
}
}

I am including a patch which seems to get this working.

What the patch does it, it does not let the drupal_theme_initialize or theme_get_registry get loaded from anywhere else apart from
_drupal_bootstrap_full

Status: Needs review » Needs work

The last submitted patch, 3: custom_theme.patch, failed testing.

srclarkx’s picture

#3 looks a lot like the first patch. The first patch didn't work for me, I ended up with a page in 2 different themes. #3 worked. Unfortunately it didn't pass SimpleTest. At a glance it looks like the difference is #3 prevents some code from running in theme_get_registry.

Status: Needs work » Needs review

smitarai queued 3: custom_theme.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 3: custom_theme.patch, failed testing.

srclarkx’s picture

smitarai, Just for grins, I replaced the global with variable_set and variable_get to see if the patch would do better with SimpleTest

srclarkx’s picture

Status: Needs work » Needs review

Submitted for testing

das-peter’s picture

variable_set() writes the value into the db. And we really don't want this as this is a flag for the current request only and nothing that has to be shared with other requests.
So either a global (php) variable or drupal_static() is the way to go for request specific status flags.

srclarkx’s picture

If I get a few minutes I'll update the patch or smitarai can do so. I read that global variables have to be put in the $GLOBALS array.

Status: Needs review » Needs work

The last submitted patch, 8: core-bootstrap_theme_init_issue-2086335-8.patch, failed testing.

das-peter’s picture

@srclarkx smitarais patch already uses global variables: global $drupal_theme_init; is the same as using $GLOBALS['drupal_theme_init'].

We should try as in #2 proposed:

ensure that drupal_theme_initialize() calls menu_set_custom_theme().

Unfortunately I hadn't time to do so. But as I just recently came across some a ThemeRegistry "cache poisoning" in one of our sites I might can spend some time on it soon - error could be related to this issue.

smitarai’s picture

@das-peter
Even if you ensure that menu_set_custom_theme gets called from drupal_theme_initialize() what happens in the case is that two different themes are loaded. The culprit is as I mentioned in my comment any code in entity_load which will in turn cause the registry to load, will also initialize the theme, and this will be done before the actual call if drupal_theme_initialize in _drupal_bootstrap_full(), and if you see drupal_theme_initialize, if it finds the global theme set, its not going to do any more processing. So the only way to stop it is making sure that is theme initialization is only through _drupal_bootstrap_full.

I can't figure out why my patch is failing simpletest because its not doing anything related to mysql at all. The only viable change that I do see in the patch is moving the global initializing to inside the not maintenance or update loop in _drupal_bootstrap_full.

smitarai’s picture

FileSize
1.66 KB

Lets see if this one passes QA.

And I give up.

smitarai’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 15: custom_theme_1.patch, failed testing.

srclarkx’s picture

smitarai, I have a bare-bones drupal with simple tests running and I put together a custom module using the instructions in #3. I was able to confirm that that the tests for the patch are failing because of the changes in theme_get_registry(). I removed the check for drupal_theme_init from the theme_get_registry function and put a check in l(). This will prevent theme_get_registry from being called. I verified a few of the tests and they seem to pass. I haven't done enough debugging to submit a patch yet. I'm going to hand over a snippet for you and see if you have time to work on it.

function l($text, $path, array $options = array()) {
  global $language_url;
  global $drupal_theme_init;
  static $use_theme = NULL;

  // Merge in defaults.
  $options += array(
    'attributes' => array(),
    'html' => FALSE,
  );

  // Append active class.
  if (($path == $_GET['q'] || ($path == '<front>' && drupal_is_front_page())) &&
      (empty($options['language']) || $options['language']->language == $language_url->language)) {
    $options['attributes']['class'][] = 'active';
  }

  // Remove all HTML and PHP tags from a tooltip. For best performance, we act only
  // if a quick strpos() pre-check gave a suspicion (because strip_tags() is expensive).
  if (isset($options['attributes']['title']) && strpos($options['attributes']['title'], '<') !== FALSE) {
    $options['attributes']['title'] = strip_tags($options['attributes']['title']);
  }

  // Determine if rendering of the link is to be done with a theme function
  // or the inline default. Inline is faster, but if the theme system has been
  // loaded and a module or theme implements a preprocess or process function
  // or overrides the theme_link() function, then invoke theme(). Preliminary
  // benchmarks indicate that invoking theme() can slow down the l() function
  // by 20% or more, and that some of the link-heavy Drupal pages spend more
  // than 10% of the total page request time in the l() function.
  if (!isset($use_theme) && function_exists('theme')) {
    // Allow edge cases to prevent theme initialization and force inline link
    // rendering.
    if (variable_get('theme_link', TRUE) && $drupal_theme_init) {
      drupal_theme_initialize();
      $registry = theme_get_registry(FALSE);
...

I think the simpleTests are failing because the return value from theme_get_registry is not correct. Fixing the l function will not solve this issue. I did notice a few other modules were fixed to work around this issue, when the right solution would probably be to figure out how to prevent the theme from re-loading.

srclarkx’s picture

This is just a fix up of smitarai's patch from #15. It should be just about the same with some verification of the global before it's used. I don't know how to make the test button appear. This doesn't work for the issue I'm looking at. It does pass the tests and does work in my bare-bones example. It will at least give someone an idea of how to fix up the patch.

srclarkx’s picture

Status: Needs work » Needs review
FileSize
2.12 KB

OK, now I'm ready to test a patch. I have a subset of the simpleTests passing on my system and the patch appears to work on my problem. Fingers crossed.

das-peter’s picture

Status: Needs review » Needs work

@srclarkx Thank you very much for working on this! And it's green!! :)

For now here's just a visual review - most of the stuff is feedback from Code Sniffer - I highly recommend to integrate it with your IDE as it saves you from such Coding standards feedbacks.
Further I think the code-bits need documentation to make clear why this stuff is in place and what happens if it's not there.

  1. +++ b/includes/common.inc
    @@ -5155,7 +5155,10 @@ function drupal_valid_token($token, $value = '', $skip_anonymous = FALSE) {
    +  //create global variable for theme init
    

    No space found before comment text; expected "// create global variable for theme init" but found "//create global variable for theme init"
    Inline comments must start with a capital letter
    Inline comments must end in full-stops, exclamation marks, or question marks

  2. +++ b/includes/common.inc
    @@ -5155,7 +5155,10 @@ function drupal_valid_token($token, $value = '', $skip_anonymous = FALSE) {
    +  $drupal_theme_init = 1;
    
    @@ -5203,6 +5206,7 @@ function _drupal_bootstrap_full() {
    +    $drupal_theme_init = 0;
    

    Wouldn't this be better a boolean?

  3. +++ b/includes/common.inc
    @@ -5211,6 +5215,7 @@ function _drupal_bootstrap_full() {
    +    $drupal_theme_init=1;
    

    Expected 1 space before "="; 0 found
    Expected 1 space after "="; 0 found

  4. +++ b/includes/theme.inc
    @@ -68,6 +68,10 @@ function _drupal_theme_access($theme) {
    +  global $drupal_theme_init;
    
    @@ -253,6 +257,10 @@ function _drupal_theme_initialize($theme, $base_theme = array(), $registry_callb
    +  global $drupal_theme_init;
    +  if (isset($drupal_theme_init) && !$drupal_theme_init) {
    

    I propose:

      // Ensure we've reached a bootstrap level in which a theme initialization is
      // possible without causing side-effects.
      if (empty($GLOBALS['drupal_theme_init'])) {
    
srclarkx’s picture

Status: Needs work » Needs review
FileSize
2.98 KB

das-peter,

I made most of the changes you asked, added comments and made the global a boolean. I couldn't get it to pass if I replaced the isset($drupal_theme_registry) with the empty($GLOBALS['drupal_theme_init']) in the theme_get_registry function. It doesn't like the return value in the conditional. I probably won't be able to get back to this for a while.

das-peter’s picture

@srclarkx Awesome, thanks! Hope I can test it soon :)

srclarkx’s picture

The initialization of the $drupal_theme_init in the _drupal_bootstrap_full function is causing problems. I'm going to see if I can get it to pass simpleTests without initializing that global variable. This is closer to what Smita submitted.

srclarkx’s picture

Status: Needs review » Needs work

I'm going to mark this as still needs work. The patch will cause other issues especially when adding files and images. I'll continue to work on it in my spare time.

srclarkx’s picture

Guess I had a brain cramp, I have a bug in the last patch.

 function drupal_theme_initialize() {
   global $drupal_theme_init;
   // Ensure we've reached a bootstrap level in which a theme initialization is
  // possible without causing side-effects. Also, if the theme is already
  // initialized, don't reset the theme.  A custom theme might be set.
  if (empty($GLOBALS['drupal_theme_init']) || !$drupal_theme_init) {
   return;
 }

should be

 function drupal_theme_initialize() {
   global $drupal_theme_init;
   // Ensure we've reached a bootstrap level in which a theme initialization is
  // possible without causing side-effects. Also, if the theme is already
  // initialized, don't reset the theme.  A custom theme might be set.
  if (!empty($GLOBALS['drupal_theme_init']) && !$drupal_theme_init) {
   return;
 }

I'm not submitting another patch because the patch breaks the Syntax Highlighter.

das-peter’s picture

Had time to investigate this further.
Created a test and overhauled the patch. Still not sure if this is the best / only approach.
Test-only patch should fail.

The last submitted patch, 27: drupal-bootstrap_theme_init_issue-2086335-27-test-only.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 27: drupal-bootstrap_theme_init_issue-2086335-27.patch, failed testing.

das-peter’s picture

Status: Needs work » Needs review
FileSize
7.03 KB
783 bytes

Adjusted patch: _drupal_maintenance_theme() has to set the global variable as well.

dawehner’s picture

I'm curious how many of those accidentally theme initialization before proper bootstrap level do we have.
Are there other examples than l() and t()? I'm curious whether we could explicitly fix them there, which means those places would never trigger the theme initialisation but
instead just fallback on the non-theme implementations?

mkalkbrenner’s picture

I'm curious whether we could explicitly fix them there

@dawehner: I don't know if I understood you correctly.
I didn't count, but I opened a lot of issues for contrib modules to avoid l() and t() in early boot strap phases, which break ThemeKey. I even wrote a debugger to find these trouble causing modules.
From my point of view it's impossible to fix all this erroneous code and new one will be written as long as we only state in the documentation that it is not allowed to use function like l() or t() for example in hook_boot.
Therefor I prefer that workaround in core.

On the other hand, the solution I would really like to see is to modify l() and t() themselves. If they are called too early they should throw a hard error. That's the only way to get rid of all the erroneous code.

But as that would break existing installations until these contrib modules are fixed, it is also possible to just create watchdog entries to force people to fix their code and have a workaround like #30 in core to get rid of the problems these contrib modules are causing.

das-peter’s picture

From my point of view it's impossible to fix all this erroneous code and new one will be written as long as we only state in the documentation that it is not allowed to use function like l() or t() for example in hook_boot.

I agree and also second that it is almost impossible to fix all the occurrences. Especially since l() or t() are just the most obvious triggers here.
As the one described in the issue summary there are much complexer scenarios which are almost impossible to fix.
I tried to change the approach to have something like drupal_theme_initialize($reset = FALSE) where _drupal_bootstrap_full() then uses drupal_theme_initialize(TRUE). However this failed miserably because _drupal_theme_initialize() already adds css / js using drupal_add_css()/drupal_add_js() which makes a clean reset almost impossible.
So I'm out of ideas for other less invasive approaches - but for now denying to initialize the theme stuff before a certain boot level seems the most unobtrusive way to handle this.

das-peter’s picture

Changed approach: drupal_theme_initialize($final_init = FALSE) and _drupal_theme_initialize($theme, $base_theme = array(), $registry_callback = '_theme_load_registry', $register_files = FALSE).
$final_init / $register_files should only be set by _drupal_bootstrap_full() or when there's no full bootstrap but output.
I'd say this is a bit clearer than dealing with global variables. And the documentation is easier to find.
First tests look good - let's see what the test-bot says.

dawehner’s picture

This patch seems to be a really good solution under the boundary condition of not changing behaviour of the system.

srclarkx’s picture

We have a large drupal site and this issue is a priority. We will do some testing using this patch today and give feedback.

srclarkx’s picture

We tested this and the theme issues seem to be fixed. If we don't see any issues in the next week, I'm going to call it good.

srclarkx’s picture

Status: Needs review » Reviewed & tested by the community

I reviewed the patch and the comments. We patched our system and have been running the patch for close to 2 weeks.

We use custom theming on a per node basis. We were having problems with the theme coming up initially in the wrong theme. When we tried the initial patch we were getting more than 1 theme loaded on a page. Patch #34 works for us. Nodes seem to be loading with the correct theme consistently.

cilefen’s picture

Issue summary: View changes

I changed loose to lose in the issue summary.

cilefen’s picture

Title: Bootstrap issue with theme initialization. » Bootstrap issue with theme initialization causes hook_custom_theme() never to be invoked
jOksanen’s picture

This fixed the custom_theme() issue for me.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs subsystem maintainer review

This is some interesting work, and being able to switch themes mid-request is a really nice goal. Thank you for working on it. But I'm worried it's more complicated than this. What about other code out there that might cache information based on the current theme, without any expectation that the theme could change later on?

I'm tagging this issue for more review, since it seems like this is a really fundamental change to the theme system and it needs more careful review to see if it's possible to do in a stable release.

In terms of a quicker fix (that might fix the immediate problem but not the underlying cause) I agree with @dawehner in #31:

I'm curious how many of those accidentally theme initialization before proper bootstrap level do we have.
Are there other examples than l() and t()? I'm curious whether we could explicitly fix them there, which means those places would never trigger the theme initialisation but instead just fallback on the non-theme implementations?

Note that in Drupal 7 t() should not initialize the theme system (at least not as far as I know), so that just leaves l(). And l() only needs to initialize the theme system in a very specific way, when a site has chosen to override the default theming of links. So it should be possible to change the code in l() to just fall back on the default theming whenever it's called too early. That would mean that if l() gets called too early those particular links might not be output the way the site expects them to be, but it seems like a relatively small price to pay especially since you really shouldn't be running too much complicated code before hook_init() to begin with... Drupal just isn't set up all the way yet then.

Alan D.’s picture

how many of those accidentally theme initialization before proper bootstrap level do we have

It's been a few years since I last looked at the code, but doesn't the menu system need to be fully executed to ensure the correct theme?

One random one in the mix is the Text module during entity load from a wildcard callback. This calls _text_sanitize() and the filters that are enabled could invoke a theme callback.

i.e. The Image resize filter was enabled on the body field. So text_field_load() called _text_sanitize() to check_markup() to theme('image_resize_filter_image').

Found this out debugging for #1870890: Use hook_domain_bootstrap_full() to set $conf['theme_default'] rather than hook_custom_theme().

Chris Burge’s picture

#34 resolved the issue relating to hook_custom_theme() for me. In my particular case, I am using the OG Theme module, which makes use of hook_custom_theme(). After a site cache clear, the initial page load of a group node would result in the wrong theme being loaded due to hook_custom_theme() failing to execute as expected.

DamienMcKenna’s picture

DamienMcKenna’s picture

It might be worth extending the test to verify that CSS or JS is only loaded from the active theme and not one of the others.

tnathanjames’s picture

I tried #34. It worked for me, but I really wanted to only process things differently in the special circumstance where the custom theme is set for the current page and a different theme was initialized before the call to drupal_theme_initialize in _drupal_bootstrap_full() of common.inc.

So, I am uploading a patch and interdiff to #34. This only changes current behavior in the circumstances previously mentioned. I also added a test for loading the correct theme if hook_custom_theme does not return a custom theme and updated the current tests to look for a file specific to the theme instead of just the theme name (just in case).

Status: Needs review » Needs work

The last submitted patch, 47: drupal-bootstrap_theme_init_issue-2086335-47.patch, failed testing.

tnathanjames’s picture

Corrected patch - directly from git this time :)

The last submitted patch, 47: drupal-bootstrap_theme_init_issue-2086335-47.patch, failed testing.

DamienMcKenna’s picture

Status: Needs work » Needs review
DamienMcKenna’s picture

DamienMcKenna’s picture

.. which makes my interdiff completely redundant. Sorry tnathanjames.

DamienMcKenna’s picture

Status: Needs review » Needs work

This needs to be extended to cover additional scenarios:

  • Make sure it works correctly regardless of whether CSS/JS aggregation is enabled.
  • Make sure it works with subthemes.
DamienMcKenna’s picture

FYI the themes won't enable in the correct order if there are other themes installed, so running CustomThemeBootTestCase locally may fail.

DamienMcKenna’s picture

Status: Needs work » Needs review
FileSize
1.88 KB
6.38 KB

This patch just changes how the themes are enabled to use theme_enable().

DamienMcKenna’s picture

This adds an extra set of tests after CSS and JS aggregation is enabled, and refactors the code a little bit.

jtwalters’s picture

This part seems like it's not doing anything:

$drupal_static_fast['registry'] = &drupal_static('theme_get_registry');
$drupal_static_fast['registry'] = array();

Have not tested it though.

Alan D.’s picture

This part seems like it's not doing anything

This is ensuring that the stored array is empty, the & bit in the first line is the reference to the stored value.

jtwalters’s picture

Thanks for clarifying. It just seems odd to reference an array index without first declaring the array, but I recall PHP allows that.

I tested out this patch and it works for my custom "hook_custom_theme" implementation. It was the only thing that worked for me.

jtwalters’s picture

Also, needed to drupal_static_reset a little more, interdiff is:

+      drupal_static_reset('drupal_add_js:jquery_added');
+      drupal_static_reset('drupal_add_library');
Fabianx’s picture

#59:

$drupal_static_fast['registry'] = &drupal_static('theme_get_registry');

Can be written directly as:

$drupal_static_fast['registry'] = &drupal_static('theme_get_registry', array());

to initialize to an array() when not set.

Fabianx’s picture

Btw. this issue is one of the reasons why I advocate to deprecate theme_link() (even if we can't remove it) and urge strongly to use theme_link = FALSE in $conf for all our sites.

It also means we really should use an alter() hook for links to avoid early instantiation when not needed. (#2562731: Add hook_link_alter)

The patch in general looks good to me, but another idea would be:

- When the theme is not yet negotiated, do not initialize it.
- Ensure that theme_link static in l() is not populated till BOOTSTRAP is completed.

davidburns’s picture

This fixed my issue where ThemeKey would load multiple themes clearing cache or re-saving a node! Thank you.

KeyboardCowboy’s picture

I like @Fabianx's recommendation of not initializing the theme while in another routine of the bootstrap phase. I'm not sure if this is more performant than the solution in #58, but it seems simple enough and it works.

Rudi Teschner’s picture

I've had trouble with loading the default theme after a cache clear and patch #66 solves the issue for me.

The last submitted patch, 58: drupal-n2086335-58.patch, failed testing. View results

The last submitted patch, 58: drupal-n2086335-58.patch, failed testing. View results

joseph.olstad’s picture

Please do not be alarmed by "composer Command Failed" - this is not an indication of a problem with the patch.
It occurs since approximately may 4th, there is a known testrunner issue. @mixologic (responsible for the testrunner) is on vacation
#2970950: D7 test runner not working since may 4th 2018 'Composer command failed'
Hopefully @mixologic gets back from his vacation soon.

DamienMcKenna’s picture

Somewhat related: #1934192