I think this is a bug, so reporting.

By accident I added xyz.tpl.php file inside the themes/themename/templates/ folder. Cleared the cache and didn't find any changes(obviously), however going to the /admin/appearance URL, I saw lots of extra themes which are disabled. Those themes were not there before and maybe due to some process were trigerred, I cannot get rid of those now.

I have attached the image below. However the problem is even after deleting that xyz.tpl.php file and clearing cache, running cron, those disabled themes are still shown in appearance page.

CommentFileSizeAuthor
11.jpg353.04 KBAnonymous (not verified)
16.jpg283.72 KBAnonymous (not verified)
15.jpg380.18 KBAnonymous (not verified)
14.jpg335.22 KBAnonymous (not verified)
13.jpg326.87 KBAnonymous (not verified)
12.jpg341.84 KBAnonymous (not verified)

Comments

Anonymous’s picture

Anonymous (not verified) commented

rajibmp created an issue. See original summary.

cilefen’s picture

cilefen commented

Try browsing /rebuild.php and see https://www.drupal.org/documentation/rebuild

cilefen’s picture

cilefen commented
Title: Adding .tpl.php file in theme templates creates absurd amount of disabled themes » Adding .tpl.php file in theme templates makes test themes visible on the appearance admin form
gnuget’s picture

gnuget
Primary language Spanish
commented

I tried to replicate this problem and I couldn't do it.

can you please provide a list of steps to reproduce it?

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update

I second #4

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Anonymous’s picture

Anonymous (not verified) commented

sorry, didn't see the message for long:

steps to reproduce:

1. Create a new theme in the themes folder. Add Bartik as its parent theme, add YAML file giving info about your subtheme.
2. Create a templates folder
3. Go to appearance from admin menu and set default the theme you just created.
4. Add a file **page.tpl.php** in the templates folder
5. Add some dummy html and php code eg: (doesn't have to be exact same code, this is mere example)

<section class="content">
<?php global $user; var_dump($user); ?>
</section>

6. Clear the cache

Edit: As it had been long, I mixed the order of steps... but now its corrected.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Thanks for the steps to reproduce, unfortunately I followed those steps and couldn't see what you are seeing. The only way those test themes show is if you have this setting in your settings.php or settings.local.php enabled:

$settings['extension_discovery_scan_tests'] = TRUE;

Can you look to see if that setting is on somewhere?

Anonymous’s picture

Anonymous (not verified) commented

yes indeed.... I didn't remember that... I copied the settings.local.php file somewhere I don't remember either which has the line:

/**
 * Allow test modules and themes to be installed.
 *
 * Drupal ignores test modules and themes by default for performance reasons.
 * During development it can be useful to install test extensions for debugging
 * purposes.
 */
$settings['extension_discovery_scan_tests'] = TRUE;

Another thing is: In the above steps to reproduce, I already had the theme enabled before mistakenly adding the tpl.php file inside the templates.

I couldn't go back to the previous state, so, I had to rebuild the site from previous backup and code.

cilefen’s picture

cilefen commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

If you think this would be helpful maybe we can comment that line by default in the default.settings.local.php file? That setting is useful but not common.

We can reopen if you think that is helpful

cilefen’s picture

cilefen commented
Category: Bug report » Support request
Status: Closed (cannot reproduce) » Fixed

Actually all of example.settings.local.php is development-based. I think that file needs a better comment at the top. default.settings.php refers to settings.local.php like this:

/**
 * Load local development override configuration, if available.
 *
 * Use settings.local.php to override variables on secondary (staging,
 * development, etc) installations of this site. Typically used to disable
 * caching, JavaScript/CSS compression, re-routing of outgoing emails, and
 * other things that should not happen on development and testing sites.
 *
 * Keep this code block at the end of this file to take full effect.
 */

But, I agree that example.settings.local.php does not explain itself. Let's keep this closed as an answered support request and open a new issue to fix up example.settings.local.php.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Thanks @cilefen I've created a follow-up for that here #2805449: Comment out 'extension_discovery_scan_tests' in example.settings.local.php

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.