Problem/Motivation

The node preview system in Drupal 8 was written as a stop-gap solution with known deficiencies and hope that some day a more robust solution will eventually take its place.

Proposed resolution

Since the Workspace module provides a clean way to achieve "entity previews" in a non-live environment, we should be able to leverage it for nodes.

Remaining tasks

#2972622: Split the workspaces UI into a separate module

User interface changes

TBD.

API changes

Various node preview hacks will be removed.

Data model changes

TBD.

Problem/Motivation

There was a failure when converting install time hooks so I moved converting that to this issue.

Steps to reproduce

Convert experimental_module_requirements_test_requirements to InstallRequirements.php

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

The file NodeViewsData.php, which implements a single function, getViewsData() should be a model of good organization and well documented.

This function returns an array with the structure documented in hook_views_data(). It is pretty complicated, with a lot of options. (In other words, not all of Drupal 7's info arrays were replaced by more object-oriented structures.) Anyone who has to implement that hook, or the related alter hook, and wants more examples than in the API documentation is going to look first at NodeViewsData.php. It has a lot of examples that affect options (fields, sorts, relations) that are familiar to anyone who has used Views.

Proposed resolution

Add an @see comment pointing to the documentation for hook_views_data().

Reorganize the function so that everything related to one primary key is in the same place. As it is now, I see a few lines related to $data['node']['node_bulk_form'], and later more lines for $data['node']['node_listing_empty'], interrupting the long definition of $data['node_field_data'].

Consider splitting off into a separate function the part that applies only if the Search module is enabled.

Add code comments explaining how each section affects what a site builder sees when working with Views.

Remaining tasks

User interface changes

None. This issue is all about developer experience (DX). If it is done correctly, it will have no effect on functionality nor interface.

API changes

None

Data model changes

None

Problem/Motivation

function foo_entity_delete(EntityInterface $entity) {
  $context = EntityContext::fromEntity($entity);
}

This will fail.

Introduced in #2791269: Allow saving pre-existing references to inaccessible items

Proposed resolution

If \Drupal\Core\Entity\Plugin\Validation\Constraint\ValidReferenceConstraintValidator::validate() can't load the unchanged entity from the DB (because it no longer exists), use the one we have

This ticket is now a clean up of a todo and update InlineBlockEntityOperations::handleEntityDelete() to use isLayoutCompatibleEntity()

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Where do you go to change the lablels on all the fields on your node form? Well, for every single field except one, you go to the "Manage fields" tab for your content type. I know title is special, but if we want people to be able to find this setting intuitively, we need to move it to where people will look for it naturally :)

Problem/Motivation

In #2691675: Replace deprecated entityManager() in ControllerBase descendents, we noticed that NodePreviewController::title() is not called once in our tests, despite actually being defined as the title_callback.

It's not called because the parent controller sets #title directly, and we never try to get the title for that route from elsewhere (e.g. breadcrumb). And it woud most likely not work anyway as it relies on being able to dynamically load the node through the query argument and then state.

Proposed resolution

Deprecate the untested code, replace it with a static _title: "Node preview" or so title as it doesn't really matter anyway. Maybe even remove completely, not sure what our policy on that one is.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

This is a follow-up and is postponed on #2765065: [PP-1] Allow plurals on bundle labels.

Problem/Motivation

Starting with #2765065: [PP-1] Allow plurals on bundle labels, bundle config entities are able to store plural labels. In the same issue the node_type config entity was extended to allow this new feature and plural labels were added to the node types shipped with Drupal core. However, while an application is able to change those values or provide plural labels to custom node types via configuration import, this is not yet possible via UI.

Proposed resolution

Add the ability to NodeTypeForm to add/edit/save node type plural labels. Keep in mind that:

• Sites installed in some other languages than English could have more than 2 count plural variants.
• Multiple, contextualised, count label versions should permitted.

Remaining tasks

None.

User interface changes

User is able to add plural variants in NodeTypeForm UI (screenshots needed).

API changes

None.

Data model changes

None.

The widescreen media query used in the node.module.css for widescreens catches mobile Android when the keyboard drawer is open.

This was with my Pixel 3 device. I don't have another device around to test, yet.

---

I have no idea how to best word this. When the keyboard opens to add body text or title, the viewpoint must change and the form sidebar comes up and the entity form isn't usable.

Here are a video and screenshot.

😱 It's not Claro, it's node.module.css.

/* Wide screens */
@media
  screen and (min-width: 780px),
  (orientation: landscape) and (min-device-height: 780px) {

This media query catches the open keyboard drawer.

Problem/Motivation

Followup from #2461049: Node module permissions are broken if hook_node_grants is implemented.

The node grant/access record system has a behavior where if no hook_node_grant() implementations are defined and therefore no modules provide node access records for specific nodes, a global "view all grant" is written instead. Having this default behavior buried inside the storage is already confusing, but the documentation for it is already pretty thin. The NodeGrantDatabaseStorageInterface::writeDefault()method docs say:

Creates the default node access grant entry.

...So that's nice but what is the "default node access grant entry"?
There is also no documentation inside the main implementation of NodeGrantDatabaseStorage::writeDefault() about what the "default grant" is (i.e., fall back to a view access grant for all).

Also see

Furthermore, none of the classes and interfaces involved in node access belong to the node access documentation topic, so the default behavior is not discoverable or clear in the "big picture" there. This is important because "view access for all but no edit nor delete access" is only the default behavior when (a) the "bypass node access" permission is not granted (b) the "view published content" permission is granted (c) no hook_entity_access() or hook_node_access() implementations already allowed or denied access for the operation (d) the node is not unpublished.

Finally, this logic seems somewhat like it should be part of the node access control handler (as a conceptual default behavior), and the storage implementation should just be... a storage implementation. #2461049: Node module permissions are broken if hook_node_grants is implemented adds the logic as actual code, but then it's in two places. Maybe there should be a grantDefaultAccess() method or something that we factor out?

Proposed resolution

1. Improve the NodeGrantDatabaseStorage::writeDefault() method docblock and the NodeAccessControlHandlerInterface::writeDefaultGrant() documentation.
2. Add inline documentation to NodeGrantDatabaseStorage::writeDefault() explaining what logic the storage implementation is implementing.
3. Clarify the default grant behavior in the node access group documentation.
4. Decide whether we should factor out the logic of the default behavior into its own method (or something).

Related: #2473123: Add node grant classes and interfaces to the node access topic

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Postponed until

#2461049: Node module permissions are broken if hook_node_grants is implemented

Problem/Motivation

In system_theme_suggestions_maintenance_page(), a template suggestion is provided for maintenance-page--offline.html.twig:

if ($offline) {
  $suggestions[] = 'maintenance_page__offline';
}

However, this template is not picked up when the system is offline. This results in a generic, unstyled exception page (i.e. a WSOD), creating a poor user experience. This is functionality that did exist and work in Drupal 7, and an attempt was made to have this functionality ported to Drupal 8, but appears to not have been completed/successful.

This is a major issue because it has no workaround and is a regression from Drupal 7.

Cause a significant admin- or developer-facing bug with no workaround.

Steps to reproduce

Scenario A (when core/includes/errors.inc is used):

1. Set correct database credentials in settings.php
2. Clear cache: drush cr
3. Set $config['system.logging']['error_level'] = 'hide' in settings.php
4. Set $settings['maintenance_theme'] = 'bartik' in settings.php
5. Set incorrect database credentials in settings.php (for example invalid username)
6. Refresh the page.
7. There is a plain text message: "The website encountered an unexpected error. Please try again later."

Scenario B (when \Drupal\Core\EventSubscriber\FinalExceptionSubscriber is used):

1. Make sure that $settings['hash_salt'] in set in settings.php
2. Clear cache: drush cr
3. Set $config['system.logging']['error_level'] = 'hide' in settings.php
4. Set $settings['maintenance_theme'] = 'bartik' in settings.php
5. Comment out $settings['hash_salt'] in settings file
6. Refresh the page.
7. There is a plain text message: "The website encountered an unexpected error. Please try again later."

Proposed resolution

Adds a way to render a template when in a fatal error context first by trying to get the maintenance theme in settings and then by the slower extension discovery if the that fails. Finally it falls back to a WSOD like fatal message.

Scenario A is addressed by calling the new static method in errors.inc.
Scenario B is addressed by calling the new static method in FinalExceptionSubscriber.

These scenarios are addressed in a new browser test.

Remaining tasks

• Manually test the merge request
• Review the merge request

User interface changes

Fatal errors will be attempted to be rendered using the maintenance theme "offline" template. This would cause previously displaying a WSOD to potentially show a themed page instead.

API changes

• New public method Drupal\Core\Utility\Error::renderFatalError

Data model changes

N/A

Release notes snippet

This is a patch (bugfix) for a regression due to incomplete porting of functionality from Drupal 7 to Drupal 8 (and now Drupal 9). Drupal 7 allowed for the implementation of maintenance-page--offline.tpl.php, a template that to be shown when the site was offline and unable to connect to the database. The porting of this functionality to Drupal 8 and 9 was incomplete, and the equivalent Twig template, maintenance-page--ofline.html.twig, was not picked up, resulting in a generic, unstyled exception page (i.e. a WSOD) with a poor user experience. This but has now been fixed, and site themers can implement maintenance-page--ofline.html.twig on Drupal 8 and 9 sites.

Who this affects

This bugfix affects Drupal theme developers. Theme developers will now be able to create a template page to be displayed when Drupal is unable to reach the database, providing an improved user experience.

How to Implement

1. Copy core/modules/system/templates/maintenance-page.html.twig to the theme to be used when your site is offline.
2. (Optional) Edit the template to provide the HTML you would like visitors to see when the site is offline
3. Edit settings.php, uncomment the line $settings['maintenance_theme'] = 'bartik';, and change the value from bartik to the machine name of the theme you chose in step one above.
4. Clear your registry

How to test the template

After performing the steps above, the way to test that the template is working is to force a fatal error on your site. Warning: it is strongly advised to not test this on a production server. Fatal errors can be forced as follows:

1. Set $config['system.logging']['error_level'] = 'hide'; in settings.php
2. Set incorrect database credentials in settings.php (for example invalid username)
3. Refresh the page
4. Confirm that the template has been picked up

In some situations, users granted the 'edit any content' and/or 'delete any content' permission(s) are not able to view the nodes they can edit or delete. This is most apparent when considering unpublished nodes.

This could be fixed by implying this permission for any user granted the 'edit any' or 'delete any' permission, but a better, more secure solution is the addition of a new 'view any content' permission.

A seven-line patch is attached which provides this functionality, please consider for inclusion in future releases.

Problem/Motivation

Drupal's ESLint configuration, which contrib projects are also encouraged to use, uses the valid-jsdoc rule, which has been deprecated.

The ESLint team recommends using eslint-plugin-jsdoc instead.

Proposed resolution

Stop using the valid-jsdoc rule in Drupal's ESLint configuration. Begin using eslint-plugin-jsdoc instead. For now, configure eslint-plugin-jsdoc similarly to how the valid-jsdoc is configured now, to minimize rework. In the future, consider using more features from eslint-plugin-jsdoc, as it is quite a bit more powerful than the valid-jsdoc rule.

Remaining tasks

User interface changes

API changes

Data model changes

Now that we have hook_mode_access_records_alter(), the 'priority' element in http://api.drupal.org/api/function/hook_node_access_records/7 is just a dangerous remnant of the old API.

Best to remove it entirely and force developers to use the alter hook.

In Drupal 7, it was possible to override breadcrumb by a contextual filter. That feature is missing in Drupal 8. Maybe in Drupal 9 too, but I am yet to try Drupal 9.

Not sure any resolution happened already on it. I did not get any result so far.

It would be good if we get that feature back.

node_tag_new() currently does a merge query on every authenticated page view, to update the {history} table.

afaik history is used for only three purposes:

1. To determine if a node is 'new' for that user or not - whether they ever visited it.

2. To determine if a node has new comments since the last time the user visited it.

3. To determine if the node was updated since the last time the user visited it.

It seems like we could check the node updated and last comment timestamp times, then compare them to the history table, then only do an insert, if one of those three conditions is met - and possibly also every few hours regardless of how many times they've visited the node. This would remove the insert on any repeat page views, and it's not likely to have any real noticeable cost when the value actually needs to be updated. This would be a similar approach to that taken for updating user_access().

The new standard in Drupal core is to avoid using field set if there is only one present or when it is the main interaction. Here the same applies because, there are vertical tabs but the actual Identification fieldset holds no value.

http://api.drupal.org/api/function/node_access_write_grants says

Modules which utilize node_access can use this function when doing mass updates due to widespread permission changes.

So, apparently, node_access_write_grants() may be called by contrib modules, right?

However, if grants are collected by node_access_acquire_grants() (for example from node_access_rebuild()), then node_access_acquire_grants() calls node_access_write_grants() only for the grants with the highest priority. No other grants are written.

This means, modules that call node_access_write_grants() directly, may write grants that would not be written during a node_access_rebuild(), and we get an inconsistent {node_access} table.

Do we have a problem here, or what am I missing?

Problem/Motivation

Docs in CronInterface say:

   * Do not call this function from a test. Use $this->cronRun() instead.

First, this is incomplete -- what is $this representing here? There is no cronRun() method on the interface.

It what is meant is \Drupal\Tests\Traits\Core\CronRunTrait -- that's the only place in core I can find a function with this name. The full name should be given in the docs.

Second, this is partially incorrect, or possibly predates the existence of Kernel tests, because the code of cronRun() is this:

    $this->drupalGet('cron/' . \Drupal::state()->get('system.cron_key'));

Unit and Kernel tests can't do browser requests with drupalGet().

So the docs are misleading, and should say that the function should be used in *browser* tests.

Third, I'm not clear why cron should be run by making a browser request, rather than through the API. That should be explained too.

Steps to reproduce

Proposed resolution

Remaining tasks

- Determine if last change was correct (Adding full stop (.) to end of comment lines)
- Review

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

See #3351494: Skip Drupal\Tests\media\FunctionalJavascript\MediaSourceFileTest we need to fix the test before it can be re-enabled.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

if (theme_get_setting('features.node_user_picture')) {
      // To change user picture settings (e.g. image style), edit the 'compact'
      // view mode on the User entity. Note that the 'compact' view mode might
      // not be configured, so remember to always check the theme setting first.
      $variables['author_picture'] = user_view($node->getOwner(), 'compact');
    }

The compact view mode is defined by standard profile, but node.module hardcodes it.

There are two problems with this.

a) Extra fields are enabled by default on additional view modes, unlike normal fields. See #2410043: Newsletter node: garbage output in view.

b) If the compact view display doesn't exist, it falls back to the default view mode, which could possibly show all kinds of fields.

We're trying to work around that in simplenews by disabling our extra field by default but still wanted it to be shown by default for the default view mode. But now we're running into the b) in tests.

Proposed resolution

Not sure, the whole concept seems rather flawed, this should all be based on configurable formatters.

As a quickfix, maybe it should at least check if the display (as in, the view mode is enabled and configured *somehow*) actually exists before trying to display it.

Remaining tasks

User interface changes

API changes

Data model changes