Theme missing when installing in non-English language

When turning off CSS/JS caching, it is apparent from the file list that no CSS for Bartik is actually added to the page. Not good [TM].

Also switching to Seven theme as default works, the Seven styles are added properly to the frontend pages. When setting back to Bartik, it is still broken as before. No cache clearing helps. So this seems like not a systemic problem as Seven seems to work as a frontend theme in the foreign language environment.

Ok this is very bizarre. What I noticed is ActiveTheme has no known stylesheets in it, although the theme extension structure in it has all the info. The theme structure is converted to the ActiveTheme class in ThemeInitialization. If I "fix" the code to not looks at these made-up properties of the theme, but instead use the info file structure, then it is "fixed" as in now all four of the CSS files provided in bartik's info file are added to the page (yay, this is not the case before). BUT the page still looks like crap.

This is due to the markup having no resemblence to what Bartik expects:

<div class="layout-container">

  <header role="banner">
          <a href="/" title="Címlap" rel="home">
        <img src="http://drupal8.local:8083/core/themes/bartik/logo.png" alt="Címlap">
      </a>
    
          <div class="name-and-slogan">

(note .layout-container has a header) vs. what Bartik outputs normally:

<div id="page-wrapper"><div id="page">

  <header id="header" class="with-secondary-menu" role="banner" aria-label="Site header"><div class="section clearfix">
         <nav id="secondary-menu" class="navigation" role="navigation" aria-labelledby="links__system_secondary_menu">
        <h2 id="links__system_secondary_menu" class="visually-hidden">Secondary menu</h2><ul id="secondary-menu-links" class="links inline menu clearfix">
    <li class="leaf"><a href="/user" data-drupal-link-system-path="user">My account</a></li>
<li class="leaf"><a href="/user/logout" data-drupal-link-system-path="user/logout">Log out</a></li>

  </ul>
      </nav> <!-- /#secondary-menu -->
    
          <a href="/" title="Home" rel="home" id="logo">
        <img src="http://sd2faf5a9aae5f21.s2.simplytest.me/core/themes/bartik/logo.png" alt="Home">
      </a>
    
          <div id="name-and-slogan">

(note #page-wrapper #page has a #header).

Looks like the templates actually used to generate the page are from the system, not Bartik.

So its not just the CSS, but the templates as well. Turning on TWIG debug mode showed no bartik templates are used ever. It keeps using all the built-in templates and has no idea bartik should be used.

3 related issues, clarifying issue title.

First question to figure out: Wondering why this only happens when installing in a different language than English?

I suspect that the installer performs an additional operation (i.e., additional module installations for locale/language), which cause the theme info to be primed ahead of time, before the actual theme is installed. Therefore, #2273769 sounds closely related.

I'm not sure the theme is missing, the system DOES know to some degree it uses Bartik. Ie. ActiveTheme knows its bartik (eg. the Extension info in ActiveTheme is fully populated as Bartik), it does not have the stylesheet parsing that are to be removed in #2326407: Remove magic property overloading from Extension class and probably not initialized in other key ways also. So in some ways Drupal does know Bartik is being used, but it is not initialized fully. The workaround in #4 makes the CSS files even used.

#2330755: ThemeHandler::refreshInfo() should use addTheme instead of setting the extension directly. fixes this but this issue has more info. Closed that as duplicate.

I sadly could not figure out how to run the InstallerLanguagePageTest test. Therefore I decided to tackle the actual root of the problem, adding
additional information to the extension object. I am not sure whether this is the right issue to post this patch, though this solves the same issue,
installing in a language still results in having a proper theme.

Duplicate issue: #2326555: After Installing drupal with another language as english, all the css of the bartik theme is gone.

how to run the InstallerLanguagePageTest test

may be like this? as the issue is missing css ID.

@vijaycs85: we don't need another test, we already have 2 that are actually installing in a foreign language, a German and an Arabic. Your test failed because it got a French translated profile selection page and then could not move forward installing. Also it would have failed because you are asserting Bartik CSS IDs, but the test installs with Stark (which does not have any custom templates).

@dawehner: yeah InstallerLanguagePageTest is not the right one to look at, that does not actually install in a foreign language, so would not fail. InstallerTranslationTest and InstallerLanguageDirectionTest are the two which install actually in a foreign language.

In this patch I decided to extend InstallerTranslationTest. Since Stark does not have its own templates, we need to assert for the only CSS file it has. To be able to do that, we need to turn off CSS aggregation. That's all we need for this test. It nicely fails for me without the fix and passes with the fix.

@dawehner: looking at the patch there are two odd things:

1. The base_theme is still moved up as a special property in addTheme. That sounds like will still be a problem for a foreign language site that uses a base theme based theme on install, right? I can see it is done because there is also base_themes which is computed in ThemeHandler. But then (see point 2).
2. For some reason, the use of addTheme() in refreshInfo() is not in the patch anymore? Looks like it would still be needed for 1, right?

Uploading a patch that also has #8 in it for this.

While rewriting the issue summary noticed that doing all this cleanup here will result in API changes. Not sure we should couple them with fixing a critical bug? Included them in the patch / issue summary for now, but not sure about this.

Erm, looks like the interaction of the fixes did not work well in #15. Let's try with only the test and the one line fix from #8.

Silly me. Should not assign a NULL to where an object should be. Meh. Now actually uses the code from #8.

Nice! Let's solve the underlying problem in a follow up.

This is going to conflict with #2329795: Make it possible to add information to theme info files during development - just add the test here?

Here is a patch that has both rolled together. THIS IS NOT FOR COMMIT. The two fixes overlap in the one line fix and this patch should prove if they work well together (they should :). Then it is your choice to commit this one first (patch from #21) or that one first and we can reroll the other one. The patch only version of this patch at #14 is fully up to date, that should pass once #2329795: Make it possible to add information to theme info files during development lands.

I think we want to keep credit, reference to issues in commits, etc. so comitting from each issues looks best to me.

All right this proves the two patches work well together :) I volunteer to reroll either once the other one lands.

#2329795: Make it possible to add information to theme info files during development went in. :)

Reuploading test only patch from #14 then. Should now pass. It did not pass before, see its results originally in #14.

Committed/pushed to 8.0.x, thanks!

Superb, thanks!