Problem/Motivation

Spin-off from #3063887: Support PHPUnit 8 optionally in Drupal 8, while keeping support for ^6.5 and ^7.

In order to make the test codebase forward compatible with PHPUnit 8, the big problem is that PHPUnit 8 is changing the signature of the main test methods that test classes extend - above all setUp() and tearDown, adding a void return typehint.

In this issue we explore the option 1 of #3063887: Support PHPUnit 8 optionally in Drupal 8, while keeping support for ^6.5 and ^7, i.e. Change the signatures of the methods in Drupal test code according to PHPUnit 8.

While this is not a problem for Drupal 9 core, that supports PHP 7.3+, this will have the impact of forcing testing for contrib/custom modules only on PHP 7.1+ (the minimum that allows specifying a void return typehint to methods).

Setting to critical since per @xjm at #3063887-39: Support PHPUnit 8 optionally in Drupal 8, while keeping support for ^6.5 and ^7

If anything I'd want to make the break in 9.0 rather than 9.1 because that's a massive change.

Proposed resolution

Change all the implementations of

• setUp()
• tearDown()
• setUpBeforeClass()
• assertPostConditions()

in test classes to have a void return typehint.

Remaining tasks

Discuss.
Patch.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Similarly to #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5, this issue is about enabling testing with PHPUnit 8 in Drupal 8.

PHPUnit 6 is out of support since Feb 1, 2019
PHPUnit 7 will be end of support Feb 7, 2020
PHPUnit 8 will be supported until Feb 5, 2021
PHPUnit 9 will be released Feb 2020.

The big problem with PHPUnit 8 is that it is changing the signature of the main test methods that test classes extend - above all setUp() and tearDown.

This means that ALL the 1700+ implementations of setUp() and the 30 of tearDown() in Drupal test code will have to be touched one way or another - unless I'm mistaken.

Also, in PHPUnit8 several assertions methods are deprecated for removal in PHPUnit9, for example:

• Using assertContains() with string haystacks is deprecated and will not be supported in PHPUnit 9. Refactor your test to use assertStringContainsString() or assertStringContainsStringIgnoringCase() instead.
• The @expectedException, @expectedExceptionCode, @expectedExceptionMessage, and @expectedExceptionMessageRegExp annotations are deprecated. They will be removed in PHPUnit 9. Refactor your test to use expectException(), expectExceptionCode(), expectExceptionMessage(), or expectExceptionMessageRegExp() instead.
• assertInternalType() is deprecated and will be removed in PHPUnit 9. Refactor your test to use assertIsArray(), assertIsBool(), assertIsFloat(), assertIsInt(), assertIsNumeric(), assertIsObject(), assertIsResource(), assertIsString(), assertIsScalar(), assertIsCallable(), or assertIsIterable() instead.
• assertArraySubset() is deprecated and will be removed in PHPUnit 9.
• getObjectAttribute() is deprecated and will be removed in PHPUnit 9.
• readAttribute() is deprecated and will be removed in PHPUnit 9.

Open points

• None at the moment.

Spun off issues

• #3094151: ExpectDeprecationTrait is not compatible with PHPUnit 8

Done

• #3097822: Drupal\migrate_drupal\Tests\StubTestTrait is not compatible with PHPUnit 8
• MigrateExecutableMemoryExceededTest - it has mock expectation fails in PHPUnit8 due to inconsistent matches(). Added a @todo and commented out the failing tests. #3102903: MigrateExecutableMemoryExceededTest has mismatched argument type mock expectations (and fails in PHPUnit8)
• ViewExecutableTest - it has mock expectation fails in PHPUnit8 due to callback return type should be bool and not string. Added a @todo and commented out the failing tests. #3102899: ViewExecutableTest uses a mocked argument callback wrongly (and fails in PHPUnit8)

Proposed resolution

I can see two options:

1. Change the signatures of the methods in Drupal test code according to PHPUnit 8

This will have the impact of forcing testing only on PHP 7.1+ (the minimum that allows specifying a void return typehint to methods), and from the day such a change will be in core, all contrib module will have to comply or fail tests.

2. Introduce a compatibility layer

1. A new Drupal\Tests\BaseTestClass, extending from PHPUnit\Framework\TestCase, is the new base class for ANY Drupal test, being Unit, Kernel, Functional, etc
2. The Drupal\Tests\BaseTestClass is actually aliased to a Drupal\TestTools\PhpUnitCompatibility\PhpUnit#\BaseTestCase class, one for each PHPUnit version, using the compatibility layer mechanism put in place to support PHPUnit 7. These aliased classes hold the override of the ::setUp(), ::tearDown(), etc methods, type hinted according to the specific PHPUnit version.
3. Each overridden method calls a corresponding proxy in the test class so ::setUp() -> ::xxxSetup(). The naming tbd.
4. ALL test classes in Drupal have to rename their PHPUnit overriding methods to the proxies, and any call to parent::method() to the parent proxy, too i.e. parent::setUp() --> parent::xxSetUp()

Remaining tasks

A lot

User interface changes

None

API changes

Some

Data model changes

None

Release notes snippet

TBD

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3106154`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

2️⃣ State of deprecated API removal in core (edited) 

3️⃣ Requiring PHP 7.3 for Drupal 9

4️⃣ New Upgrade Rector module based on Palantir.net’s updated Drupal8-rector!

5️⃣ Deprecated Twig coverage and deprecated CSS/JS library coverage in Upgrade Status (edited) 

6️⃣ The state of layout builder vs. field layout for Drupal 9

7️⃣ Update path critical issues that block people from updating from earlier Drupal 8 versions to current 8 (and therefore 9)

8️⃣ YOUR projects’ Drupal 9 plans :slightly_smiling_face:

9️⃣ Drupal Global Contribution Weekend Jan 24-26 this weekend, who has plans? :slightly_smiling_face: (edited) 

🔟 That’s it for this week’s meeting, keep up the great work folks! See you same time next Monday! #3107517: Drupal 9 readiness meeting / 27 January 2020 (edited) 

Only 39 days left until the first beta deadline today :slightly_smiling_face: (edited) 

FILE: /core/modules/user/src/Plugin/Block/UserLoginBlock.php
------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AND 2 WARNINGS AFFECTING 3 LINES
------------------------------------------------------------------------------------------------------------------
85 | WARNING | \Drupal calls should be avoided in classes, use dependency injection instead
116 | WARNING | \Drupal calls should be avoided in classes, use dependency injection instead

FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
-----------------------------------------------------------------------------------------------------------------------------------------
66 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
86 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
-----------------------------------------------------------------------------------------------------------------------------------------
/core/modules/user/src/Plugin/Action/ChangeUserRoleBase.php
-----------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------------------------------------
65 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead

FILE: core/modules/user/src/Access/RegisterAccessCheck.php
-----------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------------
25 | WARNING | \Drupal calls should be avoided in classes, use dependency injection instead

FILE: core-9/drupal/core/modules/user/src/UserListBuilder.php
------------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
------------------------------------------------------------------------------------------------------------------------------------------
149 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead

FILE: core/modules/user/tests/src/Kernel/Views/HandlerFieldPermissionTest.php
-----------------------------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 4 WARNINGS AFFECTING 4 LINES
-----------------------------------------------------------------------------------------------------------------------------------------
37 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
40 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
41 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
42 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead

FILE: core/modules/user/tests/src/Kernel/UserValidationTest.php
----------------------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AND 10 WARNINGS AFFECTING 11 LINES
----------------------------------------------------------------------------------------------------------------------------------------------
94 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
106 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
115 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
126 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
128 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
135 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
140 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
183 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
205 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
220 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead

FILE: core/modules/user/tests/src/Functional/UserCancelTest.php

59 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
90 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
93 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
116 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
143 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
147 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
148 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
153 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
161 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
189 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
190 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
191 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
192 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
197 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
198 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
207 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
249 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
250 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
251 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
255 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
256 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
264 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
329 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
330 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
331 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
335 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
336 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
361 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
389 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
390 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
391 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
395 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
396 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
437 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
438 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
439 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
456 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
457 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
458 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
462 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
463 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
480 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
498 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
499 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
500 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
503 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
504 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
526 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
527 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
528 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
531 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
532 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
564 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
565 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
566 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
567 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
568 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
571 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead
581 | WARNING | [ ] t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead

Problem/Motivation

jquery.cookie is no longer a maintained library. A replacement should be found.

> git grep core/jquery.cookie core\core.libraries.yml | wc -l
      3
	    
> git grep -l cookie -- "*.js"
core/assets/vendor/jquery-joyride/jquery.joyride-2.1.min.js
core/assets/vendor/jquery.cookie/jquery.cookie.min.js

This is used in jquery.joyride and the only real usage I have found. Also, jquery.joyride is not hard dependency on cookies.
https://github.com/zurb/joyride/blob/v2.1.0/jquery.joyride-2.1.js#L32

Proposed resolution

Replace jquery.cookie with js-cookie library adding a backwards-compatibility layer. We can model the BC layer off of js-cookie v1.5.1 as well as the js-cookie v2.0.0 release notes (#26).

This approach was originally reviewed by droplet and confirmed by _nod in 2017. There is now a major version 3 in js-cookie that has a beta release. Should we continue to implement js-cookie 2, wait until 3, or find a different dependency to use?

Remaining tasks

• Review approach by JavaScript subsystem maintainers
• Write a change record documenting all the BC notes in the issue for using js-cookie 2.2.1 directly rather than jquery.cookie.
• Write release note snippet

API changes

Yes, with backwards-compatibility layer.

Release notes snippet

TBD

Problem/Motivation

As stated in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

Part of this process includes creating theme-specific copies of all Classy libraries to core themes. This ensures Classy can be removed without impacting those themes.

Proposed resolution

- As needed ,copy libraries and assets from Classy to Umami.
- Create new libraries for every copied library, named with the convention "classy.
".
- Override the Classy libraries so they are not loaded by Umami.
- Any Classy libraries-extend: should now be taken care of in Umami.
The end result is no Classy library assets should load, and Umami experience should be unchanged.

Also: add tests that check to see if any of the copied assets from Classy have changed. If they've changed, there should be a failure that provides instructions on moving the altered file out of the /classy subdirectory.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When an exposed filter is using groups, and the Allow multiple selections option is enabled, the code ignores the configured selector (based on number of groups) and forces checkboxes:

    if (count($groups)) {
      $value = $this->options['group_info']['identifier'];

      $form[$value] = [
        '#title' => $this->options['group_info']['label'],
        '#type' => $this->options['group_info']['widget'], // This is the configured widget option.
        '#default_value' => $this->group_info,
        '#options' => $groups,
      ];
      if (!empty($this->options['group_info']['multiple'])) {
        if (count($groups) < 5) {
          $form[$value]['#type'] = 'checkboxes'; // Here it is forced to checkboxes if less than 5 groups.
        }
        else {
          $form[$value]['#type'] = 'select'; // Here it is forced to select.
          $form[$value]['#size'] = 5;
          $form[$value]['#multiple'] = TRUE;
        }

Proposed resolution

Don't ignore the configured widget setting.

Remaining tasks

User interface changes

API changes

Data model changes

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3107517`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

:zero: Who is here today? Comment in the thread below to introduce yourself.

:one: Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.

:two: TBD

Problem/Motivation

The critical need

As documented in #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path, jQueryUI is deprecated in Drupal9 core. In Drupal 9, contrib themes dependent on jQueryUI should be satisfying their jQueryUI requirements via the contrib jQueryUI modules. It needs to be possible for these themes to declare these contrib modules as dependencies.

Additional motivation

Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

Proposed resolution

• Allow themes to add the dependencies to .info.yml files
• Show these dependencies on /admin/appearance and make it impossible to install without the requirements via UI or command line
• Install dependencies automatically on API level.Moved to followup #3100374: Make it possible to install dependent modules when installing theme
• Validation is added to prevent installing themes that depend on uninstalled modules, and prevent uninstalling modules that are depended upon by installed themes. This is implemented at a level that prevents these installs/uninstalls from occurring programatically or via cli (Drush/Drupal Console).

Follow-ups

1. #3100374: Make it possible to install dependent modules when installing theme
2. Update #3005229: Provide optional support for using composer.json for dependency metadata to read composer.json theme's also

User interface changes

Themes listed in admin/appearance will list the modules they depend on and the ability to install that theme will not be available unless those module dependencies are met.
The module descriptions found at admin/modules and admin/module/uninstall will include themes in their "Required By" description.

API changes

Themes will be able to define modules dependencies in their info.yml via the dependencies key.

Release notes snippet

Pending.

Original report by [eaton]

Issue Summary
Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

Problem/Motivation

Issues we're trying to solve

• core: 8.x in an info file is restrictive
• we invented our own dependency syntax that is overly complex because of the optional core major version
• we want to move away from having the major version in the module version (e.g. 8.x-1.x » 1.0.0)
• we want to move core away from version: VERSION so we can do subtree splitting
• we want contrib modules to be able to declare their composer dependencies - e.g my module 1.3 needs symfony/yaml 4.0
• as a bonus, themes could rely on modules

@sun suggested this in #1936886-21: Rename $module.info.yml into extension.yml

Proposed resolution

use composer.json for

• discovery of themes/modules/profiles/engines
• dependency declaration
• version numbering

Deprecate the dependencies, type and version keys in info.yml files

Remaining tasks

Wind back to the scope of comment #39

User interface changes

API changes

Data model changes

This might be a known issue, I tried searching was not able to find what I was experiencing.

The problem I am experiencing is some menu links are not properly showing up. Some of them will disappear if my chrome or firefox browser is zoomed in at 100%. When I zoom out to around 80% they show up again. I was wondering if anyone else has experienced this before.

Thank you.

Problem/Motivation

In order to add target="_blank" to a file link, I had to replicate most of template_preprocess_file_link. The documentation for $variables['attributes'] ("An associative array of attributes to be placed in the a tag") is wrong after #2236855: Use CSS for file icons in file fields

Proposed resolution

Add a link_attributes variable to the template?

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

I add some bundle specific fields via hook_entity_bundle_field_info as should be controlled in code rather than config, but the entity type belongs to another module. However, although the tables are correctly created, the entity.definitions.bundle_field_map state key is never updated with the new fields. This means any future calls to \Drupal\Core\Entity\EntityFieldManager::getFieldMap are unaware of the field (despite it existing).

I think the two scenarios this causes problems are:

• Module install for existing bundles
• Bundle creation

I expect there is also going to be the reverse issue on module/bundle uninstall (bundle install may not matter too much).

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

Probably none.

Problem/Motivation

In Drupal 7, thanks to the implementation of l(), an "active" class was automatically added when generating node listing with views, and when the linked entity's URI was the same as the one listed.

With #1979468: ".active" from linkGenerator(), l() and theme_links() forces an upper limit of per-page caching for all content containing links, this is not the case any more and it's been reported to not be not easily alterable.

Proposed resolution

Re add the feature as optional, via means of adding a new checkbox form field to control whether or not the active class on links will be enabled. Adding of the actual CSS class is performed via JS.

Remaining tasks

1. Write the patch
2. Review it
3. Add test coverage for the new feature.
4. Write upgrade path to update existing views on sites.
5. Write upgrade path test to verify it works.

User interface changes

New Set the active class on links checkbox on views field options. Description: If checked, if the fields link to the current page, an "is-active" class will be added on active links.

API changes

New set_active_class boolean on views.row.schema

Data model changes

N/A

Release notes snippet

Views can now optionally add the "active" css class.

Original description

In Drupal 7, thanks to the implementation of l(), an "active" class was automatically added when generating node listing with views, and when the linked entity's URI was the same as the one listed.

With #1979468: ".active" from linkGenerator(), l() and theme_links() forces an upper limit of per-page caching for all content containing links, this is not the case anymore and it seem's not easily alterable (I can't my way through).

Is there a way to change this behaviour. Are we missing something in core to let us alter that ?

Problem/Motivation

See core\modules\views\src\Routing\ViewPageController.php

$build = $class::buildBasicRenderable($view_id, $display_id, $args, $route);
Warning in IDE "Method call uses 4 parameters, but method signature uses 3 parameters".

/** @var \Drupal\views\Plugin\views\display\DisplayPluginBase $class */
$class = $route->getOption('_view_display_plugin_class');
if ($route->getOption('returns_response')) {
  /** @var \Drupal\views\Plugin\views\display\ResponseDisplayPluginInterface $class */
  return $class::buildResponse($view_id, $display_id, $args);
}
else {
  $build = $class::buildBasicRenderable($view_id, $display_id, $args, $route);
  Page::setPageRenderArray($build);

  views_add_contextual_links($build, 'page', $display_id, $build);

  return $build;
}

Proposed resolution

--- a/core/modules/views/src/Routing/ViewPageController.php
+++ b/core/modules/views/src/Routing/ViewPageController.php
@@ -47,7 +47,7 @@ public function handle($view_id, $display_id, RouteMatchInterface $route_match)
       }
     }

-    /** @var \Drupal\views\Plugin\views\display\DisplayPluginBase $class */
+    /** @var \Drupal\views\Plugin\views\display\Page $class */
     $class = $route->getOption('_view_display_plugin_class');
     if ($route->getOption('returns_response')) {
       /** @var \Drupal\views\Plugin\views\display\ResponseDisplayPluginInterface $class */

When creating the image style and hover on the anchor instead of hovering over the particular box it is showing a hover effect on the whole row.
Steps to Reproduce

1. Create new image style
2. Add Scale and Crop as a style

For example Hovering on A11 Brings hover effect on A12 and A13 also

I hace nothing found about
i have updatet from 8.7.11 to 8.8.1

PHP
Version
7.1.33

Datenbank
Version
5.7.25
System
MySQL,

Webserver
Apache

The website encountered an unexpected error. Please try again later.
Error: Call to a member function hasPermission() on null in comment_node_update_index() (line 458 of core/modules/comment/comment.module).
comment_node_update_index(Object)
call_user_func_array('comment_node_update_index', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('node_update_index', Array) (Line: 539)
Drupal\node\Plugin\Search\NodeSearch->indexNode(Object) (Line: 500)
Drupal\node\Plugin\Search\NodeSearch->updateIndex() (Line: 181)
search_cron()
call_user_func_array('search_cron', Array) (Line: 392)
Drupal\Core\Extension\ModuleHandler->invoke('search', 'cron') (Line: 236)
Drupal\Core\Cron->invokeCronHandlers() (Line: 134)
Drupal\Core\Cron->run() (Line: 75)
Drupal\Core\ProxyClass\Cron->run() (Line: 166)
Drupal\system\Form\CronForm->runCron(Array, Object)
call_user_func_array(Array, Array) (Line: 112)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 591)
Drupal\Core\Form\FormBuilder->processForm('system_cron_settings', Array, Object) (Line: 320)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 91)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 694)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

greetings

Problem/Motivation

#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates we are switching to a new XML feed from drupal.org that provides supported_branches instead of supported_majors and some other metadata changes.

#3074993 is changing to this new XML feed but keeping the current functionality based on majors. For instances if:

• The site's current core version is 8.7.0
• The latest 8.7.x release is 8.7.10
• The latest 8.8.x release is 8.8.0
• the project XML has <supported_branches>8.7.,8.8.x</supported_branches>

currently 8.8.0 will be the recommended release even 8.7.10 is still release on a supported branch and doesn't require jumping to the next minor version of core which can be disruptive.(this will be the same after (#30749930)

Currently this does not affect contrib because support branches are the same as minors. this will change when #2681459: Support contrib semver releases is done.

Proposed resolution

The update module should recommend the latest release for the current branch if it is still supported. It should also indicate there is another release on the next supported branch.

Remaining tasks

Determine if this is the desired functionality

User interface changes

User shown updates by supported branch

API changes

Data model changes

Release notes snippet

Following is the current language fallback logic used in the path.alias_repository service:

    // Always get the language-specific alias before the language-neutral one.
    // For example 'de' is less than 'und' so the order needs to be ASC, while
    // 'xx-lolspeak' is more than 'und' so the order needs to be DESC.
    $langcode_list = [$langcode, LanguageInterface::LANGCODE_NOT_SPECIFIED];

This logic doesn't take into account where custom/contrib modules may implement hook_language_fallback_candidates_alter() to add/remove fallback candidate languages.

Example of one such contrib module:
Language hierarchy: https://www.drupal.org/project/language_hierarchy

Attaching a patch to user proper fallback mechanism. i.e.:

    // Get list of all languages that current language falls back on.
    $langcode_list = $this->languageManager->getFallbackCandidates([
      'langcode' => $langcode,
      'operation' => 'path_alias',
    ]);

Problem/Motivation

Drupal\Core\Extension has plenty of deprecated code. Let's remove it.

Proposed resolution

Remove the deprecated code.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a