We have quite some special behavior for uid #1. This tends to confuse the user, and will do so even more now we have an admin role in core. Do all the special cases we designed around uid #1 really make sense?

Problems with special casing uid 1

• People are confused whether they should be sharing credentials of this user (bad) or just using a user with the Administrator role.
• The lack of permission check on user 1 means that uid 1 can take actions on a site even if they do not have a role that grants them the permission. This makes it hard to completely disable unwanted features on a site unless you block uid 1 and never use it.
• The lack of permission check on user 1 makes them a particularly valuable account for an attacker to take over in some way. Any time there is a focus point for an attack it makes the system weaker.

Potential problems with *not* special casing

If someone is playing around and removes all roles or removes all permissions from all their admin users it could be possible to have no users with administrator permissions on a site. While is is a problem it is easily solved with a FAQ page and some database instructions just like we do with WSOD.

Proposed resolution

The special behaviour of uid 1 should be removed. Instead there is an admin role that always has all permissions. All special treatment for uid 1 should be converted to proper permissions, and as the admin role always has all permissions, any member of this role would have the same access as uid 1 has now. The following steps need to be taken:

1. Create an admin role by default, just like the anonymous and authenticated role, in the user module, and also make it undeletable, and make it the admin role.
2. Remove the is_admin_role setting from the GUI (simplifies the GUI).
3. Assign user 1 the admin role on install. (do this in the user module, not the chosen install profile).
4. When deleting or disabling a user, or removing the admin role from a user, check that there is at least one user left with the admin role, otherwise cancel the action.

User interface changes

The setting of which role is the admin role can be removed from admin/config/people/accounts.

API changes

When deleting or disabling a user, or removing the admin role from a user, check that there is at least one user left with the admin role, otherwise cancel the action. Also remove any special behaviour for uid 1. Test using an admin user with a uid greater than 1.

Beta phase evaluation

Problem/Motivation

Accidentally, we commited a transformed version of test file. The ES6 builder (Babel) removed some test cases from this file.

Proposed resolution

Restore the file and only non-JS only.

Remaining tasks

- Review

Problem/Motivation

The validation for path aliases should be the same whether saving through the admin interface (admin/config/search/path) or node edit forms. As identified in #1847174: Path alias validation should test for relative path, no trailing slash requirements, however, each of those has its own completely separate validation handler and automated tests, and they all behave a little different:

This leads to the following reproducable problem:

• Add a new node and give it a path alias of /node/add/page
• Try to add another node
• You can't

Proposed resolution

The validation logic should be consolidated--perhaps extracted into a nice, unit-testable utility function. The duplicativeness of the automated tests should be addressed, as well.

Remaining tasks

Fix, review, etc.

User interface changes

None.

API changes

tbd

As suggested by @WimLeers on #2888838: Remove render caching?, the render cache contains both data for the internal page cache and for the rest of the render cache mechanism, with different patterns of use and lifetime.

As such, it would make sense to allow splitting the page cache to a different bin.

Another big chunk of the render bin is about entity views which, as @Catch mentions, tend to be used only on one page at least in full mode, so maybe these could be moved there too.

Problem/Motivation

Render caching made sense when it was introduced in Drupal 7, and even when it was expanded to be used for many more things in Drupal 8.

But since then, Dynamic Page Cache was added in #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!). It's enabled by default. The benefit is that there's a single cache hit to render most of the page, rather than many fragments to retrieve from render cache. This saves a lot of I/O. And has a lower complexity.

Also important: there have been zero noteworthy bug reports during the 19 months that Drupal 8 has been out. In that time, Dynamic Page Cache has accelerated millions of page views.

That begs the question: do we still need render cache? Dynamic Page Cache is caching at a coarser level, so avoids lots of work. Maybe we don't need the granular caching layers as much anymore. That also greatly improves understandability/maintainability/DX. And the render cache bin is the one that has hundreds of thousands of cache items on big sites: #2526150-155: Database cache bins allow unlimited growth: cache DB tables of gigabytes!, so that'd go away too.

Can we remove render caching altogether? Or do we just disable it for e.g. blocks & entities, but keep it for Views, where it's likely most impactful?

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Problem/Motivation

Follow-up to #2865971: Use stylelint as opposed to csslint in core. Configure the shorthand-property-no-redundant-values to be consistent with https://www.drupal.org/docs/develop/standards/css/css-coding-standards

Proposed resolution

Brief instructions on running stylelint - you'll need npm...

All the commands below take place in DRUPAL_ROOT/core
To install stylelint

npm install

This will install Drupal 8's npm dependencies of which stylelint is one.

To run it on all core css files. Apply this issue's patch and do the following command from DRUPAL_ROOT/core

npm run lint:css

Remaining tasks

User interface changes

None

API changes

None

Problem/Motivation

Follow-up to #2865971: Use stylelint as opposed to csslint in core. Configure the selector-type-no-unknown to be consistent with https://www.drupal.org/docs/develop/standards/css/css-coding-standards

Proposed resolution

Brief instructions on running stylelint - you'll need npm...

All the commands below take place in DRUPAL_ROOT/core
To install stylelint

npm install

This will install Drupal 8's npm dependencies of which stylelint is one.

To run it on all core css files. Apply this issue's patch and do the following command from DRUPAL_ROOT/core

npm run lint:css

Remaining tasks

User interface changes

None

API changes

None

Problem/Motivation

Content Moderation sets the 'default revision' flag in \Drupal\content_moderation\Entity\Handler\ModerationHandler::onPresave() based on various logic checks in \Drupal\content_moderation\EntityOperations::entityPresave(), which prevents an entity validation restriction to be applied to an entity form.

For a concrete example: in #2858431: Book storage and UI is not revision aware, changes to drafts leak into live site we shouldn't allow users to submit the node form if they made any changes to the book outline and the new revision which results from that node form submission will not be a default revision. We should be able to simply throw an entity validation error and not allow the form to be submitted until either 1) the book changes are reverted or 2) the node will be made the default revision.

Proposed resolution

Move the logic from \Drupal\content_moderation\Entity\Handler\ModerationHandler::onPresave() and \Drupal\content_moderation\EntityOperations::entityPresave() somewhere in the entity form processing.

Remaining tasks

Do it.

User interface changes

Nope.

API changes

Not sure yet.

Data model changes

Nope.

Problem/Motivation

We need an endpoint to allow users to trigger the reset password process.

Proposed resolution

Create a router method within Drupal\user\Controller\UserAuthenticationController

Remaining tasks

1. Create the endpoint.
2. Create tests.

User interface changes

None.

API changes

None.

Data model changes

None.

In #2205271: Project namespace for dependencies support was added to allow modules to list dependencies by prefixing their names with their project name, thus solving the age-old problem of module names and project names being different (*cough* CCK *cough*). This API improvement was included in v7.40.

In #2844504: Testbot failing for Metatag-D7 =) it was identified that some of Metatag's tests were failing because the testci system was unable to download certain dependencies, specifically one submodule depending upon another submodule would fail if the dependency was listed in the old [module] syntax, it had to be listed in the newer [project:module] syntax.

It was reported in #2853699: Wrong dependency declaration by asacolips that this conflicts with installation profiles, which do not support the [project:module] syntax.

A simple example is the following:

• Download the latest Panopoly distribution release.
• Set it up somewhere so it can be installed.
• Download Metatag into the directory structure somewhere, e.g. sites/all/modules.
• Edit the panopoly.info file to list Metatag as a dependency, e.g.:
  

  diff --git a/panopoly.info b/panopoly.info
  index 2ee445e..2752de7 100644
  --- a/panopoly.info
  +++ b/panopoly.info
  @@ -21,6 +21,8 @@ dependencies[] = file
   dependencies[] = dblog
   dependencies[] = update
  
  +dependencies[] = metatag
  +
   ; Panopoly Foundation
   dependencies[] = panopoly_core
   dependencies[] = panopoly_images
  

• Hook up the codebase to the local web server and try to run the installer.
• The following requirements error will be reported:
  

  Required modules - Required modules not found.
  The following modules are required but were not found. Move them into the appropriate modules subdirectory, such as sites/all/modules. Missing modules: Drupal:system, Ctools:ctools, Token:token

• Further, if the dependency line in panopoly.info is changed to "dependencies[] = metatag:metatag" then the error becomes the following:
  

  Required modules - Required modules not found.
  The following modules are required but were not found. Move them into the appropriate modules subdirectory, such as sites/all/modules. Missing modules: Metatag:metatag

It seems like the dependency logic does not properly handle the [project:module] logic for modules available in the current codebase.

Problem/Motivation

admin/structure/block/demo has no test coverage.

Beta phase evaluation

Proposed resolution

Add test coverage with different themes, including testing the default theme, and ensure the link for "Exit block region demonstration" uses "admin/structure/blocks"

Remaining tasks

User interface changes

API changes

Problem/Motivation

If I run the multilingual moderation test and look at the database after, I get something like the following:

mysql> select langcode,revision_id,workflow,moderation_state from test89968991content_moderation_state_field_revision ORDER BY langcode;
+----------+-------------+-----------+------------------+
| langcode | revision_id | workflow  | moderation_state |
+----------+-------------+-----------+------------------+
| en       |           1 | editorial | draft            |
| en       |           2 | editorial | draft            |
| en       |           3 | editorial | draft            |
| en       |           4 | editorial | published        |
| en       |           5 | editorial | published        |
| en       |           6 | editorial | published        |
| en       |           7 | editorial | draft            |
| en       |           8 | editorial | draft            |
| fr       |           1 | NULL      | draft            |
| fr       |           2 | NULL      | draft            |
| fr       |           3 | NULL      | published        |
| fr       |           4 | NULL      | published        |
| fr       |           5 | NULL      | draft            |
| fr       |           6 | NULL      | published        |
| fr       |           7 | NULL      | published        |
| fr       |           8 | NULL      | draft            |
+----------+-------------+-----------+------------------+

'workflow' is defined as a translatable field, so when the translation is added, the workflow isn't copied from the source language.

Proposed resolution

Either:

• Make workflow non translatable (why is it in the first place?)
• Copy the workflow field from the source translation to the new, when creating the entity.

Remaining tasks

Agree, patch.

User interface changes

API changes

Data model changes

When setting the title of a View to a string containing a '&', the & gets rendered as & in the Views Preview.

So for example overriding the titles as such (where the title of the nid is 'Apples & Oranges'):

Articles about {{ arguments.nid }}

Renders:

Articles about Apples & Oranges

Where it should render:

Articles about Apples & Oranges

Problem/Motivation

ResourceTestBase is not usable out of the box for tests of non-entity resources. There are a number of problems one encounters:

1. $this->serializer is declared but never set
2. getExpectedBcUnauthorizedAccessMessage() needs to be implemented even though it is only needed for entity resources

Proposed resolution

1. Move the initialization of $this->serializer from EntityResourceTestBase to ResourceTestBase
2. Remove the abstract method getExpectedBcUnauthorizedAccessMessage()
3. Implement getExpectedUnauthorizedAccessMessage generically in ResourceTestBase

Remove the abstract definition of getExpectedBcUnauthorizedAccessMessage() from ResourceTestBase.

This is a follow-up for #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method.

It was deemed wiser to only apply this new test coverage to all entity types that already had some test coverage in the existing REST tests: Node, User, Term, EntityTest, Comment, Block, ConfigTest, Role and Vocabulary.
All other entity types are deferred to a follow-up […]

This is that follow-up.

Entity types to add test coverage for here:

Content entity types

1. MenuLinkContent: #2832859: Write EntityResourceTestBase subclasses for: MenuLinkContentAssigned to: webflo
2. BlockContent: #2835845: EntityResource: Provide comprehensive test coverage for BlockContent entityAssigned to: arshadcn
3. File: #2843139: EntityResource: Provide comprehensive test coverage for File entity, and tighten access control handler
4. Shortcut: #2843750: EntityResource: Provide comprehensive test coverage for Shortcut entity
5. Item: #2843752: EntityResource: Provide comprehensive test coverage for Item entityAssigned to: arshadcn
6. ContentModerationState: #2843753: EntityResource: Provide comprehensive test coverage for ContentModerationState entity
7. Feed: #2843754: EntityResource: Provide comprehensive test coverage for Feed entityAssigned to: rogierbom
8. Message: #2843755: Allow Message entities to be created (i.e. contact forms to be sent) via REST (was: "EntityResource: Provide comprehensive test coverage for Message entity")

Config entity types

1. FieldStorageConfig: #2843756: EntityResource: Provide comprehensive test coverage for FieldStorageConfig entityAssigned to: jamesdesq
2. FilterFormat: #2843757: EntityResource: Provide comprehensive test coverage for FilterFormat entity
3. View: #2843758: EntityResource: Remove ViewAccessControlHandler and provide comprehensive test coverage for View entityAssigned to: jamesdesq
4. SearchPage: #2843759: EntityResource: Provide comprehensive test coverage for SearchPage entity
5. ConfigurableLanguage: #2843761: EntityResource: Provide comprehensive test coverage for ConfigurableLanguage entity
6. Action: #2843762: EntityResource: Provide comprehensive test coverage for Action entity
7. ContentLanguageSettings: #2843763: EntityResource: Provide comprehensive test coverage for ContentLanguageSettings entityAssigned to: arshadcn
8. EntityFormDisplay: #2843764: [PP-1] EntityResource: Provide comprehensive test coverage for EntityFormDisplay entity
9. EntityViewDisplay: #2843765: [PP-1] EntityResource: Provide comprehensive test coverage for EntityViewDisplay entity
10. FieldConfig: #2843766: EntityResource: Provide comprehensive test coverage for FieldConfig entity
11. BaseFieldOverride: #2843767: EntityResource: Provide comprehensive test coverage for BaseFieldOverride entity + add missing access control handlerAssigned to: arshadcn
12. Tour: #2843768: EntityResource: Provide comprehensive test coverage for Tour entity
13. ResponsiveImageStyle: #2843770: EntityResource: Provide comprehensive test coverage for ResponsiveImageStyle entity
14. RdfMapping: #2843771: EntityResource: Add an admin permission to RdfMapping entity and provide comprehensive test coverage
15. DateFormat: #2843772: EntityResource: Provide comprehensive test coverage for DateFormat entity
16. RestResourceConfig: #2843773: EntityResource: Provide comprehensive test coverage for RestResourceConfig entityAssigned to: Wim Leers
17. BlockContentType: #2843774: EntityResource: Provide comprehensive test coverage for BlockContentType entityAssigned to: jamesdesq
18. CommentType: #2843775: EntityResource: Provide comprehensive test coverage for CommentType entityAssigned to: arshadcn
19. EntityTestBundle: #2843776: EntityResource: Provide comprehensive test coverage for EntityTestBundle entity
20. NodeType: #2843777: EntityResource: Provide comprehensive test coverage for NodeType entityAssigned to: arshadcn
21. ContactForm: #2843778: EntityResource: Provide comprehensive test coverage for ContactForm entityAssigned to: naveenvalecha
22. ShortcutSet: #2843779: EntityResource: Provide comprehensive test coverage for ShortcutSet entity
23. EntityFormMode: #2843780: [PP-1] EntityResource: Provide comprehensive test coverage for EntityFormMode entityAssigned to: jamesdesq
24. EntityViewMode: #2843781: EntityResource: Provide comprehensive test coverage for EntityViewMode entity
25. Editor: #2843782: EntityResource: Provide comprehensive test coverage for Editor entityAssigned to: arshadcn
26. Menu: #2843783: EntityResource: Provide comprehensive test coverage for Menu entity
27. ModerationStateTransition: #2843784: EntityResource: Provide comprehensive test coverage for ModerationStateTransition entity
28. ModerationState: #2843785: EntityResource: Provide comprehensive test coverage for Workflow entity
29. ImageStyle: #2843786: EntityResource: Provide comprehensive test coverage for ImageStyle entity

Problem/Motivation

Follow-up to #2865971: Use stylelint as opposed to csslint in core. Configure the function-whitespace-after to be consistent with https://www.drupal.org/docs/develop/standards/css/css-coding-standards

Proposed resolution

Brief instructions on running stylelint - you'll need npm...

All the commands below take place in DRUPAL_ROOT/core
To install stylelint

npm install

This will install Drupal 8's npm dependencies of which stylelint is one.

To run it on all core css files. Apply this issue's patch and do the following command from DRUPAL_ROOT/core

npm run lint:css

Remaining tasks

User interface changes

None

API changes

None

Problem/Motivation

There's a config:

system.performance response.gzip

...which is defined in core/modules/system/config/schema/system.schema.yml and is mapped to the D6/7 variable page_compression e.g. in core/modules/system/migration_templates/d6_system_performance.yml

However, after the changes to page cache in #2368987: Move internal page caching to a module to avoid relying on config get on runtime it seems that response.gzip doesn't actually do anything any more.

In fact, it looks like consensus was reached in #28 of that issue that this should be removed:

catch and [Wim Leers] agreed that the best way forward was to simply remove the "Compress cached pages"/response.gzip

It seems that the changes committed didn't remove response.gzip though.

Proposed resolution

Remove response.gzip and remaining references to it e.g.

core/modules/page_cache/src/Tests/PageCacheTest.php:228:    $config->set('response.gzip', 1);
core/modules/system/migration_templates/d6_system_performance.yml:17:  'response/gzip': page_compression
core/modules/page_cache/src/StackMiddleware/PageCache.php:184:   * If page_compression is enabled, a gzipped version of the page is stored in

core/modules/system/config/schema/system.schema.yml:189:        gzip:
core/modules/system/config/schema/system.schema.yml-190-          type: boolean
core/modules/system/config/schema/system.schema.yml-191-          label: 'Compress cached pages'

Remaining tasks

Review patch to remove response.gzip and remaining references to it.

User interface changes

None - the "Compress cached pages" option is already gone from the UI.

API changes

None.

Data model changes

None.

Problem/Motivation

If our goal is to segregate our interfaces by workflow types that are configurable and workflows that are not, I think it makes sense to move the methods for transition/state forms to WorkflowTypeFormInterface/WorkflowTypeFormBase.

That leaves implementations of workflow types that are simple and don't require the collection of extra information for states/transitions/as a whole light.

Proposed resolution

Move these methods.

Remaining tasks

Discuss and agree on an approach.

User interface changes

API changes

Data model changes

Problem/Motivation

Follow-up to #2865971: Use stylelint as opposed to csslint in core. Configure the declaration-block-no-shorthand-property-overrides to be consistent with https://www.drupal.org/docs/develop/standards/css/css-coding-standards

Proposed resolution

Brief instructions on running stylelint - you'll need npm...

All the commands below take place in DRUPAL_ROOT/core
To install stylelint

npm install

This will install Drupal 8's npm dependencies of which stylelint is one.

To run it on all core css files. Apply this issue's patch and do the following command from DRUPAL_ROOT/core

npm run lint:css

Remaining tasks

User interface changes

None

API changes

None

Problem/Motivation

Follow-up to #2865971: Use stylelint as opposed to csslint in core. Configure the declaration-block-no-redundant-longhand-properties to be consistent with https://www.drupal.org/docs/develop/standards/css/css-coding-standards

Proposed resolution

Brief instructions on running stylelint - you'll need npm...

All the commands below take place in DRUPAL_ROOT/core
To install stylelint

npm install

This will install Drupal 8's npm dependencies of which stylelint is one.

To run it on all core css files. Apply this issue's patch and do the following command from DRUPAL_ROOT/core

npm run lint:css

Remaining tasks

User interface changes

None

API changes

None