Problem/Motivation

Classy will be moved to contrib during Drupal 9. In preparation to that, we have to remove dependencies on Classy from all core themes.

Proposed resolution

Use this spreadsheet of Core Theme's use of Classy as reference

Create theme-specific versions of all libraries that are not already overridden by the theme.

Copy all remaining Templates and CSS that are not already overridden by the theme and remove dependency to Classy. Some templates in Classy are identical to Stable and can be removed instead of copied. This is covered by #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync

Theme specific issues:
Claro: #3084810: Decouple Claro from Classy
Umami: #3096014: [META] Make Umami theme non-dependent on Classy
Seven: #3107872: [PP-1] Decouple Classy libraries from Seven

Remaining tasks

• Determine directory structure for copied templates: #3095713: Create classy directory with README, in the templates and css directories for all themes subtheming Classy
• Create test process for copying libraries: #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton
• Create test process for copying templates: #3096349: [PP-?] Create test for confirming Themes do not depend on Classy templates (currently blocked on #3106600: Decouple Classy libraries from Umami and other yet-to-be-created issues for decoupling Classy libraries from themes)
• Remove Classy templates with identical copies in Stable: #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync

Once the test procedure and directory naming is settled, create multiple issues for moving templates/libraries to themes. Consider grouping similar templates in an issue to reduce the total number of issues, but the scope should remain reasonable for each.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If users modify scaffold files (e.g. ".htaccess"), then they might not get changes to this file made in newer versions of Drupal.

Scaffold files should not be modified in Composer-managed Drupal sites; instead, users are expected to use "append" or "patch" capabilities to add their custom content to the Drupal-provided files. Some users do not know this yet, though, so some additional behavior to detect and warn users who modify the generate files is being proposed.

We ask people to modify their .htaccess file in the following use cases, and there is probably an expectation that their modifications will not be lost.

• using Drupal in a subdirectory
• suggesting a rewrite from or to a sub-domain

Additionally hacking .htaccess can help when redirecting to a front-end application not managed by Drupal.

However allowing composer to update .htaccess, web.config or other files is important because those files may change in new versions of Drupal due to security vulnerabilities, new features and so on.

There are three available ways to manage this in my repository: excluding the files from scaffolding altogether, or adding an append configuration (which is ++ for robots.txt, but not applicable to they types of changes in .htaccess), or by patching the scaffold files with cweagans/composer-patches. Managing scaffold file modifications through the scaffold process (i.e. with append or cweagans/composer-patches) is the recommended method, but poses some risk to developers who are not yet familiar with these techniques, and who might be uncertain about how to configure their file-mappings in order to get the desired behaviors. During this learning period, developers are in danger of accidentally losing any ad-hoc modifications that they may make to their scaffold files, as scaffold files are overwritten every time composer install runs.

Proposed resolution

User Expectations

1. I would expect to get the latest version of all the various files at the time I install Drupal
2. I would expect that if I make modifications to those files, that they’re left alone
3. The exception to that would be if there are updates “upstream” to the file(s) [for example, a change to resolve a security issue, which has definitely happened with .htaccess in the past]
4. Then, I want some means of knowing there's a change between my local files and upstream, so I can back my stuff up to compare/constrast the two and figure out what I need to do (either accept the changes wholesale or merge them into my modifications somehow)

The scaffold plugin now takes the following actions:

1. When a scaffold file is written, its contents are hashed, and the hash values are stored in a cache.
2. When a scaffold file is to be rewritten, then the contents of the source file are once again hashed; if the hash value matches what is in the cache (the source file has not changed), and the scaffold file still exists at its destination path, then it is skipped (not written).
3. If a scaffold file is modified at the destination path, this is detected because its content hash no longer matches the cached hash value.
   If the scaffold file does not exist at the destination path, it does not count as a modified file.
4. When a modified scaffold file is rewritten, then the scaffold plugin will warn the user that they may loose data, and will prompt them for the action to take
   • They may choose to discard their modifications.
   • They may abort the scaffold operation, in which case none of the scaffold files are changed.
   • They may permanently keep their modifications, in which case the file is removed from consideration and is no longer managed by the scaffold plugin.

Note that in the last option, where a scaffold file is no longer managed by the scaffold plugin, the user presently (in the current implementation of the most recent version of the patch) will not be warned if the scaffold file changes in a newer version of Drupal. It is desirable if the user knows when a modified upstream file has changed. The proposal is to print a warning during scaffolding. It would not be consistent to prompt, as the user has explicitly removed the file from being managed by the scaffold code. A prompt may be missed in the output of composer install / composer update; however, the user currently is not warned at all e.g. when running drush pm-update, so perhaps this is sufficient.

The hash cache data used by the scaffold plugin must be stored in either a transient location or a non-transient location. The non-transient location was selected.

Discussion on transient vs non-transient hash cache storage

An example of a transient location is inside the vendor directory, e.g. vendor/drupal/scaffolded.json. The advantage of the transient location is that the file does not have to be managed by the Drupal site. It may be committed to the repository if vendor is committed, but users who do this are accustomed to ignoring changes to vendor contents during updates. The disadvantage of the transient location is that it may be inadvertently removed; for example, if the user removes their entire vendor directory and then runs composer install, then the scaffold operation will overwrite any modified scaffold file. This may be unexpected, as scaffold files are written to locations outside of the vendor directory.

An example of a non-transient location is inside the project root, e.g. .scaffolded.json. The advantage of the non-transient location is that it is not subject to accidental removal if the user should decide to delete their vendor directory. While it is still possible for the user to deliberately delete their hash cache, with all of the consequences described above, this is less likely to happen. The disadvantage of the non-transient location is that there would be a new dot file at the project root of every Drupal site, and its contents will change inscrutably during Drupal upgrades. Every site owner must be aware of this file and decide whether to commit or .gitignore it -- although we can place it in example.gitignore to help with this decision, and document the file.

The proposal is to use a non-transient location for now, and add a comment to the file pointing the user to the scaffolding documentation. Since the hash cache keeps transient information that is only useful to users who are not using the recommended scaffold file management techniques (append or patch), we would then have the option to perhaps move the cache to a transient location in Drupal 9 or Drupal 10, once we felt that the recommended method was sufficiently socialized.

Original proposed resolution from becw

• Update the default behavior in core to specify overwrite: false for some scaffolding files (likely .htaccess, robots.txt, and web.config)
• Update comments in those files to include a note like "If you modify this, update your composer.json to contain ___", since each of these contain comments suggesting how to modify different parts of their contents
• Reduce the frequency that the scaffolder touches any files, so that they're only updated when core is installed or updated, which makes it much easier for developers to manage the diffs -- and allows developers to routinely incorporate core updates that affect these files.

Remaining tasks

• We need to decide what to do about scaffold files that the user has removed from consideration (set to "false" in file-mappings). Currently, no warning is provided if the source scaffold file changes once this is done.

User interface changes

Possible changes to how running composer behaves

API changes

None

Data model changes

Introduces a "transient-cache" field that allows users to decide whether to keep their hash cache in a transient location (inside the vendor directory), or whether it should be stored in the project root, where it may be committed to the repository (the default).

Release notes snippet

TBD

Problem/Motivation

In #3082958: Add gitignore(s) to composer-ready project templates, we want to add initial .gitignore files to our two Composer Project Templates to give users guidance on how to set up these files based on their preference to either commit the vendor directory or not.

The problem we face in that issue is that these two files are identical, save for slight variations in the path. It would be preferable if we could maintain but a single .gitignore, and place it in the right location with the scaffold plugin. In order to do that, we would need to interpolate replacement tokens inside the file in order to generate the correct relative path for ignored files inside the Drupal root.

Proposed resolution

Add an 'interpolate' flag to 'replace' operations:

"extra": {
    "drupal-scaffold": {
      "file-mapping": {
        "[project-root]/.gitignore": {
          "mode": "replace",
          "path": "assets/example.gitignore",
          "interpolate": true,
          "overwrite": false
        }
      }
    }
  }

Once interpolation is enabled in a scaffold file, replacement tokens will be substituted in the file when it is copied into place. For example, given:

[web-root]/index.php

The result will be either ./index.php or web/index.php (or similar), depending on the value of [web-root] in the project's "locations" section.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

See example "replace" operation above.

Release notes snippet

It is now possible to use template substitutions in scaffolded files.

Problem/Motivation

Users are encouraged to modify their .htaccess file directly in a comment in that same file; since this comment has been in place for a while, people are used to doing it. Unfortunately, this sort of modification is erased during Drupal updates (e.g. when running drupal pm-update), and with the introduction of the Drupal Composer Scaffold tool, composer install also puts these files in danger of being overwritten. See #3092563: Avoid overwriting .htaccess changes during scaffolding for some of the implications of this.

It would be desirable if we could start guiding users towards a more modern, Composer-based way to manage their .htaccess and robots.txt customizations. The Drupal Composer Scaffold tool provides patching and append/prepend features to make these changes easier to maintain, for example.

Proposed resolution

Add two examples to drupal/recommended-project:

1. Prepend to robots.txt
2. Patch .htaccess

These examples should not be added to the legacy project for now, as that is used to generate downloaded tarballs.

Remaining tasks

The scaffold files in drupal/core should say "do not modify these files", rather than the patch file / prepend file in the template.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

tbd

Right now AjaxResponse doesn't implement CacheableResponseInterface. And as a result we can't set cacheability metadata.
Need to improve drupal and add Cacheable Ajax response class.

Problem/Motivation

Drupal 9 will once again allow hook_update_N() to be used between major versions.

However, database updates still regularly introduce bugs, since they often run up against issues on real sites, such as corrupted data, or incompatibilities with contributed and custom schema changes/additions. Also sites that run into upgrade path issues and report them to the issue queue are not always run by people who can debug upgrade path issues themselves.

Proposed resolution

• Remove all updates added prior to Drupal 8.8.0-rc1 from Drupal 9.
• Remove all real legacy update tests

This will mean that sites still on Drupal 8.7 or lower, will need to update to Drupal 8.8.0 or later, prior to updating to Drupal 9.

There are various advantages to this:

1. Old upgrade path bugs from Drupal 8.5/8.6 can no longer be fixed in Drupal 8.7 but they can still be backported to Drupal 8.8. Therefore for sites running out of date core versions, getting them onto 8.8 first means they have the best chance of a smooth minor upgrade path before the major one.

2. Old updates may rely on deprecated APIs that are being removed in Drupal 9, and re-writing upgrade paths risk introducing new regressions.

3. Ensuring that every Drupal 8 site is on Drupal 8.8 or 8.9 before they update to Drupal 9 will drastically reduce the variables when upgrade paths are reported (compared to letting people update from Drupal 8.4 to Drupal 9 directly).

4. Contributed modules will also need to be updated to their latest versions prior to moving to Drupal 9, so ensuring core installs do this is encouragement to update contrib too.

Remaining tasks

Create a patch

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal 8 upgrade path has been removed.

In the last day or so, I've been trying to render a collapsible fieldset in a block and finding some difficulty in doing so. I realize that in D7, collapsible fieldsets are primarily designed to be used in forms, but it seems like it's especially difficult to use inside a block.

After seeing #42 in #857124: Collapsible fieldsets and vertical tabs do not work without form_builder() (Form API), I realized that part of the difficulty looks like a bug in either the block system or the logic that handles collapsible fieldsets. More specifically, though the documentation for hook_block_view() says that the 'content' key "...may be a renderable array (preferable)...", it actually has to contain a top-level key in order for the fieldset to render properly.

Examples are in order. This works (renders as a collapsible fieldset titled "Test"):

/**
 * Implements hook_block_view().
 */
function my_module_block_view($delta) {
  $wrapper = array(
    'fieldset' => array(
      '#type'       => 'fieldset',
      '#title'      => t('Sample fieldset'),
      '#attributes' => array('class' => array('collapsible', 'collapsed')),
      '#attached'   => array('js' => array('misc/collapse.js', 'misc/form.js')),
      'test'        => array(
        '#markup' => t('Test'),
      ),
    ),
  );

  $block = array(
    'content' => $wrapper,
  );

  return $block;
}

This doesn't (just renders as the text "Test"):

/**
 * Implements hook_block_view().
 */
function my_module_block_view($delta) {
  $wrapper = array(
    '#type'       => 'fieldset',
    '#title'      => t('Sample fieldset'),
    '#attributes' => array('class' => array('collapsible', 'collapsed')),
    '#attached'   => array('js' => array('misc/collapse.js', 'misc/form.js')),
    'test'        => array(
      '#markup' => t('Test'),
    ),
  );

  $block = array(
    'content' => $wrapper,
  );

  return $block;
}

Why is the extra top-level array necessary?

Since the release of Drupal 8.8.0, I haven't been able to run tests in my module CI environments (for an example, see this Honeypot failure).

I used to run the CI tests with the following structure:

1. Download Drupal tarball
2. Run composer install --dev
3. Require drush and run drush site:install
4. Enable my module + simpletest module
5. Run composer run-script drupal-phpunit-upgrade
6. Run core/scripts/run-tests.sh for my module

But now, when I do that, I get the following error on the drupal-phpunit-upgrade script:

  [InvalidArgumentException]                                      
  Script "drupal-phpunit-upgrade" is not defined in this package  

So I dropped that line, and then ran composer require phpunit/phpunit prior to running run-tests.sh. When I did run-tests.sh again, this resulted in the error:

  ERROR: PHPUnit testing framework version 7 or greater is required when running on PHP 7.3 or greater. Run the command 'composer run-script drupal-phpunit-upgrade' in order to fix this.

So... it's kind of a circular problem. I can't upgrade PHPUnit because the drupal-phpunit-upgrade script is missing completely. How are we to run PHPUnit tests in Drupal now?

Adding some probably-related issues.

Problem/Motivation

The description of a module on the Extend page, describes what the module does.
Not all module descriptions on the Extend page follow the common format, as described in the Help text standard.

In addition, module descriptions were reviewed and changed for Drupal 8, The module description on the Extend page, should follow the wording on the module's help page because these have been reviewed previously.

In general, "user" should be used to describe something that a user - with whatever role and appropriate permissions - can do, because we can't preempt what roles exist on site. The main point is to separate this from other modules, that don't result in users doing something.

Proposed resolution

Change the descriptions in the modules .info.yml files for the stable modules so that they are correct, consistent, and follow the same format.
Following comment #114, these descriptions of modules where the help text has been changed, are to go into a separate issue #3060616: Update the module descriptions on the Extend page to fit the Help texts
Experimental modules should have their own issues assigned because their functionality is still changing too much to hold up this issue in general.

Remaining tasks

• Split the existing patch into two, so that this only includes changes to the structure of the sentence, but no new wording.

.
Several modules were added to core in later versions since this issue was started (see #101 Media, Settings tray, Workflow, Datetime range, Migrate, Field layout, Layout builder, Media library and Workspace). If necessary these are fixed in separate issues to avoid further issue creep.

User interface changes

This is a UI text change.

API changes

None.

Data model changes

None.

Problem/Motivation

      @trigger_error('Automatically creating the first item for computed fields is deprecated in Drupal 8.5.x and will be removed before Drupal 9.0.0. Use \Drupal\Core\TypedData\ComputedItemListTrait instead.', E_USER_DEPRECATED);

\Drupal\Core\TypedData\Plugin\DataType\ItemList::get() should include field name/entity type or so in the message, because it's pretty annoying to even track down right now what is causing it.

Proposed resolution

Add more context.

Remaining tasks

Do it!

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

We implemented the WYSIWYG before the introduction of the green focus ring so it has its own custom focus effect which is much less visible than the green focus ring.

Proposed resolution

Add the green focus ring to the WYSIWYG element as defined in the style guide and implement that in Claro.

Remaining tasks

Manual testing in multiple browsers (Chrome, Firefox, Edge, Safari, IE11)
Update the before and after screenshots for the latest patch

User interface changes

Text areas will have the freen focus from now.

Problem/Motivation

The default Dropdown button is being implemented on #3023243: Drop Buttons style update. This issue is a follow-up to get the primary one addressed. At the moment this is not being used anywhere so we want to implement it for potential contrib use cases.

Specs:
FIGMA

Remaining tasks

• Accessibility review
• RTL review (Right to left)

Test Instructions

From comment #31 by @bnjmnm
A way to test the use of primary dropbuttons is with the Workbench Moderation module. If moderation is enabled on a content type, the submit button is converted to a dropbutton. (example: after enabling the module -- turn on moderation for the Article content type here /admin/structure/types/manage/article/moderation )

Problem/Motivation

The string '_none' is repeated throughout the module and tests, using a constant makes it easier to refactor.

Proposed resolution

1. Convert _none to a constant.
2. Move form_select_options() to a helper class.

API changes

String '_none' is converted to constant.

Beta phase evaluation

Problem/Motivation

Drupal\KernelTests\Core\Entity\ConfigEntityQueryTest::testCaseSensitivity can randomly fail.

1) Drupal\KernelTests\Core\Entity\ConfigEntityQueryTest::testCaseSensitivity
Failed asserting that 4 is identical to 3.

https://www.drupal.org/pift-ci-job/1508229

This is because entities with a label containing the word 'test' (e.g. '12test78') are occasionally generated.

$entity = ConfigQueryTest::create([
  'label' => $this->randomMachineName(),
  'id' => '1',
  'number' => 31,
  'array' => $array,
]);

// Filter by label with a known containing case-sensitive word.
$this->queryResults = $this->entityStorage->getQuery()
  ->condition('label', 'TEST', 'CONTAINS')
  ->execute();
$this->assertResults(['3', '4', '5']);

Proposed resolution

// Avoid the word 'test' in the label because filter by label with the word
// 'test' may randomly fail.
do {
  $label = $this->randomMachineName();
} while (stripos($label, 'test') !== FALSE);

$entity = ConfigQueryTest::create([
  'label' => $label,

Missing exit code statement is deprecated in Symfony 4.4 and causes type error in Symfony 5.

https://symfony.com/blog/new-in-symfony-4-4-console-improvements#make-it...

Problem/Motivation

ForumForm uses the old pattern of checking whether it is an add or an update form to provide dedicated messages.

Proposed resolution

Split ForumForm into ForumAddForm and ForumEditForm instead. One additional complexity is that ForumForm is extended by ContainerForm.

Remaining tasks

User interface changes

None.

API changes

None.

Problem/Motivation

Partly inspired by http://www.d7ux.org/roles-the-admin-header/ but I've been thinking about it for a while.

1. Authenticated user and anonymous user are somewhat drupalisms - or at least I've never seen them used elsewhere
2. It's been shown in UB user testing and anecdotally that lots of people don't understand giving a permission to auth users gives it to every logged in user. See #78941: Usability: Auto-check permissions if "authenticated" has them.
3. Anonymous users is terrible - these are visitors to the site, authenticated users can be 'anonymous' too.

So I suggest just 'logged in users' and 'visitors'.

Proposed resolution

"Anonymous user" role label changes to "Visitor" (singular)
"Authenticated user" role label changes to "Logged-in user" (singular)

Limit the change only to front-end labeling for Drupal 8.9.x and Drupal 9.0.x; change beyond UI needs to wait for Drupal 9.1.x.

I couldn’t find any similar issues on Drupal.org so I opened this one, if anyone knows of a similar issue please feel free to link and close this as duplicate.

Problem/Motivation

This was found while diagnosing an issue on the Scheduler module. However it also affects the “Authored On” field.
https://www.drupal.org/project/scheduler/issues/3085947

The node edit form's "Authored On" field uses the timezone of whatever user was on that form during the last cache clear. This can end up with a Chicago User saving a node that has an “Authored On” value in UTC.

This only seems to affect new nodes, editing existing nodes are not affected.

Steps to Reproduce
Requirements: Have two users, one with a UTC timezone and one with a Chicago Timezone

Step One: Create content as an UTC User

1. Log in as the UTC user
2. Clear the Drupal cache
3. Create a new Basic Page
4. Note the Authoring information (e.g 4:00:00 PM)
5. Save and publish the node.

Step Two: Create content as a Chicago User

1. Log in as the Chicago user
2. Do not clear the cache
3. Create a new Basic Page
4. Note the Authoring information
5. Observe that the Authoring information shows approximately the same time at UTC (e.g 4:02 PM)
6. This should show a time relative to Chicago (e.g 11:00 AM)

For authoring information this is relatively benign however it does impact Scheduling.

Proposed resolution

It looks like this is being caused by code in the Datetime::getInfo() method.

core/lib/Drupal/Core/Datetime/Element/Datetime.php

public function getInfo() {

      // .. node: some code removed for brevity …

     return [
      '#input' => TRUE,
      '#element_validate' => [
        [$class, 'validateDatetime'],
      ],
      '#process' => [
        [$class, 'processDatetime'],
        [$class, 'processAjaxForm'],
        [$class, 'processGroup'],
      ],
      '#pre_render' => [
        [$class, 'preRenderGroup'],
      ],
      '#theme' => 'datetime_form',
      '#theme_wrappers' => ['datetime_wrapper'],
      '#date_date_format' => $date_format,
      '#date_date_element' => 'date',
      '#date_date_callbacks' => [],
      '#date_time_format' => $time_format,
      '#date_time_element' => 'time',
      '#date_time_callbacks' => [],
      '#date_year_range' => '1900:2050',
      '#date_increment' => 1,
      // Timezone is set here and gets cached. 
      '#date_timezone' => drupal_get_user_timezone(),
    ];
} 

The getInfo() method only gets called on cache clear, therefore the element that gets loaded gets the timezone of whichever user loads the page after the cache is cleared.

This bug has seemingly been in place for some time, but it was made much more visible with the deprecation of drupal_get_user_timezone() in #2799987: Datetime and Datelist element's timezone handling is fragile, buggy and wrongly documented. Prior to that the site's timezone would be used rather than the server's timezone when caches are built without a user (eg, via drush, or some other backend process.)