Problem/Motivation

Right now, when you complete a Drupal 8 migration, AFAICS in all cases, you get your node/comment titles moved over, but the bodies display as blank:

The data for the fields is in the database, but getting stripped out on the front end.

According to the migrate team, this happens when filter formats not recognized by Drupal 8; they get migrated as filter_null, a filter that simply returns an empty string. However, to an "end user" it just appears that migrations don't work, even for very simple core cases where no fancy non-core input formats were used.

Major/Migrate critical because this represents a pretty significant usability hurdle, and harms user confidence in the system early on.

Proposed resolution

Instead, map mismatched filter formats to fallback_format (defaults to plain text).

The one possible reason not to do this is PHP code filter, where you could inadvertently expose database credentials that would now be exposed in plain text. However, we could probably deal with this case specially. (For example, explicitly setting that one to filter_null to indicate it needs attention.)

Remaining tasks

• Write a patch + tests
• Review it
• Commit it!

User interface changes

By default, migrations will now display at least something for body field content for nodes and comments. (As well as other rich text fields.)

API changes

?

Data model changes

N/A?

Release notes snippet

Migrations now default to the fallback filter format, fixing a problem where rich text fields were not displaying post-migration.

Problem/Motivation

Contrib/custom database drivers are not in the Drupal\Core\Database namespace, and in this case Log::findCaller will not report the caller correctly, but just the first function/method coming after the first call to the database connection, or worse after a vendor namespaced method if the driver implements methods there.

Incurred into this while experimenting a db driver https://github.com/mondrake/drudbal in conjuction with #2605284: Testing framework does not work with contributed database drivers, and getting failure for the LoggingTest.

See the trace below: in this case the identified 'caller' is always 'query' since it's the first method coming after either not namespaced or not into Drupal\Core\Database namespace.

    [0] => Drupal\Core\Database\Log -> findCaller
    [1] => Drupal\Core\Database\Log -> log
    [2] => Drupal\Core\Database\Statement -> execute
    [3] => Doctrine\DBAL\Statement -> execute
    [4] => Drupal\Driver\Database\dbal\Connection -> query
    [5] =>  -> db_query
    [6] => Drupal\drudbal\Tests\LoggingTest -> testEnableLogging
    [7] => Drupal\simpletest\TestBase -> run
    [8] =>  -> _simpletest_batch_operation
    [9] =>  -> _batch_process
    [10] =>  -> _batch_do
    [11] =>  -> _batch_page
    [12] => Drupal\system\Controller\BatchController -> batchPage
    [13] =>  -> call_user_func_array
    [14] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [15] => Drupal\Core\Render\Renderer -> executeInRenderContext
    [16] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> wrapControllerExecutionInRenderContext
    [17] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [18] =>  -> call_user_func_array
    [19] => Symfony\Component\HttpKernel\HttpKernel -> handleRaw
    [20] => Symfony\Component\HttpKernel\HttpKernel -> handle
    [21] => Drupal\Core\StackMiddleware\Session -> handle
    [22] => Drupal\Core\StackMiddleware\KernelPreHandle -> handle
    [23] => Drupal\page_cache\StackMiddleware\PageCache -> pass
    [24] => Drupal\page_cache\StackMiddleware\PageCache -> handle
    [25] => Drupal\Core\StackMiddleware\ReverseProxyMiddleware -> handle
    [26] => Drupal\Core\StackMiddleware\NegotiationMiddleware -> handle
    [27] => Stack\StackedHttpKernel -> handle
    [28] => Drupal\Core\DrupalKernel -> handle

Proposed resolution

I think we can safely assume in D8 any logged query will always pass by the Connection object. Get its class name, and drop any stack entry with classes that are not the same as the connection class, drop any entry of the connection class, and then process the remaining stack trace as before.

I think we can safely assume in D8 any logged query will always pass through methods in the namespace of the Connection object.

• Get the connection class namespace,
• Drop any stack entry with methods from classes that are not within that namespace,
• Drop any stack entry with methods from classes that are within that namespace,
• then process the remaining stack trace as before.

This will get to:

    [0] =>  -> db_query
    [1] => Drupal\drudbal\Tests\LoggingTest -> testEnableLogging
    [2] => Drupal\simpletest\TestBase -> run
    [3] =>  -> _simpletest_batch_operation
    [4] =>  -> _batch_process
    [5] =>  -> _batch_do
    [6] =>  -> _batch_page
    [7] => Drupal\system\Controller\BatchController -> batchPage
    [8] =>  -> call_user_func_array
    [9] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [10] => Drupal\Core\Render\Renderer -> executeInRenderContext
    [11] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> wrapControllerExecutionInRenderContext
    [12] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
    [13] =>  -> call_user_func_array
    [14] => Symfony\Component\HttpKernel\HttpKernel -> handleRaw
    [15] => Symfony\Component\HttpKernel\HttpKernel -> handle
    [16] => Drupal\Core\StackMiddleware\Session -> handle
    [17] => Drupal\Core\StackMiddleware\KernelPreHandle -> handle
    [18] => Drupal\page_cache\StackMiddleware\PageCache -> pass
    [19] => Drupal\page_cache\StackMiddleware\PageCache -> handle
    [20] => Drupal\Core\StackMiddleware\ReverseProxyMiddleware -> handle
    [21] => Drupal\Core\StackMiddleware\NegotiationMiddleware -> handle
    [22] => Stack\StackedHttpKernel -> handle
    [23] => Drupal\Core\DrupalKernel -> handle

Remaining tasks

Review patch.

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

I noticed while working on a contrib module that it would be good, if it would be possible to fetch the count of open sessions for a single user.

The module creates locks for content, so only a single user can edit it. The idea here now is that when user logs out it should remove open locks. As a user can log in to multiple browser and can have multiple sessions, it needs to make sure that this is the last open session.

As a workaround in content_lock following is used:

  // Only do the database check if the original drupal session manager is used.
  // Otherwise its not sure if sessions table has correct data. As it would be
  // a common practice to extend the Class, instanceof is not used here!
  if (get_class(Drupal::service('session_manager')) == \Drupal\Core\Session\SessionManager::class) {
    $query = \Drupal::database()
      ->select('sessions');
    $query->condition('uid', $account->id());
    $query = $query->countQuery();
    $session_count = (int) $query->execute()->fetchField();
  }

See FR #2937733: Remove locks on user log out

Proposed resolution

Add new method for counting the open sessions to SessionManager

Remaining tasks

• Add new method
• Add tests

User interface changes

None

API changes

Add new countSession() method to SessionManager

Data model changes

None

Problem/Motivation

Drupal 8 is running on CKEditor 4.x. CKEditor 5.x has gone stable and looks like it has enhancements to help improve the authoring experience.

CKEditor 5 also no longer relies on inline JavaScript, which requires a more permissive Content Security Policy due to its use in CKEditor 4 (#2789139: [upstream] CSP requires 'unsafe-inline' because of CKEditor 4).

Proposed resolution

General requirement: the high-level existing features documented at https://www.drupal.org/docs/8/core/modules/ckeditor/overview continue to exist. If there are strong reasons to not have those features anymore, it needs sign-off from Drupal product managers. Those are: structured content, clean markup, integrates with filter system, paste from Word/Google Docs, drag-and-drop text editor configuration UI, strong safety guarantees, contrib extensibility.

Remaining tasks

The plan:

1. ✅ Phase 1: Basic PoC
   1. ✅ Add core/modules/ckeditor5.
   2. ✅ Create an @Editor PHP plugin with the ID ckeditor5.
   3. ✅ Create a Drupal.editors JS plugin with the ID ckeditor5.
   4. ✅ Getting CKE5 (CKEditor 5) to load at all on the /node/add/article form.
2. Phase 2: Critical technical aspects. (These should be tackled first since they come with the highest amount of risk and architectural work.)
   1. Ensure filter_html's HTML restrictions are respected inside CKE5 just like in CKE4's Advanced Content Filter (which CKE4 added specifically for Drupal). Why? [Because it] allows Drupal to guarantee CKEditor generates clean markup, and only markup that is allowed by Drupal's filters, which means CKEditor's markup preview matches the output exactly. (I have no concerns about this thanks to CKE5's model).
   2. Related: ensure that arbitrary HTML is not lost — see https://github.com/ckeditor/ckeditor5/issues/592 and comments #49–#51.
   3. CKE4 uses an <iframe>-based text editor in forms. CKE5 no longer has an <iframe> mode. This means that the admin theme's CSS automatically applies. This also means that there's no obvious way to port the ckeditor_stylesheets feature that enabled the default (front end) theme to make CKEditor instances in the back end to generate previews that approximately or even precisely match the front end (the default theme). (See CKEditor iframe css at https://www.drupal.org/docs/8/api/ckeditor-api/overview.)
3. Phase 3: Critical integration aspects
   1. Enable a Drupal + CKE5 ecosystem, just like we have today for Drupal + CKE4: https://www.drupal.org/documentation/modules/ckeditor/contrib. This means we need Drupal modules to be able to add additional CKEditor plugins to be loaded and configured. See CKEditor Plugin plugins at https://www.drupal.org/docs/8/api/ckeditor-api/overview for the current five PHP interfaces that @CKEditorPlugin plugins are able to implement. Also relevant information in #28 (by CKEditor 5 Lead Developer @Reinmar) and #32 (big meeting with Drupal maintainers & CKEditor maintainers).
   2. A CKE5 configuration UI like /admin/config/content/formats/manage/basic_html. Noteworthy: the current UI is even fully keyboard accessible. This is evidently blocked on the previous bullet. Also relevant information in #28 (by CKEditor 5 Lead Developer @Reinmar) and #32 (big meeting with Drupal maintainers & CKEditor maintainers).
   3. Ensure there is a great authoring experience that still results in structured content. For example Drupal stores <img src=… alt=… data-align=… data-caption=…>, but CKE4 renders something very different than just an <img>, thanks to CKEditor Widgets. In the talks that @Reinmar linked in his comments #50 and #51 it's clear that the structured content is not a problem (just a matter of extending the CKE5 model) nor is the different presentation for the content author (just a matter of extending the CKE5 view).
4. Phase 4: Polish
   1. Evaluate all of Drupal core's CKE4 plugins: DrupalLink, DrupalImage and DrupalImageCaption. For all of these, we should ask ourselves whether we truly need Drupal to maintain custom integration code for them. Do some git and issue queue archeology to assess the rationale for each of them. In short, for DrupalLink it was that CKE4's link plugin was overly complex, offering the end user 37 choices whereas just the one would suffice. For DrupalImage: same. For DrupalImageCaption: CKE4 at the time would always store the <figure>…<figcaption>This is the caption.</figcaption></caption> markup, which was unacceptable to Drupal since it violates our structured content principles. CKE5 evidently is doing much better on that front, so perhaps we can now drop that altogether?
   2. Evaluate all Drupal's choice to not use CKE4's dialogs but our own server-side rendered ones to allow Drupal modules to hook_form_alter(). (This is true for the plugins mentioned in the previous bullet.) Perhaps in Drupal 9 we can choose to not offer Drupal-PHP-alterable forms and require developers to customize their CKE5 build?
   3. Ensure Quick Edit integration works (the PoC already contains InlineEditor)
   4. Evaluate all other existing integration tweaks and assess whether we want to continue to have them. For example: CKE4 felt very constrained and annoying out of the box, so we added autogrow support and tweaked that further — CKE 5 already does this out of the box! 🥳
   5. Ensure CKE4 and CKE5 can co-exist — currently having both instantiated on the same page results in errors (because for example Basic HTML uses CKE5 and Full HTML uses CKE4 since only CKE4 allows entering arbitrary HTML)
   6. Ensure CKE5 continues to work well in the Off-Canvas Dialogs; for CKE4 this required a complex CSS reset.
   7. #1890502: WYSIWYG: Add CKEditor module to core landed on February 8, 2013. A few days shy of 6.5 years ago. #2469713: Step 2: Create a JavaScriptTestBase using PhantomJs Driver/Binary landed on March 15, 2016. About 3 years and 3 months ago. This is why D8 + CKE4 barely has JS test coverage. Let's do better for D9 + CKE5.
5. Phase 5: Update Path

While doing this work to bring CKE5 to D9, we should do two things on every step along the way:

1. git and drupal.org issue queue archeology to understand why certain choices were made in the D8 + CKE4 integration. When D9 + CKE5 wants to deviate from those choices, be explicit about this and have comments explaining why choices should be different now. This will help D11 + CKE7 😜
2. Work with the CKE5 team! They're an awesome, responsive bunch that will try their best to help us use their work 🥳 #32 is a good example of this :)

User interface changes

TBD. Current status:

API changes

A migration guide has been provided from migrating from 4.x to 5.x, covering plugins, skins, and APIs:

• https://docs.ckeditor.com/ckeditor5/latest/builds/guides/migrate.html

Data model changes

None.

Problem/Motivation

Menu links in Drupal 7 are translated using i18n_menu submodule of the suite i18n, we need to migrate those respecting the language settings. This should be similar to the D6 version, #2225587: Migrate D6 i18n menu links

The D6 patch included a migration for language content menu settings as well.

Proposed resolution

Use the D6 version as a guide.

Remaining tasks

Do the work

Problem/Motivation

As stated in #3110855: Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami, Bartik/Seven/Claro/Umami will be decoupled from Stable. This includes the two libraries provided by Stable, which extend existing core libraries.

drupal.ajax:
  version: VERSION
  js:
    js/ajax.js: {}

drupal.user:
  version: VERSION
  js:
    js/user.theme.js: {}

libraries-extend:
  core/drupal.ajax:
    - stable/drupal.ajax
  user/drupal.user:
    - stable/drupal.user

stable/drupal.ajax added in #3059847: Move hard coded AJAX progress bar classes to a theme function
stable/drupal.user added in #3061265: Use specific class for password confirm message

Proposed resolution

Make core versions of stable/drupal.ajax and stable/drupal.user.
Configure Bartik/Seven/Claro/Umami to extend core/drupal.ajax and user/drupal.user with these libraries, and override stable/drupal.ajax and stable/drupal.user to false.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

There are different precision limits for fields of the numeric type:
- PostgreSQL has a limit of 1000;
- MySQL has a limit of 65;
- Oracle has a limit of 38.

Still, testSchemaAddFieldDefaultInitial tries to test database for numeric fields with 40 and 65 precision limits.

Problem/Motivation

In #462950: Mitigate the security risks that come from IE, Chrome and other browsers trying to sniff the mime type we added

  # Disable content sniffing, since it's an attack vector.
  Header always set X-Content-Type-Options nosniff

To the .htaccess file. We also have

    // Prevent browsers from sniffing a response and picking a MIME type
    // different from the declared content-type, since that can lead to
    // XSS and other vulnerabilities.
    // https://www.owasp.org/index.php/List_of_useful_HTTP_headers
    $response->headers->set('X-Content-Type-Options', 'nosniff', FALSE);

in \Drupal\Core\EventSubscriber\FinishResponseSubscriber::onRespond().

It needs to be in both places because we want the nosniff header on files not served by Drupal's index.php, for example, images.

However, if I get the home page of my local dev build I see the following headers:

Cache-Control:must-revalidate, no-cache, private
Connection:Keep-Alive
Content-Encoding:gzip
Content-language:en
Content-Length:1619
Content-Type:text/html; charset=UTF-8
Date:Wed, 22 Feb 2017 09:16:54 GMT
Expires:Sun, 19 Nov 1978 05:00:00 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.4.23 (Unix) PHP/7.1.0 LibreSSL/2.2.7
Vary:Accept-Encoding
X-Content-Type-Options:nosniff
X-Content-Type-Options:nosniff
X-Drupal-Cache:MISS
X-Drupal-Cache-Contexts:languages:language_interface route theme url.path url.query_args user.permissions user.roles:authenticated
X-Drupal-Cache-Tags:block_view config:block.block.stark_admin config:block.block.stark_branding config:block.block.stark_local_actions config:block.block.stark_local_tasks config:block.block.stark_login config:block.block.stark_messages config:block.block.stark_page_title config:block.block.stark_tools config:block_list config:system.menu.admin config:system.menu.tools config:system.site config:user.role.anonymous config:user.settings http_response rendered
X-Drupal-Dynamic-Cache:HIT
X-Frame-Options:SAMEORIGIN
X-Generator:Drupal 8 (https://www.drupal.org)
X-Powered-By:PHP/7.1.0
X-UA-Compatible:IE=edge

As you can see the X-Content-Type-Options header is duplicated.

This problem also causes \Drupal\system\Tests\Routing\RouterTest to fail for me locally with:

Fail      Other      RouterTest.php      40 Drupal\system\Tests\Routing\RouterT
    Value 'nosniff,nosniff' is equal to value 'nosniff'.

Which is how I found this problem.

Proposed resolution

I think the we need to fix the .htaccess rule so this does not occur. Because the line in \Drupal\Core\EventSubscriber\FinishResponseSubscriber::onRespond() makes this work for other webservers for every delivered via index.php.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

I recently saw a site (in D7) where the body field was deleted. No log message surfaced. I confirmed this is still an issue in D8. If a user deletes a content type, the action is logged, so it seems to make sense to log field deletion too. There are probably numerous other places where we could add logging too.

Proposed resolution

Log field deletions.

Remaining tasks

User interface changes

API changes

Data model changes

Hello all, it’s time for the weekly migration initiative meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 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 here: https://www.drupal.org/project/drupal/issues/3113541
➤*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? Introduce yourself in this thread.

1️⃣ What do we need to talk about?

2️⃣ Migration translation revisions

3️⃣ getHighestId() should be able to use any integer destination id

4️⃣ Implement Entity::fields() for migration destinations

5️⃣ Create a way to declare a plugin ID defined in a migration yml file as deprecated

6️⃣ Plugin migration_lookup don’t process source when part of plugin sub_process

7️⃣ Migrate d7 menu translation

8️⃣ Optimize migration of specific source IDs for SQL sources

9️⃣ Move actions migrations and tests to system module

🔟 Migrate “findMigrationDependencies” function throws error when “process” param is null (edited) 

1️⃣ :one: Migration of menu links does not set the appropriate bundle

1️⃣ 2️⃣ Fix “MigrateCckField is deprecated in Drupal 8.3.x and will be removed before Drupal 9.0.x. Use \Drupal\migrate_drupal\Annotation\MigrateField instead.” deprecation error

1️⃣ 3️⃣ If no Drupal 8 equivalent filter is found during migration, drop transformation-only filters, so that body fields show up

1️⃣ 4️⃣ Field formatter & widget settings: fall back to default if missing plugin

1️⃣ 5️⃣ Migrate empty, and link field

1️⃣ 6️⃣ Future of Migrate in Drupal 10 and beyond

Participants:

benjifisher, Gábor Hojtsy (he/him), heddn, wimleers (he/him), damienmckenna, hash, Joshua Turton (srjosh), mikelutz, andypost, kevinquillen

Problem/Motivation

DRUPAL_PHP_FUNCTION_PATTERN was deprecated in Drupal 8.8.0. It is a single constant with no remaining uses in core.

Proposed resolution

Remove it from Drupal 9.

Remaining tasks

Patch, test, commit.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

This issue is a follow-up to #3110186: Simplify the wording of messages on the status report about security coverage for the site's installed minor version.

The "Drupal Core Update Status" message on the Status report (/admin/reports/status) has up to two links (the summary line and the text "available updates") to the form at /admin/reports/updates/update. These links are not helpful because Drupal core cannot be updated from that form.

Proposed resolution

Link instead to the list at /admin/reports/updates, the primary tab on the same page as the form.

Remaining tasks

User interface changes

This will change up to two links (target, not text) on the Status report.

API changes

None

Data model changes

None

Release notes snippet

Not needed unless this issue is promoted to Major.

When a configuration entity that acts as a bundle for another entity is first saved, it does not have an "original ID" yet. If that configuration entity is then re-saved during Entity::postSave() or hook_entity_insert(), the site shows a blank screen (WSOD).

This is because ConfigEntityBundleBase::preSave() throws an exception if the entity ID differs from the original ID. Of course this is always the case for new bundle entities, as they have NULL for their original ID. See below for the relevant code:

  public function preSave(EntityStorageInterface $storage) {
    parent::preSave($storage);

    // Only handle renames, not creations.
    if (!$this->isNew() && $this->getOriginalId() !== $this->id()) {
      $bundle_type = $this->getEntityType();
      $bundle_of = $bundle_type->getBundleOf();
      if (!empty($bundle_of)) {
        throw new ConfigNameException("The machine name of the '{$bundle_type->getLabel()}' bundle cannot be changed.");
      }
    }
  }

However, EntityStorageBase::doPostSave has a fix for this, but it's being called too late:

  protected function doPostSave(EntityInterface $entity, $update) {
    $this->resetCache(array($entity->id()));

    // The entity is no longer new.
    $entity->enforceIsNew(FALSE);

    // Allow code to run after saving.
    $entity->postSave($this, $update);
    $this->invokeHook($update ? 'update' : 'insert', $entity);

    // After saving, this is now the "original entity", and subsequent saves
    // will be updates instead of inserts, and updates must always be able to
    // correctly identify the original entity.
    $entity->setOriginalId($entity->id());

    unset($entity->original);
  }

Proposed resolution:

• Move the relevant piece of code above the postSave and invokeHook for new entities and leave it below the hooks for updated entities.
• Alternatively, do the above in a brand new ConfigEntityStorageBase class override of ::postSave().

Example use case:
Config entities can have plugin collections by implementing EntityWithPluginCollectionInterface. After saving, one could let other modules try to install "default" plugins on the config entity. Doing so would require a re-save of the config entity, leading to the exception thrown.

Problem/Motivation

It seems like core/themes/bartik/templates/node.html.twig is referencing a Claro template instead of a Bartik library.

Proposed resolution

Reference a Bartik template instead of Claro.

Remaining tasks

Problem/Motivation

In #2487588: Move CMI import/export directory "staging" to "sync", as it is confused with staging environments the config.storage.staging service was deprecated and replaced with config.storage.sync, but some contrib still refers to the old service name.

Proposed resolution

Fully deprecate the config.storage.staging service. The final removal will have to wait until Drupal 10.

Remaining tasks

Patch, test, commit.

User interface changes

None

API changes

Using the config.storage.staging service will report a deprecation warning.

Data model changes

None

Release notes snippet

Problem/Motivation

There are four deprecated services in core.services.yml scheduled for removal in Drupal 9.

Proposed resolution

Remove the services.

Remaining tasks

Patch, test, commit.

User interface changes

None

API changes

Deprecated services will no longer be available.

Data model changes

None

Release notes snippet

Problem/Motivation

In #3107113: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9 the general direction of raising MySQL requirements to 5.7 and MariaDB requirements to 10.2 was agreed on.

Proposed resolution

Raise version requirements.

It was discussed that this may require resolving #2985788: Add a separate MariaDB driver first, but that does not seem to be the case.

Remaining tasks

Raise version requirements.
Update documentation.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Raised the minimum MySQL version to 5.7 and MariaDB version to 10.2 in Drupal 9.

Problem/Motivation

Discovered at #3111929-31: If no recommended update is found, Update Status recommends the latest release, even if it is unsupported ... the patch that was already RTBC would have broken this block of code from update.compare.inc:

    // First, if this is the existing release, check a few conditions.
    if ($project_data['existing_version'] === $version) {
      if (isset($release['terms']['Release type']) &&
          in_array('Insecure', $release['terms']['Release type'])) {
        $project_data['status'] = UpdateManagerInterface::NOT_SECURE;
      }
      elseif ($release['status'] == 'unpublished') {
        $project_data['status'] = UpdateManagerInterface::REVOKED;
        if (empty($project_data['extra'])) {
          $project_data['extra'] = [];
        }
        $project_data['extra'][] = [
          'class' => ['release-revoked'],
          'label' => t('Release revoked'),
          'data' => t('Your currently installed release has been revoked, and is no longer available for download. Disabling everything included in this release or upgrading is strongly recommended!'),
        ];
      }
      elseif (isset($release['terms']['Release type']) &&
              in_array('Unsupported', $release['terms']['Release type'])) {
        $project_data['status'] = UpdateManagerInterface::NOT_SUPPORTED;
        if (empty($project_data['extra'])) {
          $project_data['extra'] = [];
        }
        $project_data['extra'][] = [
          'class' => ['release-not-supported'],
          'label' => t('Release not supported'),
          'data' => t('Your currently installed release is now unsupported, and is no longer available for download. Disabling everything included in this release or upgrading is strongly recommended!'),
        ];
      }
    }

% grep -ri revoke core/modules/update/tests is empty. We have no test coverage of the above code block.

Proposed resolution

Add tests.

Remaining tasks

1. Add tests:
   • NOT_SECURE See #11 and #16
   • REVOKED patch #4
   • NOT_SUPPORTED patch #10
2. Review.
3. RTBC.
4. Commit.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Hello,

in the Seven theme my browser has sometimes performance problems to display the permissions form at admin/people/permissions because the form gets bigger and bigger due to ~100 modules. The modules are all needed :-/

Perhaps there is a way to improve permission display/handling

Here are my thoughts about:

• display in a first step only the permission category (e.g. paragraph permission) as a collapsed container. if the user clicks on the container title, load the requested permissions dynamically via ajax
• Make the form searchable and filterable. There the "module filter" module could be a role model

Problem/Motivation

Drupal 8.8.0 introduced native support for Composer directly in Drupal core. With the introduction of Composer also came the new top-level composer directory, which contains components that are not part of the drupal/core subtree split.

The following Composer-related components exist:

• Generator: Modifies the metapackages when composer.lock is updated.
• Metapackage: Contains exported dependency version constraints, e.g. drupal/core-recommended.
• Plugin: Contains Composer plugins, e.g. drupal/core-composer-scaffold.
• Template: Contains template projects used to create new Drupal sites, e.g. drupal/legacy-project.

These new components should each be considered for mention in the Drupal 8 backwards compatibility and internal API policy (backend) documentation page, so that this policy can better inform backporting decisions as changes are made to these new components.

Generator

The generators cannot be used or extended from a Drupal site. Their only function to to run during composer update operations to keep the metapackages in sync with Drupal's composer.lock file. Everything in the Generator directory should therefore be considered @internal.

Metapackage

The Metapackages only contain composer.json files. Each metapackage creates a subtree split with tagged versions that match the versions of drupal/core. No backwards-compatible-breaking change should be introduced in a minor update of a metapackage. Since the metapackages are generated from the composer.lock file, maintaining compatibility in the composer.lock file will also maintain compatibility in the metapackages. Therefore, no specific b/c policy documentation change is needed for the metapackages.

Plugins

The core Drupal Composer plugin classes are not intended to be called or used directly. All of the Composer plugins should therefore be treated as @internal. API changes that break compatibility with older versions of the plugin should therefore be permissible, provided that the behavior and data structures of the plugin remain compatible.

Note, however, that special care must be taken for plugins that run update hooks. It is possible that Composer may load some parts of a plugin before the update operation. If the plugin itself is updated, then the post-update hook and post-install hook will be called using the new version of the plugin. This can cause failures if classes loaded earlier (from the earlier version of the plugin) are incompatible.

For a fix for one example of this, see https://github.com/drupal-composer/drupal-scaffold/pull/82

Templates

The template projects are used to create new Drupal sites, and are also used to generate the downloadable tarballs on drupal.org. Everything in the templates directory should therefore be subject to the backwards compatibility policy.

Proposed resolution

• Add tests to confirm that Composer plugins do not change in ways that will cause upgrade problems. See #3104922: Guard against changes to Scaffold Plugin that might cause upgrade problems and #3104985: Increase scope of Composer plugin update tests to cover other plugins
• Update Drupal 8 backwards compatibility and internal API policy (backend) with new policies:
• Add a new heading Composer plugins under the heading @internal
• Add a new section on Command line tools and scripts
• Add a new section on Configuration elements
• Add @internal markers to all Composer plugin classes explicitly marking them all internal.

The new headings should appear just before the existing section Minor releases vs. patch releases.

Proposed text for Composer plugins:

#Composer Plugins

Composer plugins in the Drupal repository are not included in Drupal download archives, but are instead packages separately. Subclassing code from Composer plugins is not supported. All classes and methods in Composer plugins are considered internal, and should explicitly marked as such for the avoidance of doubt. In the context of a Composer plugin, @internal means that the class or method is internal to that plugin only, and should not be used from other Composer plugins or from any other part Drupal core outside of that plugin. Commands provided by Composer plugins must follow the rules for command line tools and scripts.

Proposed text for Commandline tools:

The implementation for all command line tools and scripts packaged in Drupal are considered to be @internal. However, the parameters and options accepted by these tools are themselves considered to be a public API. Changes to parameters and options must follow the rules for backwards compatibility.

Proposed text for Configuration elements:

Configuration elements that Drupal sites and modules must provide in order to work correctly are also considered to be part of the API, and must remain compatible from one release of Drupal to another. Configuration elements that are to be removed or changed must also follow the rules for backwards compatibility.

#Composer Scaffold Configuration

Drupal sites that follow the Recommended project or Legacy project templates for Composer-managed sites may contain scaffold configuration elements in their top-level composer.json file. This configuration include specifications for file mappings, the location of the Drupal web root, and other settings. See the documentation on Using Drupal's Composer Scaffold for details on the available settings.

#Project Message Configuration

The Project Message plugin allows project templates to include follow-on instructions for sites created from the template. See the Project Message README for details.

#Vendor Hardening Configuration

The Vendor Hardening plugin allows Composer-managed sites to provide lists of directories to remove. See the Vendor Hardening README for details.

No part of any of the configuration enumerated above will be changed or removed in a breaking way.

Remaining tasks

Refine the proposed policy as needed and reach agreement on the policy. Update the Drupal 8 backwards compatibility and internal API policy (backend) documentation page with the approved text.