The requested page "/admin/appearance/settings/bartik" could not be found after installation

The attached test does not fail, so clearly SimpleTest is doing some cache clearing that doesn't happen during normal installation.

The route is added here:
http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/modul...

  foreach (list_themes(TRUE) as $theme) {
    if (!empty($theme->status)) {
      $items['admin/appearance/settings/' . $theme->name] = array(
        'title' => $theme->info['name'],
        'route_name' => 'system_theme_settings_' . $theme->name,
        'type' => MENU_LOCAL_TASK,
      );
    }
  }

Maybe this is #2004334: Separate Tabs (MENU_LOCAL_TASK) from hook_menu()?

Edit: It's also broken before that commit.

So this fixes the problem:

diff --git a/core/modules/system/lib/Drupal/system/Routing/RouteSubscriber.php b
index 616955c..374a071 100644
--- a/core/modules/system/lib/Drupal/system/Routing/RouteSubscriber.php
+++ b/core/modules/system/lib/Drupal/system/Routing/RouteSubscriber.php
@@ -34,13 +34,11 @@ static function getSubscribedEvents() {
   public function createSystemThemeRoutes(RouteBuildEvent $event) {
     $collection = $event->getRouteCollection();
     foreach (list_themes() as $theme) {
-      if (!empty($theme->status)) {
         $route = new Route('admin/appearance/settings/' . $theme->name, array(
           '_form' => '\Drupal\system\Form\ThemeSettingsForm', 'theme_name' => $
           '_permission' => 'administer themes',
         ));
         $collection->add('system_theme_settings_' . $theme->name, $route);
-      }
     }
   }

This does not:

diff --git a/core/modules/system/lib/Drupal/system/Routing/RouteSubscriber.php b
index 616955c..8246f2d 100644
--- a/core/modules/system/lib/Drupal/system/Routing/RouteSubscriber.php
+++ b/core/modules/system/lib/Drupal/system/Routing/RouteSubscriber.php
@@ -33,7 +33,7 @@ static function getSubscribedEvents() {
    */
   public function createSystemThemeRoutes(RouteBuildEvent $event) {
     $collection = $event->getRouteCollection();
-    foreach (list_themes() as $theme) {
+    foreach (list_themes(TRUE) as $theme) {
       if (!empty($theme->status)) {
         $route = new Route('admin/appearance/settings/' . $theme->name, array(
           '_form' => '\Drupal\system\Form\ThemeSettingsForm', 'theme_name' => $

This means that $theme->status is somehow cached incorrectly, even after system_list_reset() is called.

I think to test this properly, we have to entirely refactor system_list(). :) @tim.plunkett pointed me at #2024083: [META] Improve the extension system (modules, profiles, themes).

Related: #1067408: Themes do not have an installation status

This was not introduced by #2004784: Move module install/uninstall implementations into ModuleInstaller in http://drupalcode.org/project/drupal.git/commit/09db04d, so it's happened sometime since then.

And #1808248: Add a separate module install/uninstall step to the config import process.

This fixes it. No effing clue how to test it without refactoring the entire call chain for system listings, since we can't have a failing web test because of the cache clearing in SimpleTest, and given the sprawling complexity of static calls that is required to add these routes, I think I have a better chance of unit testing my cat.

Updated issue summary.

Updated issue summary.

Updated issue summary.

It turned out to not be precisely a cache issue after all.

Updated issue summary.

Looks like #2021959: Refactor module handling responsibilities out of DrupalKernel doesn't actually solve the problem, unfortunately.

This test also doesn't fail:

diff --git a/core/modules/system/lib/Drupal/system/Tests/InstallerTest.php b/cor
index 43824bf..72df060 100644
--- a/core/modules/system/lib/Drupal/system/Tests/InstallerTest.php
+++ b/core/modules/system/lib/Drupal/system/Tests/InstallerTest.php
@@ -149,6 +149,9 @@ protected function drupalGet($path, array $options = array()
    * Ensures that the user page is available after every test installation.
    */
   public function testInstaller() {
+    $themes = list_themes(TRUE);
+    $this->assertEqual($themes['stark']->status, 1);
+
     $this->drupalGet('user');
     $this->assertResponse(200);
   }

Turns out all the installer tests actually extend from WebTestBase.

@BarisW, did you try the patch in #8?

Thanks @BarisW!

The patch here still needs technical review, though, so setting to NR for that. See the @todo.

Yeah that's way better. :)

+++ b/core/includes/module.incundefined
@@ -38,13 +38,21 @@ function system_list($type) {
+    // site operation, the state backend might be down. Because we have a
+    // fallback to rebuild this data from the file system, we hide the error.

Where's the fallback? the if empty($theme_data) hunk below?

+++ b/core/includes/module.incundefined
@@ -38,13 +38,21 @@ function system_list($type) {
+    catch (Exception $e) {
+    }

+++ b/core/modules/system/system.moduleundefined
@@ -2861,13 +2861,21 @@ function system_rebuild_theme_data() {
+  catch (Exception $e) {
+  }

Can we catch something more specific?

@fubhy linked a mess of other theme-related issues:
#2029819: Implement a ThemeHandler to manage themes (@see ModuleHandler)
#2024043: Add Module, Theme, Profile, and Extension value objects
#2024083: [META] Improve the extension system (modules, profiles, themes)
#1798732: Convert install_task, install_time and install_current_batch to use the state system

Let's add a posptoned followup for the theme status issue to fix system_list() for themes.

#18: theme-settings-2040037-18.patch queued for re-testing.