Problem/Motivation

I am observing the following behavior when content editing and viewing the latest version of translated moderated content. Users with identical permissions, with the exception of "Translate Entity Type" permissions, will observe different latest versions of moderation translation content.

Note: Entity Type in 'Translate Entity Type' refers to the bundle, e.g. Translate Article, Translate Basic Page.

Steps to Reproduce

Consider the following steps to reproduce:

On a standard install, Drupal 8.8.2, Apache/2.4.18, PHP 7.2.23 with content moderation 8.8.2, content translation 8.8.2, workflows 8.8.2, and paragraphs demo 8.x-1.8 enabled, CREATE a new instance of a node in default language (EN) and publish immediately. Translate this node and save translations both in DRAFT state.

• Navigate to the node revisions tab.
• Observe the only revision is the Published English Node (Current Revision)
• Edit one of the draft translations and save as draft
• Navigate to the node revisions tab. Expect to see the translated draft revision in the list. Observe only the Published English Node (Current Revision) revision
• Edit the original published node and save as a draft revision.
• Navigate to the node revisions tab. Expect to see the draft revision in the list. Observe the new draft revision is first and the Published English Node (Current Revision) revision is second.
• Edit one of the draft translations again and safe as draft, again.
• Navigate to the node revisions tab. Expect to see the translated draft revision in the list. Observe only the english draft revision and the Published English Node (Current Revision) revision

As a authenticated user WITH‘View any unpublished content’, ‘View the latest version’, ‘Entity Type : View revisions’, ‘View all revisions’ AND WITHOUT: "Translate Entity Type" permission
- Prior to creating a draft revision of the English published node
- Navigating to the latest version of a draft translation, observe 403
- After creating a draft revision of the English published node
- Navigating to the latest version of. A draft translation, the English latest version (draft) content was displayed

As an administrator (WITH"Translate Entity Type" permission)
- Prior to creating a draft revision of the English published node
- Navigating to the latest version of a draft translation, observed latest draft translation
- After creating a draft revision of the English published node
- Navigating to the latest version of a draft translation, observed latest draft translation.

As an authenticated user (WITH"Translate Entity Type" permission)
- Prior to creating a draft revision of the English published node
- Navigating to the latest version of a draft translation, observed latest draft translation
- After creating a draft revision of the English published node
- Navigating to the latest version of a draft translation, observed latest draft translation.

Alternatively, CREATE a new instance of a node in default language (EN) and save as DRAFT, translate this node and save translations both in DRAFT state.

- Observe no ‘Lastest Version’ tab exists
- Edit the English node and save as Published
- Edit a translation and save as draft, again. Observe a Latest Version is created

As a authenticated user WITH‘View any unpublished content’, ‘View the latest version’, "Entity Type : View revisions", ‘View all revisions’ AND WITHOUT: "Translate Entity Type" permission
- Navigating to the latest version of the draft translation, observe English latest revision

As an administrator (WITH"Translate Entity Type" permissions) OR
As an authenticated user (WITH"Translate Entity Type" permissions)
- Navigating to the latest version of the draft translation, latest draft translation.

Attachments Overview

• entityrepository_getActiveMultiple
• As an authenticated user without Translate Entity Type permissions, on line 167 we can see that $langcode is "de", as expected. However the $entity returned shows that the active/default language of the node is the original language. This is unexpected.

• latestRevisionCheck_loadEntity.png
• As an authenticated user without Translate Entity Type permissions, on line 167 we can see that active langcode of the returned $entity on line 92 is set to the default language. This is unexpected.

• content_translation_permissions.png
• Content Translation permissions overview. We can see that Translate Entity Type permissions dont include any additional help text/description of what the permission allows

Proposed resolution

I think there are a couple topics included in this issue that need to be addressed:

• Draft translation revisions aren’t created and logged if the original language content was published upon creation
• Permissions to view translated draft revisions/latest versions aren’t clear
• Should "Translate Entity Type" permissions be required to view latest version of draft translated content? When this permission is granted to an authenticated user, the user cannot actually translate content (assuming they don't have Create permissions). https://www.drupal.org/project/drupal/issues/2972308#comment-12622344 describes the permission as 'Allowing access to the Translation overview page'.

Remaining tasks

• Review steps to reproduce.
• Identify any related core issues.
• Investigate code, refactor, patch

User interface changes

Unknown

API changes

Unknown

Data model changes

Unknown

Problem

• WSOD. No error. Nothing.

Cause

Symfony\Component\HttpKernel\Kernel.php:

    public function init()
    {
        if ($this->debug) {
            ini_set('display_errors', 1);
            error_reporting(-1);

            DebugClassLoader::enable();
            ErrorHandler::register($this->errorReportingLevel);
            if ('cli' !== php_sapi_name()) {
                ExceptionHandler::register();
            }
        } else {
            ini_set('display_errors', 0);
        }
    }

Details

• index.php calls
  

  $kernel = new DrupalKernel('prod', FALSE);
  

• The second argument is $debug, tacked onto $this->debug by the Kernel's constructor.
• The rest is visible in the pasted snippet above.

Problem/Motivation

1. Create a content type with a Datetime field
2. Create some sample data with the content type
3. Create a simple view that has one exposed filter for selecting the Date
4. The exposed filter will force you on the 'is equal to' operator to make an exact match on specific datetime fields prior to listing

Cases:
1. Site allows users to create specific meeting times but the client wants search by month or day
2. Views does not allow the user to select the granularity of the search against the Datetime field, you can select the between operator, however if you have separate start/end dates it becomes more complicated since you would have to have the operator work between 4 specific dates... ugh.

Proposed resolution

Add simple form element to date exposed filter to allow the user to select the granularity of their date input

Remaining tasks

1. Land #2648950: [PP-3] Use form element of type date instead textfield when selecting a date in an exposed filter which is itself blocked on these 2:
   • #2625136: Fix label visibility and add wrapper container for exposed numeric/date filters with multiple form elements
   • #2419131: [PP-1] #states attribute does not work on #type datetime
2. More robust tests (see #57, #61.
3. If underlying date field is NOT a datetime field, but instead just a date field, then don't present granularity options for hours/min/second (from #61). Fixed in #79.
4. Sort out timezone bugs from #66.
5. Update summary with screenshots of the current UI, and flesh out "User interface changes" section in more detail.
6. Decide if we want granularity to work on timestamp fields, too. If so, implement the required changes to core/modules/views/src/Plugin/views/filter/Date.php.

User interface changes

Add a new form element to the views exposed filter

API changes

Data model changes

Original report by generalconsensus

The menu_link_content entity has only one bundle in drupal core (with the same name as the entity).

During the development cycle before Drupal 8 stable there was an implementation for bundles with this entity but it ended up having one single bundle just like the user entity.

So the idea is that menu_link_content shouldn't be different than user at having a single bundle to play nice with field_ui and also be a good example for other single bundle entities. In the current situation we kind of half-care for contrib modules that might want to implement bundles since they can add the bundle key themselves but also force them to override the entity class to get somehow override the preCreate() method on the current class entity.

The 'Menu link bundles per menus' feature has been introduced with this issue: https://www.drupal.org/project/drupal/issues/1966298

So each menu link should have as bundle the menu name and not the value 'menu_link_content'.

Consecutively, the menu links migration script for D7->D8 should be updated accordingly.

After updading a Drupal site from 8.6.16 to 8.7.1 (PostgreSQL 9.6.13 , Nginx) I get this error in almost every operation (creating a view , installing a module, importing feeds, ....) with diferent plugins

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "{whatever}" plugin does not exist.
Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan,[...]
in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 de /"
"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I use the drupal-project composer template so my update process was:

composer update --with-dependencies webflo/drupal-core-require-dev drupal/* "symfony/*" -d /<path/to/site> --no-interaction ;
cd /<path/to/site>
drush updb
drush cron
drush cr

It was not successfull, so I do this:

rm -rf vendor/*
composer update

and run again previous commands which It worked.

I though that I could be a problem with PHP version so I update from PHP 7.0 to PHP 7.3, but the error still remains.
I also thought that it could be related with a feeds module installation so delete all feeds content, feeds types, etc .. and unistall and reinstall the module several times (also run drush devel-entity-updates because drupal status report warned of a feeds field that needed to be deleted)

After see that the problem was related with multiples plugins I start looking for a more generic issue (config?, permissions?, ...) but I don't find cause/solution.

EDIT 1

Looking for a stack trace I try using drupal console:

drupal site:mode dev -v

and get this:

In DiscoveryTrait.php line 53:

  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                                                                                                                                               
  The "system.performance" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, language_reference, language, map  
  , binary, timestamp, list, datetime_iso8601, uri, integer, duration_iso8601, email, field_item:comment, field_item:datetime, field_item:daterange, field_item:file_uri, field_item:file, field_item:font  
  awesome_icon, field_item:image, field_item:link, field_item:list_integer, field_item:list_float, field_item:list_string, field_item:path, field_item:telephone, field_item:text, field_item:text_long, f  
  ield_item:text_with_summary, field_item:time_range, field_item:time, field_item:webform, field_item:email, field_item:uri, field_item:entity_reference, field_item:uuid, field_item:timestamp, field_ite  
  m:string_long, field_item:language, field_item:password, field_item:changed, field_item:float, field_item:decimal, field_item:map, field_item:boolean, field_item:integer, field_item:created, field_ite  
  m:string, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment, entity:comment:comment_forum, entity:comment_type, en  
  tity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter  
  _format, entity:image_style, entity:imce_profile, entity:language_content_settings, entity:configurable_language, entity:media_type, entity:media, entity:media:audio, entity:media:file, entity:media:i  
  mage, entity:media:remote_video, entity:media:video, entity:node_type, entity:node,[...], entity:node:page, entity:node:position, entity:rdf_mapping, entity:responsive_image_style, entity:rest_resource_config, entity:rules_reaction_rule, entity:rules_component, entity:s  
  earch_page, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:badge_type, entity:taxonom  
  y_term:categories, entity:taxonomy_term:forums, entity:taxonomy_term:materials, entity:taxonomy_term:nivel, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user, entity:use  
  r_role, entity:webform_options, entity:webform, entity:webform_submission, [..], entity:menu_link_content, entity:pathauto_pattern, entity  
  :view, entity:base_field_override, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity:entity_form_display, entity:date_format, entity_reference

Exception trace:
 () at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53
 Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php:25
 Drupal\Core\Plugin\DefaultPluginManager->getDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/DataDefinition.php:195
 Drupal\Core\TypedData\DataDefinition->getClass() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:86
 Drupal\Core\TypedData\TypedDataManager->createInstance() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:103
 Drupal\Core\TypedData\TypedDataManager->create() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/TypedConfigManager.php:394
 Drupal\Core\Config\TypedConfigManager->createFromNameAndData() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:134
 Drupal\Core\Config\StorableConfigBase->getSchemaWrapper() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:179
 Drupal\Core\Config\StorableConfigBase->castValue() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/Config.php:212
 Drupal\Core\Config\Config->save() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:150
 Drupal\Console\Command\Site\ModeCommand->overrideConfigurations() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:87
 Drupal\Console\Command\Site\ModeCommand->execute() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:987
 Symfony\Component\Console\Application->doRunCommand() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /home/"<user>"/www/"<site>"/vendor/drupal/console-core/src/Application.php:184

EDIT 2

looking at the database I found two tables from feeds module (supposed to be uninstalled)

feeds_feed feeds_subscription

running drupal console commnand drupal debug:module feeds appears as the only module uninstalled with a schema version defined

ID     Name   Package  version      schema version  status      origin
...
feeds  Feeds  Feeds  8.x-3.0-alpha5    8001         Uninstalled no core
...

EDIT 3

After enable debugging (https://drupal.stackexchange.com/questions/127182/how-do-i-enable-develo...)

I got new clues about the error ( trying to create a view) but my lack of drupal core knowledge stops me from understanding where final cause is:

</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;views.view.*&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, [...], entity:entity_form_display, entity:date_format, entity_reference in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;views.view.*&#039;) (Line: 195)
Drupal\Core\TypedData\DataDefinition-&gt;getClass() (Line: 86)
Drupal\Core\TypedData\TypedDataManager-&gt;createInstance(&#039;views.view.*&#039;, Array) (Line: 103)
Drupal\Core\TypedData\TypedDataManager-&gt;create(Object, Array) (Line: 394)
Drupal\Core\Config\TypedConfigManager-&gt;createFromNameAndData(&#039;views.view.test2&#039;, Array) (Line: 134)
Drupal\Core\Config\StorableConfigBase-&gt;getSchemaWrapper() (Line: 179)
Drupal\Core\Config\StorableConfigBase-&gt;castValue(&#039;uuid&#039;, &#039;c2f6326b-a77f-4f1e-9698-cb96154252cb&#039;) (Line: 212)
Drupal\Core\Config\Config-&gt;save() (Line: 284)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;doSave(&#039;test2&#039;, Object) (Line: 449)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 993)
Drupal\views_ui\ViewUI-&gt;save() (Line: 191)
Drupal\views_ui\ViewAddForm-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;view_add_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

_color_unpack() does not remove leading '#' character from the $hex param causing PHP notice:

PHP7.4:

Passing invalid characters to base_convert(), bindec(), octdec() and hexdec() will now generate a deprecation notice. The result will still be computed as if the invalid characters did not exist. Leading and trailing whitespace, as well as prefixes of type 0x (depending on base) continue to be allowed.

See https://www.php.net/manual/en/migration74.deprecated.php#migration74.dep...

Problem/Motivation

Link fields and menu links are output in JSON:API in the following format:

"field_link": [
  {
    "uri": "internal:/",
    "title": "Home",
    "options": [
    ]
  },
  {
    "uri": "entity:node/5",
    "title": "News Center",
    "options": [
    ]
  }
]

"link": {
  "uri": "entity:node/5",
  "title": "",
  "options": [   
  ]
},

This isn't very useful for anything consuming the API because it needs to process these links. In most cases the data can't be fetched because it's unknown what node type is being referenced, and so which endpoint to query is unknown. If this was known, then it would require a lot of unnecessary requests to get the links from various bundle endpoints.

Proposed resolution

Add a computed url property at \Drupal\link\Plugin\Field\FieldType\LinkItem::propertyDefinitions()

Remaining tasks

Write code

User interface changes

None

API changes

An additional property is added to link objects

Data model changes

None

Release notes snippet

tbd

Summary

The node_access system is a somewhat obscure, yet powerful access control API. However, it is severely inhibited for a number of reasons:

1. It is not widely understood
2. It is hard to understand because of poor terminology and conflicting use of terminology
3. It is limited the the Node entity type

The proposal is to implement a new entity-type agnostic access control API that will sit alongside existing systems (not replace permissions/roles, or node_access for BC reasons). We are now ideally positioned to finally implement a new system because of Drupal 8's release cycle and its much better understood and coherent entity system. That is, entities are finally first-class citizens.

Please contribute to technical proposal for a generic entity grants system in Drupal 8 Core

We want to reach a consensus about the architecture and terminology used in the new generic entity access system before we start with the implementation. Therefore, the audience of the proposal is for technical maintainers of Drupal core and people following the drupal.org issue.
https://docs.google.com/document/d/1jIWKVoYbdVeEg-Kz_5yvlMvi7PycoHZWg4xX...

Related issues

#1810320: Remove EntityTranslationControllerInterface::getAccess() once have entity access is postponed on this issue.

Problem/Motivation

composer/Plugin/Scaffold/ManageGitIgnore.php generates a .gitignore file which ignores files in the whole project. In my case I had a .eslintrc.json in a custom theme which was ignored. By adding a leading slash, this should be fixed

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hi all! This is the start of the weekly API-first initiative meeting. The conversation will take place across various threads.:zero: let us know who's here (please include your d.o username so I can give you d.o credit for attending)

:one: Please post any topics you'd like to discuss here and then I'll start a thread for them

:two: Announcements? (edited) 

:three: JSON:API 8.x-1.x EOL

:four: multiple mutations in a single request cc: @pwolanin (he/him)

:five: who's speaking at DrupalConNA?

:six: @jibran had asked for someone to review this before the meeting https://drupal.slack.com/archives/C5A70F7D1/p1583231110126700 (edited) 

Problem/Motivation

Drupal 8.8.x is not passing tests on PHP 7.4. PHP 7.4 released on November 28, 2019, a week before Drupal 8.8.0.

Proposed resolution

Fix code to not trigger errors in PHP 7.4 maintaining the same behaviour as PHP 7.0 to 7.3.

There is no release of easyrdf/easyrdf that supports PHP 7.4 in order to work around this we've done #3090017: Isolate test dependency on easyrdf/easyrdf to a single trait and then in this patch we provide a test only version of \EasyRdf_ParsedUri that is PHP 7.4 compatible. This code is only loaded and available at test time. Hopefully a release of easyrdf will happen sometime but it's not as important because it is now a test only dependency in Drupal 9.

Follow-up issues

• #3110815: \Drupal\hal\Normalizer\EntityReferenceItemNormalizer::normalize() tries to normalize entities that don't exist
• #3110839: Use of \Drupal\Core\Database\Install\Tasks::getFormOptions() in \Drupal\migrate_drupal_ui\Form\CredentialForm::buildForm() results in confusing description for prefix form element
• #3110972: Update easyrdf library or change \Drupal\Tests\rdf\Traits\RdfParsingTrait to not rely on it

Done:

• #3090145: Ensure that mixing array and Attribute objects in theme rendering is managed properly
• #3104420: PHP 7.4 Deprecated curly brace syntax for accessing array elements
• #3104421: PHP 7.4 deprecated reverse order of glue and pieces in implode
• #3095895: FieldTypePluginManager::getPluginClass() should throw an exception when called for a field type that doesn't exist
• #2830631: Remove code that tries to use _raw_variables for route argument resolution as it does not work
• #3089764: Updating translations does not clear the JS asset cache so new translations are not loaded
• Get a new release of composer/composer including https://github.com/composer/composer/pull/8296, see comment #33. #3075785: Update composer/composer to ^1.9.1
• Update to release 1.6.8 of mikey179/vfsstream, see comment #31. mikey179/vfsstream 2.0.x-dev requires PHP 7.2, so D8.8. cannot upgrade to it. #3091225: Require-dev mikey179/vfsstream ^1.6.8 in order to support PHP 7.4
• Get a new release of symfony/validator, including https://github.com/symfony/symfony/pull/34097:#3092112: Update symfony packages to 3.4.33 before 8.8.x beta
• #3089530: Tests of copied Doctrine code are not testing what we want them to test
• New release of Typo3's phar stream wrapper and of PEAR's Archive Tar #3088853: Require typo3/phar-stream-wrapper ^3.1.3 and pear/archive_tar ^1.4.8 in order to support PHP 7.4
• PHPunit 6 does not run on PHP 7.4 so we need to upgrade it - #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5 - unfortunately PHP 7.0 (still supported in 8.8.0) does not run PHPUnit 7.
• egulias/email-validator - access array on null. Solvable updating to latest version. #3039611: Update core PHP dependencies for 8.8.x
• mikey179/vfsstream - use of deprecated curly brackets for array access. Solvable updating to latest version.
  #3039611: Update core PHP dependencies for 8.8.x

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal [insert version] is now compatible with PHP 7.4 and testing on PHP 7.4 is part of the regular automated test suite.

Problem/Motivation

update_fix_compatibility() is just remove modules and themes that don't exist.

Steps to replicate

1. delete a module from the modules folder
2. run updates
3. restore the module and try to enable it

You can't enable nor uninstall. But it does point to the process of disabling the module leaving things in a corrupt state.

Proposed resolution

Add an requirement error when the module list or theme list is wrong. We can't fix things really because at least in the case of modules we have no idea what to do. With themes potentially we could force an uninstall with no code present but then again we're making changes without really knowing what the user wants.

Looks something like:

Steps to test:

• Install standard
• Enable stark theme
• Remove dblog, page_cache and stark
• Set update free access in settings.php
• Visit update.php

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up of #3089900: Drupal 8.8/8.9/9.0 update test coverage

It's very painful to write update tests for modules that aren't enabled in the filled dump by default.

Proposed resolution

That issue on purpose kept the filled dump as similar as possible but as discussed in Slack, we should enable new stable modules there as well and also add some content (medias, layouts, drafts..?)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

This issue is about ensuring the overall framework for updating Drupal 8 databases to Drupal 9 is in good shape.

(not in precedence order, just for easier reference).

1. Policy

(policy) Figure out how to handle database updates eligible for backport from 9.x to 8.x #3108658: [policy] Handling update path divergence between 8.9.x and 9.x

2. Test coverage

(done) Add new database dumps so that updates added from 8.8.0 are tested against an 8.8.0 database dump #3089900: Drupal 8.8/8.9/9.0 update test coverage.

(done) Refactor tests of the update system itself to not rely on version-specific database dumps, and put them into their own namespace and base class so that they are easy to identify separate from tests for individual updates #3102059: Make tests of the update system use UpdatePathTestTrait instead of UpdatePathTestBase and #3106395: Move tests that test the update system to UpdateSystem namespace.

(nice to have) Add expanded database dump which includes newer Drupal 8 stable modules (such as layouts, media) #3095333: Extend filled database dump with new stable modules and content for them.

3. Improvements to update system API and error messages around removed updates

Clearer messages and stronger warnings for hook_update_last_removed() #3098475: Add more strict checking of hook_update_last_removed() and better explanation

(needs issue) Test whether Drush respects hook_update_last_removed() once the above fix is in and, if needed, fix upstream in Drush.

Ensure that hook_post_updates can be removed cleanly #3066801: Add hook_removed_post_updates() (blocks post update removal).

Ensure that sites cannot be updated from Drupal 8 to Drupal 9 if they have any modules installed that aren't compatible with Drupal 9 #3108159: Database updates should not be allowed if any installed modules are not compatible with Drupal core / #2917600: update_fix_compatibility() puts sites into unrecoverable state.

4. Removal of older updates

Remove hook_update_N() added prior to 8.8.0 #3087644: Remove Drupal 8 updates up to and including 88**#3108416: Remove workspace_update_8803().

Remove hook_post_updates added prior to 8.8.0 #3106666: [pp-1] Remove post updates added prior to 8.8.0.

5. Upgrade guide documentation

DONE: Ensure that recommendations around updating from 8.7 or earlier, including help for sites having issues updating to 8.8 or earlier, are documented in the Drupal 9 upgrade guide, marketing materials, and any relevant third-party tooling. See #3108618: Document how can people update to Drupal 9 from various Drupal 8 versions

Related issues: (policy) Figure out an ongoing policy for update removals #2942096: [policy, no patch] Remove old update hooks prior to each major version (Drupal 10 and later).

Problem/Motivation

Must-haves prior to tagging Drupal 9.0.0-beta1

8.9.x and 9.0.x will enter beta at the same time and will have the same beta stability requirements as a normal minor release. Additionally:

1. There must be no outstanding issues to update PHP and JavaScript dependencies (i.e. they should be on the latest release of the latest branch we intend to ship with). Also unused dependencies should be removed prior to beta.
   • PHP: All must have parts done for Drupal 9: #3009213: [META] Update / reconsider PHP dependencies for Drupal 9
   • JavaScript and CSS: #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1
     Remaining:
     • #2550717: [JS] Replace jQuery.cookie with JS-cookie and provide a BC layer
     • #2821525: Update normalize.css to the most recent version

    

2. ALL BETA SCOPE DONE: All deprecated code usages and backwards compatibility layers must be removed and deprecations properly documented - we can't remove deprecated code that is called by Drupal core. (see the @deprecated tag). This includes deprecated JavaScript libraries etc.
   See:
   • #2716163: [META] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 9 branch
   • Done: #2959269: [meta] Core should not trigger deprecated code except in tests and during updates

    

3. Any critical Drupal 8 upgrade path bugsmust be triaged / resolved in 8.x so that sites are not stranded on pre-8.9.x versions due to known core bugs.
   Remaining:
   • #2917600: update_fix_compatibility() puts sites into unrecoverable state
   • #3056543: taxonomy_post_update_make_taxonomy_term_revisionable() fails when terms have no default translation
   • #3052318: Update from 8.6.15 to 8.7 fails due to corrupt "menu_link_content" entity data

    

4. Also in 9.0.x, updates from versions prior to Drupal 8.8.x must be removed and hook_update_last_removed() implementations added: #3108254: [META] Drupal 8-9 upgrade path clean-up This is to minimise the surface area for 8-9 upgrade path bugs.
   Remaining:
   • #3066801: Add hook_removed_post_updates()
   • #3106666: [pp-1] Remove post updates added prior to 8.8.0
   • (nice to have for beta) #3095333: Extend filled database dump with new stable modules and content for them

    

5. There must be a Drupal 9-specific version of the Stable theme, so that contributed and custom themes are able to port to it. #3050374: Create Drupal 9 stable theme
    
6. NO OUTSTANDING ISSUES: Any known 9.0.x-only security or data integrity criticals must be resolved.
    
7. ALL BETA SCOPE DONE: Simpletest module must be either successfully moved to contrib, or retained in core and undeprecated #3110983: Verify that simpletest tests can be run in contrib, or add simpletest back to core. (done)

Should-haves

These issues are not hard blockers to releasing Drupal 9, but there would be significant negative consequences of them not being completed in time for Drupal 9's release. Outstanding should-haves may cause 9.0.0 to be deferred from the June release window to the August window.

1. NO OUTSTANDING ISSUES: Any critical API changes, API additions, or data model changes should be completed, as these changes will no longer be allowed during the beta.
    

2. All Drupal 6 and Drupal 7 -> Drupal 8/9 core content migrations should be stable. In practice this mostly means multilingual migrations #2208401: [META] Stabilise Migrate Drupal Multilingual module , and #2746541: Migrate D6 and D7 node revision translations to D8 is the final beta-blocking issue for those. If we don't do this, we can't expect people to migrate from Drupal 6 and Drupal 7.

There may be minor configuration translation migrations or contrib -> core migrations still outstanding which would be great to clean up but should not actually block release.
 

3. ALL BETA SCOPE DONE: We should have adopted a policy for PHP 7.x version support, as this needs to be announced as far as possible before the LTS and 9.0.0 release so hosts have time to upgrade. #2917655: [policy] Decide whether and how to drop PHP 7.3 support in Drupal 9 during its lifetime.
    
4. We should have MySQL, PostgreSQL and SQLite requirements implemented.
   • Policies:
     • #3107113: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9
     • #3106077: [policy] Decide on PostgreSQL 9.x/10.x support status
     • #3107155: Raise SQLite version requirement to 3.26 in Drupal 9 (was the policy)
   • Implementation:
     • #3109534: Raise the minimum MySQL version to 5.7 and MariaDB version to 10.2 in Drupal 9
     • #2846994: Increase minimum version requirement for Postgres to 9.6.x
     • #3107155: Raise SQLite version requirement to 3.26 in Drupal 9

    

5. ALL BETA SCOPE DONE: We should provide accurate update recommendations (9.0, not a non-existent minor version of Drupal 8) on the Status Report (/admin/reports/status). #2991207: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases#3111929: If no recommended update is found, Update Status recommends the latest release, even if it is unsupported.
    
6. ALL BETA SCOPE DONE: We should have a proper policy for CSS and markup changes.
    
7. ALL BETA SCOPE DONE: Drupal.org should be able to fully handle contributed projects that are compatible with both 8.x and 9.x and not assume core compatibility based on version/branch name: #3054433: Support multiple core branch functionality for contributed projects on drupal.org This spans multiple projects and areas such as project listing, composer façade, update.xml from drupal.org and localization files.

   &snbp;

8. We should have dropped support for Node.js 8 since it's EOL. #3107918: [PP-1] Drop support for Node.js 8

Nice to haves

1. #3111409: [META] Add new default Olivero frontend theme to Drupal 9 core only if done enough in time, otherwise moves to Drupal 9.1.0 earliest.

Must have and should have issues (and their children) have been tagged "Drupal 9.0.0-beta1 requirement" on a best effort basis for an easier cut-through view of all issues regardless of their hierarchy or project affected.

Problem/Motivation

In #3087644: Remove Drupal 8 updates up to and including 88**, we noticed that using that hook_update_last_removed() is not actually that strictly enforced (it requires to have an update function), doesn't actually show what's going on and just displays a warning message, together with a success message:

Proposed resolution

Add something to system_requirements() that checks for that explicitly, for all modules implementing such a hook. Display an error with clear info and don't allow users to continue in that case.

Remaining tasks

User interface changes

(copied from #40)

Before:

you only get a warning that doesn't prevent you from doing the update and that warning only shows up on a later step when the updates are listed:

After:

Update.php stops on the requirements page and displays an error that doesn't allow you to continue:

Contrib:

API changes

Data model changes

Release notes snippet

Problem/Motivation

We worked around conflict between dependency versions on Drupal and postcss-header library by not loading postcss-header using the index file. This can be removed now that postcss-header has released a version that supports Babel 7.

Proposed resolution

Update to the latest version of postcss-header and remove the workaround.

Remaining tasks

User interface changes

I am observing a strange behavior using the built-in "archive" view in Views to create a block for posts by month.

With the same setting
SORT CRITERIA:
Content: Authored on (asc)

I would expect with the same direction of sort for both, that the display would be the same for both.

But the "page" view shows the months descending order (latest first) but the "block" view shows months ascending order (earliest first).

A second strange behavior is that changing the setting from ascending (asc) to descending (desc) doesn't change the results.

To reproduce you will need some articles published, and then simply enable the archive view and see the preview below, or visit the /archive page and place the block in the sidebar.

Screenshots attached.

The related issue has a comment saying that perhaps the sort criteria is being set in the wrong place. If so, where is the right place? I am following the label of "Sort Criteria."

Also it's possible I'm not understanding properly what this page / block is supposed to do. I thought from the name & description it's supposed to be like the archive block on a Wordpress blog. In that case, please help me understand.

Thanks,
Leek

Notice: Undefined index: status in _update_project_status_sort() (line 634 of core/modules/update/update.module).
_update_project_status_sort(Array, Array)
uasort(Array, '_update_project_status_sort') (Line: 55)
update_requirements('runtime') (Line: 186)
update_page_top(Array) (Line: 336)
Drupal\Core\Render\MainContent\HtmlRenderer->buildPageTopAndBottom(Array) (Line: 135)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->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: 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)