Problem/Motivation

user_user_role_insert() is a secondary write to config. Basically when you create a role through the API or UI you will always get two actions created. This entangles the role and action configuration entities from an API perspective that is wrong. When you create a role through the API the system should only create a role. At the moment configuration sync only works because we bail if the role is being created as part of a configuration sync. But whether or not it is a config sync seems irrelevant. In fact it feels as though we need different hooks of API and UI based creates.

This is a bug because if an install profile provides both the role and it's related system.action.user_add_role_action.ROLEID the install breaks horribly with the following error:

Drupal\Core\Config\ConfigDuplicateUUIDException: Attempt to save a configuration entity 'user_add_role_action.administrator' with UUID '1b27a4d1-6f94-4c33-9500-a44bd23eeab9' when this entity already exists with UUID 'b69baf55-119d-4066-8d0f-15725863cce1' in Drupal\Core\Config\Entity\ConfigEntityBase->preSave() (line 344 of core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php).

Proposed resolution

tbd. The simplest solution for user_user_role_insert() is just to move this code to the form that creates user roles.

Remaining tasks

User interface changes

API changes

Data model changes

I updated drupal from 7.44 to 7.58.
while clicked one "next" button in /update.php steps , I got this message

PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: DELETE FROM {cache_bootstrap} WHERE (cid = :db_condition_placeholder_0); Array([:db_condition_placeholder_0] => system_list ) at cache_clear_all() (line 173 of /home/data/xxx/drupal-7.58/includes/cache.inc)

By the way, we had 2 apache+drupals deployed in different machine sharing the same code base. But this may not the reason, the other application using the same deployment structure went through a smooth update.

Problem/Motivation

If a config entity is being renamed through \Drupal\Core\Config\ConfigFactoryInterface::rename() then it becomes impossible to load the entity by its uuid through \Drupal\Core\Entity\EntityRepositoryInterface::loadEntityByUuid().

Proposed resolution

When config is saved or deleted we listen to the corresponding events in \Drupal\Core\Config\Entity\Query\QueryFactory and update the config key store for fast lookups so that a config entity could be loaded by its lookup keys.

In order to cover renaming config entities through the config factory we should additionally listen to config renaming events and update the config key store for fast lookups accordingly. Additionally we should remove delete the old values from the config key store for fast lookups.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

CKEditor's default styles and resets are being overridden by off-canvas' CSS. As a result, CKEditor is basically un-usable when rendered inside of the off-canvas dialog.

Currently the selector "#drupal-off-canvas" is a part of almost every selector in off-canvas' CSS, and that makes overriding any off-canvas style really tough. This is because in #2826722: Add a 'fence' around settings tray with aggressive CSS reset. which originally created the CSS reset for the off-canvas dialog this was the only way we could figure out make sure the reset was actually effective against contrib themes that we tested against. See the Specificity Calculator as to why really only an ID can be sure to override selectors using styles in contrib themes.

We also tried #2853222: Explore using an IFrame to sandbox CSS for the Off Canvas tray and other ways #2853208: [META] Determine best method ensure consistent theming of Off Canvas Tray. There is also the general issue #2195695: Admin UIs on the front-end are difficult to theme which I don't think has come up with any good solutions.

Because of backwards compatibility concerns and that none of the other solutions are supported by the browsers we need to support or didn't cause their own problems we probably are stuck with the current method for the reset.

As soon as you start to create/edit entities in the off-canvas dialog you are going to run into this problem like in #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder.

How it looks now:

You can see this locally by following these steps:

1. Apply the provided "layout-builder-debug.patch" patch
2. Install the Standard profile
3. Enable the "Layout Builder Debug" (layout_builder_debug) module
4. Visit /admin/structure/types/manage/article/display-layout/default
5. Click "Add Block"
6. Select "Debug Form Styling" from the block listing
7. See that CKEditor looks funky

Proposed resolution

1. Add :not(.js-off-canvas-ignore), to the end of all selectors used in the off-canvas css library.
2. Document that modules that want a particular element and it's child elements be excluded by the off-canvas css reset should add the class .off-canvas-ignore-parent to the parent element.
3. Via Javascript look for elements with the .off-canvas-ignore-parent class and add the .js-off-canvas-ignore class to it and all it's children.

Step #1 here makes the proposed patch very large but because it is :not selector it not should effect any sites current CSS unless they are already using the .js-off-canvas-ignore class. This seem very very unlikely.

Remaining tasks

Discuss the problem, determine what solution we should use.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Problem/Motivation

During the content translation/moderation integration in 8.5.x, two messages were added as warning messages, but they are actually not *warnings* IMHO.

See the screenshots in #3002571: Multiple warning messages when having untranslatable fields for one of them, when you have untranslatable fields. That's not a bug, not something you need to do anything about, that's just how it is.

The other one is on /translate, if you have pending translation revisions then you get a warning that you're not allowed to delete them:

This is a bit more warning-ish, it's an explanation why you can't delete a translation.

Proposed resolution

I'm not sure. A green/OK message is also strange?

Maybe show some other visual hint that there are fields that can't be changed/translated?

Remaining tasks

User interface changes

API changes

Data model changes

Due to #1497366: Introduce Plugin System to Core successfully commited can we talk about migrating template system into plugins?

Problem/Motivation

In #2303525: Provide link tags to alternate languages (hreflang) in HTML head, when viewing a content entity, we added hreflang alternate links to the HTML head for each translation of that entity. However, alternate links will appear for unpublished translations as well. This behavior hurts SEO, as web crawlers will be made aware of links that cannot actually be viewed.

Proposed resolution

Do not include unpublished translations when providing rel="alternate" hreflang links in the HTML head.

Remaining tasks

- Needs review.

User interface changes

None.

API changes

None.

Problem/Motivation

If Drupal 9 only (or even nearly-only) drops backwards compatibility with Drupal 8, then Drupal 8 modules using the latest 8.x APIs should work with 9.x

However the core key in .info.yml only supports a single version (6.x/7.x/8.x) - anything else just gets rejected.

Proposed resolution

We already supported versioned module dependencies, so could potentially use some of that logic and/or composer's format.

Remaining tasks

Postponed on #2641658: Module version dependency in .info.yml is ineffective for patch releases

User interface changes

API changes

Data model changes

A site's install profile is registered as a module in core.extension config, with a weight of 1000.

AFAICT this is hardcoded in a function in core/lib/Drupal/Core/Extension.

Until this quirk of the profile system is cleaned up, we could add a constant for the value to the relevant class, so it's easier to spot and has documentation.

Currently, a user can be added without an email address (the field is optional). However, as soon as a user receives an email address, the email field becomes required. This leaves things in a sort of halfway state. It seems like one of the following should be true:

1. It is valid for a user to have no email address. If this is the case, then the field should not be required on user edit. (Otherwise you can't return a user to this state after an address has been entered.)
2. A user must have an email address defined. If this is the case, then the field should be required on user add also.

I'm not sure which way is preferred, but it would be great if this experience was consistent.

Updated: Comment #212

Problem/Motivation

Inserting an image in the text editor dialog today allows the user to fiddle with image dimensions. It doesn't even have aspect ratio locking.

It's not great for the authoring experience nor for structured content reasons that users are defining the specific dimensions of every single image they insert. It'd be much better to allow them to choose from image styles — just like we do for image fields.

Proposed resolution

Allow an image style to be selected in the image dialog, which gets stored in a data-image-style attribute, and is handled by a yet-to-be-added imagestyle filter.

Remaining tasks

1. Initial patch: select image style in dialog, inserting that sets a data- attribute, and a filter transforms the end result.
2. Get #1589176-4: Follow-up: Use data-* to store #states api informations— a blocker to this patch — committed.

User interface changes

• The new ability to select an image style.
• A new filter.

API changes

None.

Related Issues

• #1932652: Add image uploading to WYSIWYGs through editor.module
• #1589176-14: Follow-up: Use data-* to store #states api informations
• #2123251: Improve DX of responsive images; convert theme functions to new #type element

Problem/Motivation

When enabled the "Account administration pages" language negotiation lets the user have a configurable language for admin pages. The negotiator determines whether the current page is an admin-page by extracting the path (ignoring any query-arguments) for the current Request and resolving resolving a Route for the path.

This leads to problems for REST resources as they are looked up by format. That is, a rest resource declares which formats it supports, and a request filter (RequestFormatRouteFilter) then ensures that a Request can not be routed to the resource if it requests the wrong format.

Steps to reproduce

1. Enable language, rest, basic_auth
2. Download and enable the monitoring module (or any other module with a rest resource that is only available via json)
3. Request /monitoring-sensor-result?_format=json
4. (verify that a json response is produced)
5. Add an extra language via /admin/config/regional/language
6. Enable the "Account administration pages" language negotiation via /admin/config/regional

/language/detection

7. Edit the current users profile and select a language in the "Administration pages

language" dropdown under the "Language Settings" section

8. Request /monitoring-sensor-result?_format=json

Expected result:
Same output as in step 3

Actual result:
"No route found for the specified format html."

The reason for the this response is that html is the default format used in the absence of af _format query parameter. When the negotiator tries to determine whether we're currently on an admin-page by matching the path with a Route it runs in to the RequestFormatRouteFilter which is unable to find a route for the default format and throws an NotAcceptableHttpException exception.

Proposed resolution

Have LanguageNegotiationUserAdmin preserve the _format query argument when trying to determine whether a path is an admin-path.

I have attached a patch that simply passes the argument along if present. I would have liked to provide a test as well, but figuring out how to set up a test that goes though all the outlined steps proved to be a bit too much to handle with the time I had available for now. Tips on how to set up the test (or an actual test) would be most welcome.

When accessing a CKEditor field using JAWS, the help text is not announced by JAWS.

• Testing was performed using JAWS v18.0.2945.
• This defect exists in Google Chrome v70.0.3538.77 and in IE11.

Steps to reproduce:

1. Add a help text to a formatted text field (CKEditor field).
2. Open JAWS v18.0.2945.
3. Create/Edit a node that has the field.
4. Use the Tab key to navigate to the field.

Expected result: All additional information/cues needed to complete form fields are expected to be announced by JAWS. In this instance, JAWS is expected to fully announce the help text when the field is accessed.

Problem/Motivation

#1748022: Make cache()->get() return a classed CacheItem object will improve the return type from get a lot making it quite a bit easier to work with but handling cache misses in Drupal can be a bit complicated. Returning an object means you have to do some inspection and understand the object and the way caches behave when you you just want the caching system to help you avoid doing some costly action over and over. And lets all admit, if you haven't messed with caches in a while, you probably forget about the intermediate object the first time you prototype your code.

Proposed resolution

I suggest we add a helper that combines get/set into one handy function looking something like this:

$data = $this->cache->remember($cid, $expire, function () {
  return 'My expensive value';
});

or to steal from the core documentation is would replace most uses of this:

$cid = 'mymodule_example:' . \Drupal::languageManager()
  ->getCurrentLanguage()
  ->getId();
$data = NULL;
if ($cache = \Drupal::cache()
  ->get($cid)) {
  $data = $cache->data;
}
else {
  $data = my_module_complicated_calculation();
  \Drupal::cache()
    ->set($cid, $data);
}

with this:

$bin = \Drupal::cache();
$cid = 'mymodule_example:' . \Drupal::languageManager()
  ->getCurrentLanguage()
  ->getId();
$data = $bin->remember($cid, Cache::PERMANENT, function() {
  return my_module_complicated_calculation();
}

This idea is shamelessly stolen from Laravel's cache repository because it simplifies so much logic out of most cache uses.
https://laravel.com/api/5.4/Illuminate/Contracts/Cache/Repository.html#m...

Remaining tasks

Discuss plan and agree if its a good idea
Decide on the interface
Write implementation
CR
Update documentation

User interface changes

n/a

API changes

New API. Provided as new interface for BC but maybe merged into CacheBackendInterface for 9.x?

Data model changes

n/a

Problem

I would export a revision. So i created a new view of type "content revision" with a filter on "revision id".
I acces to this view with the url "revision/%" where % is a vid

And i had this error :

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'npr.title' in 'field list': SELECT nr.vid, nr.nid, npr.title FROM {node_revision} nr WHERE nr.vid IN ( :vids__0 ); Array ( [:vids__0] => 60 ) in Drupal\node\Plugin\views\argument\Vid->titleQuery() (line 76 of core/modules/node/src/Plugin/views/argument/Vid.php).

Proposed resolution

The current line 76 of vid.php is :

<?php
$results = $this->database->query('SELECT nr.vid, nr.nid, npr.title FROM {node_revision} nr WHERE nr.vid IN ( :vids[] )', array(':vids[]' => $this->value))->fetchAllAssoc('vid', PDO::FETCH_ASSOC);
?>

There is no npr table in the WHERE clause

The first thing to do is to add a "\" before PDO::FETCH_ASSOC
The second is to remove the reference to "npr" on the select

Just for testing I replaced the line 76 by this one :

<?php
$results = $this->database->query('SELECT nr.vid, nr.nid, nr.nid as title FROM {node_revision} nr WHERE nr.vid IN ( :vids[] )', array(':vids[]' => $this->value))->fetchAllAssoc('vid', \PDO::FETCH_ASSOC);
?>

And now my export work well. Of course it's not a correct solution. It's just a dirty and quick fix for remove the PHP fatal error.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Usually happens every other Monday at 20:00 CEST / 15:00 ET (for this week).
➤ 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:
`https://www.drupal.org/project/drupal/issues/3007152`
➤*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.

:zero: Who is here today! Comment in the thread below to introduce yourself and tell us what are here for.

:one: Our master issue is at https://www.drupal.org/project/drupal/issues/3007300. Our other issues are children of this one and form this nice tree: https://www.drupal.org/files/issues/2018-10-26/%5BMETA%5D%20Release%20Drupal%209%20in%202020%20%233007300.pdf We identified a lot of things since the last meeting and will delve into specifics in further agenda items. Any major blockers that we forgot?

:two: Migrate! The team has been working hard to close more multilingual blockers. The outstanding question on supporting Drupal 6 to 9 migrations seems to be resolved with building it in Drupal 8 and deprecating it for removal in Drupal 9 (moving to contrib). The Drupal 8 to 8 (AKA 8 - 9 migration path) was also discussed on the core committer meeting two weeks ago. Alex Bronstein was to post an update on the issue but I don't think he did. Is this accurate? Other major outstanding migrate questions?

:three: Contrib versions and core compatibility.

Further topics TBD

Since September in our site some nodes are disappearing. We had 8.5.X but now we have latest core version 8.6.2.
We have multilingual site and there are more than 10 persons adding and editing content and the same time.
Content that have problems: is translatable and working with revision system.

We have seen that node_field_data, node__body and other node field registers are deleted, but they are in revision tables.
No logs and no errors in watchdog, no deleting actions from editors, only disappear "node data" from database but not "node revision data".

What are the steps required to reproduce the bug?

We don't know why this happens and how to reproduce. Things to be in mind:
- Only happens in office hours, maybe problem is related with multiples access and same time.
- Only happens in content with a lot of editions, we have old content types with a lot of nodes with no problems.
- Only happens with translation entity, never happened with source translation.

We use following sql code to get orphans revisions:

SELECT distinct nfr.nid, nfr.langcode, nfr.vid
FROM node_field_data nfd
LEFT JOIN node_field_revision nfr ON nfd.nid = nfr.nid
where nfd.langcode != nfr.langcode
AND nfr.langcode NOT IN (
SELECT nfd2.langcode
FROM node_field_data nfd2
WHERE nfd2.nid = nfd.nid
)
AND nfr.vid = (
SELECT nfr2.vid
FROM node_field_revision nfr2
WHERE nfr2.nid = nfr.nid
AND nfr2.langcode = nfr.langcode
ORDER BY nfr2.vid DESC
LIMIT 0,1
)
ORDER BY nfr.nid DESC;

We have checked crons, code, a lot of process and we didn't get anything.

We have tried changing php max_input_vars to 3000 too but with no luck.

Any ideas?

I do not know when this errors was taken

address: /admin/reports/fields

Notice: Undefined index: image in Drupal\field_ui\FieldStorageConfigListBuilder->buildRow() (line 119 of core/modules/field_ui/src/FieldStorageConfigListBuilder.php).

Full text in file admin.reports.fields.txt

address: /admin/structure/types/manage/news/fields/node.news.field_img/storage

Notice: Undefined index: alt in Drupal\image\Plugin\Field\FieldType\ImageItem->defaultImageForm() (line 437 of core\modules\image\src\Plugin\Field\FieldType\ImageItem.php).
The same with the title, width, height

Full text in file node.news_.field_img.txt

How do I remove these errors?

I just came across a code glitch after upgrading to 8.4.0.

I'm trying to use a view to pull raw data from a query, and iterate through the values in each row. My code has the following call:

$id = $view->field[$field]->getValue($row);

However, on one page, the $row's value for a particular $field happens to be null.

On the 8.3.x version of EntityField , this happened to be OK, but now EntityField::getValue() has a call to getEntityTranslation(NULL):

public function getValue(ResultRow $values, $field = NULL) {
  $entity = $this->getEntity($values);
  
  // Retrieve the translated object.
  $translated_entity = $this->getEntityFieldRenderer()->getEntityTranslation($entity, $values);

  ...

getEntityTranslation($entity) really panics if $entity happens to be NULL, and throws the following error:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\views\Entity\Render\EntityFieldRenderer::getEntityTranslation() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in **my_website_directory**/core/modules/views/src/Plugin/views/field/EntityField.php on line 1056 in Drupal\views\Entity\Render\EntityFieldRenderer->getEntityTranslation() (line 69 of core/modules/views/src/Entity/Render/EntityTranslationRenderTrait.php).
Drupal\views\Entity\Render\EntityFieldRenderer->getEntityTranslation(NULL, Object) (Line: 1056)

I'm not sure if EntityField::getValue should check to see if $entity is NULL before passing it to getEntityTranslation, or if getEntityTranslation itself should be able to handle nulls.

At the moment I've just thrown in a:

          $entity =  $view->field[$field]->getEntity($row);
          if ($entity == NULL) {
            continue;
          }

in before my code... I'm also trying to see if I can implement my code in a different way... Somehow this seems overly complex... Still, a simple "if NULL then stop" might be useful.

Rolling up a patch now...

Problem/Motivation

As part of the Workflow Initiative, we want to improve the path alias system and make it easier to integrate into modern Drupal workflows, like the new Workspaces or Content Moderation modules.

The current system has various deficiencies:
- it uses a custom storage pattern
- the integration with other entity types is done via a custom (computed) field type, which is an endless source of tricky bugs
- path aliases are not revision-aware nor publishable, which means they can not be integrated into the other core workflows

Proposed resolution

Do all the things!

Remaining tasks

Conversion to revisionable entities:
#3006086: update.php should not process path aliases
#2336597: Convert path aliases to full featured entities
#3009014: Convert path alias migrations to create entities
#3007832: Convert custom path alias forms to entity forms
#3011807: Convert the path alias admin overview to a list builder
#2233595: Deprecate the custom path alias storage

To be done after the initial conversion:

#3007669: Add publishing status to path aliases
#3008058: Convert the computed path item field type to a regular entity reference field

User interface changes

Various features that are available for all content entity types will also be enabled for path aliases, like Views integration, etc.

API changes

A new core entity type with a backwards compatibility layer in place until Drupal 9.

Data model changes

Path aliases will be converted to translatable, revisionable and publishable entities.