Problem/Motivation

Follow up to #3129043: Move core database drivers to modules of their own and to #3230714-11: ConnectionUnitTest should be skipped for any database not psql or mysql:

Once #3129043: Move core database drivers to modules of their own is complete, it would be good to split the Database tests in 'core' ones and 'driver specific' ones, with the 'driver specifc' ones running dependent on the db driver in use by the SUT.

Proposed resolution

At the moment we have 4 possible solutions:

1: From the MR. Split Database tests in 'core' ones and 'driver specific' ones for the kerneltests in Drupal\KernelTests\Core\Database only. For most contrib database drivers this is enough, only for the one for MongoDB this is not the case.

2: No patch/MR. Move the core/phpunit.xml.dist file to the root of the database driver module and let every module with a database driver have its own phpunit.xml.dist. Use that file for the testbot and in that file the tests that must be skipped for the module can be added to the file. The Drupal testbot must be changed for this to work. The advantage is that all tests can be overridden.

3: From the patch (comment #18): Change the class Drupal\Core\Test\TestDiscovery, so that the method
getTestClasses() only returns the tests that need to be run. It skips the tests from the modules with a database driver that is not fromthe active database connection. The script run-tests.sh will need to be changed a bit and the option "--list" will need the "--dburl" to have it return the correct list of test classes.

4: From the patch (coomment #19): The method Drupal\KernelTests\KernelTestBase::setUp() now has code that skips tests that are from module with a database driver that is not from the active database connection and it skips tests that have been overridden by the module with the databse driver that is used in the active database connection. It only works for kerneltests, but the same solution can also be used for browsertests.

This issue implements option #1.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #2537732: PluginFormInterface must have access to the complete $form_state (introduce SubFormState for embedded forms), the SubFormState class was introduced for BlockPlugin's build/validate/submit callbacks, and additionally $form['settings'] (the sub form array) started getting passed to the build/validate callbacks, but not to the submit callback!

That means that $form is different in these two callbacks for everyone writing a BlockPlugin:

($form is $form['settings'] here)
public function blockValidate($form, FormStateInterface $form_state) {

($form is the complete/parent form here)
public function blockSubmit($form, FormStateInterface $form_state) {

Proposed resolution

We should fix this so that the $form argument passed to these callbacks is consistent.

Remaining tasks

Review the patch.

User interface changes

None.

API changes

The sub form is now passed to BlockPlugin's submitForm method, instead of the complete/parent form.

Data model changes

None.

Problem/Motivation

Follow up of #3256642: Autoload classes of database drivers modules' dependencies.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Likely regression from #2778083: Default value for Date-Only fields is broken when UTC date is different than user current date

Given a date field, with the 'Date only' setting and 'Current date' as the default, the current date can be wrong for the configured time zone. It works as expected if the field is set to 'Date and time'

Screenshot of two date fields, one with Date only and one with Date and time, using Current date as the default, with timezone set to Los Angeles:

Same node, with the timezone set to UTC:

Steps to reproduce

1. Install Drupal
2. Add a Date field to the article content type, with 'Date only', and the default set to 'Current date'
3. Add another date field with 'Date and time' and the default set to 'Current date'
4. Set the site timezone to one that is ahead of UTC, where the current day is different (e.g. 7pm in LA)
5. Create a node, see that the date is different between the fields
6. Set the timezone to UTC
7. See that the date is correct

It seems like this was caused by the changes in #2830094: Deprecate and remove usages of datetime_date_default_time()., specifically the changes in DateTimeWidgetBase.php around line 39.

When that code originally used datetime_date_default_time(), $date was first set to 12:00:00 and then the timezone was change. After the code was changed to not use datetime_date_default_time(), now the timezone is set first and then the time is set to 12:00:00. This doesn't produce the same result; it will now give the UTC date instead of the local time zone date.

Proposed resolution

Call $this->createDefaultValue() before calling $date->setTimezone() in line 39 of DateTimeWidgetBase.php

Remaining tasks

User interface changes

API changes

Data model changes

The database schema for {user} does not require that email addresses are unique, and user_save() does not prevent saving multiple users with the same address. However, when user with a non-unique address submits the account form on user/123/edit, the form validation fails with the following error message:

The e-mail address c960657@example.com is already taken.

The error occurs, even if the registered mail address has not been changed, i.e. this prevents the user from changing other parts of the profile.

I know that other parts of Drupal does not properly handle duplicate email addresses, e.g. the lost password feature, but we should either fix those parts or enforce the uniqueness in the database schema and/or in user_save().

Problem/Motivation

Annotation for \Drupal\entity_test\Entity\EntityTestRev has two view_builder entries, with identical values.

Proposed resolution

Remove one of the lines

Remaining tasks

Delete a line.

User interface changes

Nil

API changes

Nil

Data model changes

Nil

Release notes snippet

Nil

This meeting takes place every Friday at 14:00 UTC (currently 7:00am PT, 10:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

ping:
@Gábor Hojtsy (he/him), @worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Antoniya, @Ravi, @shaal, @ckrina, @simohell

Go to the issue for the next meeting to add/remove yourself to/from the list.

Recording of this week's meeting: TODO

Rough transcript of this week's meeting: Drupal Usability Meeting - 2022-10-07.txt

We discussed the following issue:

• #3314350: [meta] Usability improvements for Project Browser

NR and RTBC issues marked Needs usability review.

Problem/Motivation

At the moment there is no generic revision UI, this means that every module with revisionable entities will need to create their own UI similar to the Node revision overview page (node/{node_id}/revisions. This means quite a bit of boilerplate code, especially for modules with multiply revisionable entities.

Steps to reproduce

Without the patch and contrib modules, there's no Revisions UI for entities other than nodes. This issue can be manually tested on Media and Blocks with some contrib modules that rely on some version of this patch.
Here's a custom entity that I tested with the same results. The .module is based on working code from a site that's using the patch, but it's also originally based on the work in media_revisions_ui.

* On a standard install, 9.5.0-dev

Node

* Add content of type Basic /node/add/page (revisions are enabled by default)
* Go to the Revisions UI, via the tab at the top /node/1/revisions

* Edit node a few times to get more revisions /node/1/edit
* Review the Revisions UI /node/1/revisions

Media

* Enable media module
* Add media of type Image /media/add/image (revisions are enabled by default)
* Edit Image, note there's no tab for Revisions UI /media/1/edit

* With the patch in #228, install and enable contrib media_revisions_ui dev-3.x
* Edit Image, note that there's a Revisions tab now. Edit a few times to get multiple revisions /media/1/edit
* Go to Revisions UI (tab), compare to Node revisions tab

Blocks

* Edit Basic block custom block type, and enable Create new revision /admin/structure/block/block-content/manage/basic
* Add custom block of type Basic /block/add/basic
* Edit block, note there's no tab for Revisions UI /block/1

* With the patch in #228, install and enable contrib block_content_revision_ui 2.127.2
* Edit block, note that there's a Revisions tab now. Edit a few times to get multiple revisions /block/1
* Go to Revisions UI (tab), compare to Node revisions tab

** Note the contrib block_content_revision_ui module doesn't use the admin theme by default

Revert using the Revisions UI

* Click Revert back to the first revision
/node/1/revisions/1/revert
/media/1/revisions/1/revert
/block/1/revision/1/revert (revision, singular)
* Get a confirmation page; Click Revert button
* Go back to the Revisions UI; now the current revision has been set back to the original (first) revision

Proposed resolution

Create a route provider for generating revision list, revision revert form, revision delete form based derived from link templates.

Remaining tasks

Direction/decisions

Items needing discussion

• ✅Whether to continue blocking this issue on #3043321: Use generic access API for node and media revision UI, an access checker will be added and immediately deprecated.
• ❌Whether Node should use this in this issue.
• ✅Whether we should generate local tasks, or if entities should add their own.
• Revert terminology updated to be agnostic of target revision' time.
• Should we adopt Version terminology (per patch)?

This list is a summary of some comments/discussion, re: the unresolved Revert terminology/adopt version term questions. Overall, most comments are in favor of the UI being addressed in another ticket, pending UX feedback. As far as code changes, there doesn't seem to be a clear consensus, which is summarized pretty well here:

on the one hand UI issues shouldn't block this, but on the other it's turning one-off UI terminology into an API with the same language

• should be questions for the UX team, #108& #109
• UI change is a separate UX issue if we want to change it again, #109
• Code change: I'm not sure there's a compelling reason to change it at all and it might make things less clear, #109
• We're creating a bunch of classes with both Revert and Version, arriving at a decision earlier would be preferable to changing symbols in the future, #113
• on the one hand UI issues shouldn't block this, but on the other it's turning one-off UI terminology into an API with the same language, so making the problem worse, #210
• 'revert' has bothered me in this UI for years, since what this actually does is 'clone and publish' the revision it refers to, #210.
• I've always read 'revert' in this context as reverting the *state of the entity* to that contained in the revision, #211
• hope we can divert that discussion to a separate issue, #212
• #2899719: Revision/version language on revision listing page is misleading with content moderation enabled, #218

Blockers

• #2927077: $entity->toUrl('revision-*') should fill revision parameter on all applicable routes. per 45, 59, others.
• #3043321: Use generic access API for node and media revision UI per 67.

Patch to date for this issue relies on patches in these.

User interface changes

New opt-in UI based on features already established by Node.

API changes

None

Data model changes

None.

Release notes snippet

Problem/Motivation

Embedding a video as media remote_video entity does not allow Fullscreen for the video. On the inner frame it says allowfullscreen=""
To allow fullscreen, it would have to say
allowfullscreen="allowfullscreen"
I cannot find how one would influence this, this must have to do with the Oembed implementation.

Filed as a bug report since Fullscreen is a basic feature IMHO.

Proposed resolution

For the maximum cross-browser compatibility copy youtube and add allowfullscreen allow="fullscreen" to the iframe tag.

This aligns with the iframe documentation - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe

Remaining tasks

User interface changes

remote video embeds now are allowed to go fullscreen.

API changes

None

Data model changes

None

Release notes snippet

N/a

When a custom block is rendered in a TWIG template, the quote is displayed incorrectly. Here is an extract of the code of my template, it is the home page of Drupal :

  {% if rows %}
    <div class="view-content">
      {{ rows }}
    </div>
  {% elseif empty %}
    <div class="block">
      {% if not logged_in  %}
        {{ drupal_entity('block_content', '11') }}
      {% else %}
        {{ drupal_entity('block_content', '12') }}
      {% endif %}
    </div> 
  {% endif %}

I put screenshots with rendering in Drupal blocks and directly in a Twig template with the code above. There is a significant shift in the quote to the left.

Problem/Motivation

From #2350939: Implement a generic revision UI, mentioned in summary/96/103/108/109/110.

To reduce duplicate code and maintenance burden, we should aim to rework Node's revision UI so it extends generic entity UI implemented in #2350939: Implement a generic revision UI

A generic revision UI is being implemented in #2350939: Implement a generic revision UI, this issue exists to deprecate/remove Node's revision UI in favor of the generic solution.

Proposed resolution

Remaining tasks

• Replace Node' revision UI code, extending generic revision UI.
• Can we remove Node test coverage which already exists for generic revision UI?
• Specific enhancements between generic UI and existing Node UI need to be identified, and add tests for this functionality.

User interface changes

Issue aims to replicate existing interface.

API changes

Class names should be maintained, but extend generic classes.
Format of node render arrays and forms will change.

Data model changes

None?

Release notes snippet

-

I have Drupal 9 with the Olivero theme. I want to disable the display of the "About Text Formats" link. There is no option in the text formats configuration to do this.

How to extract media and internal links from CKEditor 5?

I want to create a page view with a tab, on my nodes. I want this page to display all the media present in the body of the node. How can I do this? It would be something great. I don't want to use fields, but the media used with CKEditor.

I have the same question for internal links. My node, refers to other nodes, in CKEditor. I want to create a view block, which displays the nodes with the same keywords, but it must exclude the links present in the body of the node. It would make CKEditor so much more powerful and so much better integrated with Drupal. How to do this, without creating a reference field?

It's easy to achieve this result using reference fields, but it's unnecessary work. It is necessary to extract this information from the body of the node and CKEditor. It would be logical and natural.

In settings.php, the private file path is documented with "This directory must be absolute, ...". However, an absolute path does not work when drupal runs on a shared host and access to the parent directories is not possible.

Example:
• a shared host with drupal root /var/www/ud17_276/html/drupal
• web server root is /var/www/ud17_276/html
• shared host root is /var/www/ud17_276, i.e., this part is not visible for the space admin, and thus neither for drupal
• in settings.php:
$settings['file_private_path'] = '/var/www/ud17_276/files/drupal-private';

If a drupal user tries to upload a file, by creating a node of a content type having a file field with private storage configured, drupal tries to create the full parent path, /var/www/ud17_276, which obviously will fail. The error message in the log is:

"The upload directory private://2016-09 for the file field field_privimage could not be created or is not accessible. A newly uploaded file could not be saved in this directory as a consequence, and the upload was canceled."

Configuring the shared host's users relative root, like
$settings['file_private_path'] = '/files/drupal-private';
does also not work. The only way this seems to work currently is a relative path:

$settings['file_private_path'] = '../../files/drupal-private';

Hence, either the code documentation in settings.php should be updated to include this case, or the coding has to be changed to be able to deal with shared hosting. (Unfortunately, due to lack of php knowledge, I cannot judge these options.)

Best, Tobias

Problem/Motivation

The web/core/modules/node/src/Plugin/migrate/source/d6/Node.php did not get the constructor updated to use ModuleHandlerInterface instead of ModuleHandler

Steps to reproduce

This is likely triggered by the hook_event_dispatcher module being enabled as well.

Run migration and receive error:
[Exec] TypeError: Drupal\node\Plugin\migrate\source\d6\Node::__construct(): Argument #7 ($module_handler) must be of type Drupal\Core\Extension\ModuleHandler, Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler given, called in /code/web/modules/legacy/shop6_migrate/src/Plugin/migrate/source/ErpCore.php on line 38 in Drupal\node\Plugin\migrate\source\d6\Node->__construct() (line 81 of /code/web/core/modules/node/src/Plugin/migrate/source/d6/Node.php).

Proposed resolution

Update the constructor

Panels are not consistent in Olivero. I have panels on my website with a blue header and a gray header. What is the correct header?

Problem/Motivation

After enabling English (not translatable) in a working site, I get daily a lot of messages: Translation file not found.

Steps to reproduce

• Create a new D9.4.x site and install it with Dutch (or any lanuage).
• No other languages are enabled.
• After setting up the site with some additional modules and using it for some time.
• Enable English as extra language.
• Make sure translate_english is set to false in locale.settings.yml

At every cron run you will now get lots of messages: Translation file not found. And all appears to be for English translations like: Translation file not found: https://ftp.drupal.org/files/translations/all/token/token-8.x-1.9.en.po.
These will appear daily even when the 'Check for updates' setting is: weekly.

Proposed resolution

in install.core.inc, fetch translatable languages only instead of all languages.

Problem/Motivation

The themes #image_formatter and #image_style are both taking the image style name as argument. Then the image style object is loaded in the theme layer, in preprocess. That's a bad design because puts the loading and validating objects logic in the theme layer. Theme layer should not be in business of loading and validating. These are backend operations. The backend should be responsible of loading, validating and preparing the correct image style to be used by the theme.

Proposed resolution

1. Deprecate the usage of #image_style theme variable 'style_name' in favour of a new 'style' that will hold the entire image style object. If the deprecated variable 'style_name' will get a non-empty value, that will take precedence in theme preprocess to assure a full BC.
2. Deprecate the usage of #image_formatter theme variable 'image_style' in favour of a new 'style' that will hold the entire image style object. If the deprecated 'image_style' will get a non-empty value, that will take precedence in preprocess to assure a full BC.
3. Make core use the new variables.
4. In 9.0.x drop the deprecated variables. Open a followup for that.

Remaining tasks

Open a 9.0.x followup for removing deprecated variables.

User interface changes

None.

API changes

• New variable 'style' available to 'image_style' theme.
• New variable 'style' available to 'image_formatter' theme.

Data model changes

None.

Problem/Motivation

#2997123: Cacheability of normalized computed fields' properties is not captured during serialization added the ability for computed field properties to contribute cacheable metadata to the normalization. However, entity reference fields are treated totally different by json:api module, since they must be converted to a "Relationship object" which references a UUID and resource type. As a result, there is no way for computed ER fields to express cache metadata.

Updated: We must also account for cacheability of empty fields.

Steps to reproduce

Create a computed ER field on an entity and observe it cannot vary by cache tags, context or TTL.

Proposed resolution

Use similar logic to the recently-added feature set, but for ER fields. We can use ResourceIdentifier::getDataReferencePropertyName() to be consistent.

Remaining tasks

Extend test coverage.

User interface changes

None.

API changes

None... well, we potentially change the visibility of the helper static method for getting the data reference property.

Data model changes

None.

Release notes snippet

TBD.

Original report

Hi,

I'm having an issue with a computed field (entity reference type) being displayed on JSON:API resources. The problem is that it's always cached, although it should change as I change for ex. categories or tags.

What I want is to have a computed/virtual field with similar articles for given article (depending on common categories and tags). For retrieving similar articles I use module called Similar By Terms => https://www.drupal.org/project/similarterms I want these similar articles to be outputted on JSON:API resources... and it works good, but it's cached all the time.

Here's my code:

function my_module_entity_bundle_field_info_alter(array &$fields, EntityTypeInterface $entityType, string $bundle): void {
  if ($entityType->id() === 'node'&& $bundle === 'article') {
    $fields['field_similar_articles'] = BaseFieldDefinition::create('entity_reference')
      ->setName('field_similar_articles')
      ->setLabel('Similar articles')
      ->setTargetEntityTypeId('node')
      ->setTargetBundle('article')
      ->setComputed(TRUE)
      ->setRevisionable(FALSE)
      ->setTranslatable(FALSE)
      ->setCardinality(FieldStorageDefinitionInterface::CARDINALITY_UNLIMITED)
      ->setClass(SimilarArticlesComputedField::class);
  }
}

class SimilarArticlesComputedField extends EntityReferenceFieldItemList {

  use ComputedItemListTrait;

  protected function computeValue(): void {
    $similarArticles = <array of articles' entities get from the view>

    foreach ($similarArticles as $key => $similarArticle) {
      $this->list[$key] = $this->createItem($key, $similarArticle);
    }
  }

}

As I said, JSON:API resource displays field_similar_articles field correctly, but when I change some article's category or tag then output of this field in JSON:API resource should change as well, but it's not.

Let's say there is Article 1, 2, 3, 4 and 5.

Article 2, 3 and 4 are similar articles to the Article 1 (because they share common tags/categories).

When I go to this resources /jsonapi/node/article/{article-1-uuid} then I can see Article 2, 3 and 4 in section field_similar_articles and also in included section.

So far, so good.

But then, let's say that I delete tags and categories for Article 2 and once again go to the upper mentioned resource... I still can see Article 2, 3 and 4 in section field_similar_articles... but Article 2 should not be there. What's interesting, in the included section Article 2 disappears, which is good.

Could you please tell me what I can do about it ... and will it be possible after applying this patch (I'm using Drupal ver 9.2.10) from this issue?