Problem/Motivation

Split off from #2820364: Entity + Field validation constraints are processed in the incorrect order.

Proposed resolution

Make it required.

Remaining tasks

1. Change the base field definition.
2. Update function that does the same thing. See aggregator_update_8200() for an example. (Via @amateescu in #2820364-29: Entity + Field validation constraints are processed in the incorrect order.

User interface changes

None.

API changes

None.

Data model changes

None.

Entities can provide route parameters for their routes. Parameters you can query by calling $entity->toUrl($link_relation)->getRouteParameters(); Yet, Field UI chooses to ignore those and only hard-codes specific route parameters.

A great example of where it crashes the site is field_ui_entity_operation():

$operations['manage-fields'] = array(
        'title' => t('Manage fields'),
        'weight' => 15,
        'url' => Url::fromRoute("entity.{$bundle_of}.field_ui_fields", array(
          $entity->getEntityTypeId() => $entity->id(),
        )),
      );

This only works if the 'field_ui_base_route' path is something like my_entity/{my_entity}. If it's anything like my_module/{some_context}/my_entity/{my_entity}, it will crash because {some_context} is not being provided.

In order to fix this, we need to make Field UI define link relations and properly name its routes after said link relations. It currently has some routes that do not follow the (albeit undocumented) convention of entity.{entity_type_id}.link_relation_name.

The most recent patch approach does this in a backwards-compatible way.

Problem/Motivation

This issue was originally Comment-specific. But further investigation has revealed that the problem is not specific to comments. It's a general Entity/Field API problem. Entity constraints are validated before field constraints. See #12 and later.

Still, the Comment use case is a useful guide through the discovered problems:

While working on #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, it took me hours to figure out what the minimal set of fields is that one must send for a Comment entity to be successfully created. See #2737719-75: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method.

In doing so, I had to do extensive debugging using Xdebug to figure out the incredibly obtuse error responses, which are categorically HTTP 500 responses instead of 422 responses. And not only that, but the message in each of those responses is absolutely worthless. It doesn't give any indication about what is wrong.

AFAICT key problems are:

1. \Drupal\comment\CommentStatistics::update() depends on entity_type, which is neither required nor validated
2. CommentNameConstraintValidator depends on entity_id and field_name, but runs before either of those can even possibly be validated (entity_id is required, but that's not validated before CommentNameConstraint is validated)
3. Both of these result in failures outside of what the Entity API validation system is designed for, hence resulting in undecipherable errors in REST responses

Proposed resolution

Unknown, see comments.

Remaining tasks

1. Make Comment's entity_type base field is required: #2885809: 'entity_type' base field on Comment is required
2. Make Comment's entity_type base field have a validation constraint, to ensure a valid entity type is set. Test coverage must include a non-existing entity type to ensure good DX.
3. Also ensure that \Drupal\Tests\rest\Functional\EntityResource\Comment\CommentResourceTestBase::testPostDxWithoutCriticalBaseFields() is no longer sending an Accept request header.
4. … more, but yet TBD!

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Hello,

I've got an exception when trying to add a new user via /admin/people/create. I immediately get the following error:

Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "user" entity type did not specify a "register" form class. in Drupal\Core\Entity\EntityTypeManager->getFormObject() (line 184 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).

Drupal\Core\Entity\EntityManager->getFormObject('user', 'register') (Line: 69)
Drupal\Core\Entity\HtmlEntityFormController->getFormObject(Object, 'user.register.default') (Line: 59)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
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: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
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: 666)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

So I stepped into the code with Xdebug and figured out, that when the
hasHandlerClass() method in the EntityType class gets called, the $handlers variable looks like this:

$handlers = [
    '...',
    'form' => [
        'default' => 'Drupal\user\ProfileForm',
        'cancel' => 'Drupal\user\Form\UserCancelForm',
        'register' => null,
        'content_translation_deletion' => '\Drupal\content_translation\Form\ContentTranslationDeleteForm',
    ],
    '...',
];

I don't know why the register form handler ist null. Any suggestions how this can happen?

I am using Drupal 8.5.6 with PHP 7.2.

Thanks in advance!

Convert system functional tests to phpunit

Scope:
#2984185: Convert system functional tests to phpunit for page and pager./Page/DefaultMetatagsTest.php
#2984185: Convert system functional tests to phpunit for page and pager./Pager/PagerTest.php
./Render/HtmlResponseAttachmentsTest.php
./Render/UrlBubbleableMetadataBubblingTest.php
#2983970: Convert system functional tests to phpunit /Routing/DestinationTest.php ./Routing/DestinationTest.php
./Routing/RouterTest.php
./Session/SessionAuthenticationTest.php
./Session/SessionHttpsTest.php
./Session/SessionTest.php
./Session/StackSessionHandlerIntegrationTest.php

Postponed:
./Path/UrlAliasFixtures.php
./Routing/MockAliasManager.php
./Routing/MockRouteProvider.php

Splitting this off from #2982149: Page/Routing/Render/Session: Convert system functional tests to phpunit, that is getting too big. Please credit the people that worked on that.

scope:
./Session/SessionAuthenticationTest.php
./Session/SessionHttpsTest.php
./Session/SessionTest.php
./Session/StackSessionHandlerIntegrationTest.php

Problem/Motivation

As we added ViewMode template suggestions for Nodes here #1503464: Automatically add theme hook suggestion for node view mode and most probably for all entities: #2270883: Automatically add theme hook suggestions for all entity types.
We should also have suggestions for Fields.
Also because you can configure your Field Formatter per Viewmode, I think this is necessary.

Proposed resolution

Add Theme Hook Suggestions for Fields with View Modes

Remaining tasks

Write Patch

I am using Drupal 7.59 and Acquia Dev Desktop 2. When i am enable custom module then i am getting this error.
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'custom_user_reg.cache_block' doesn't exist: TRUNCATE {cache_block} ; Array ( ) in cache_clear_all() (line 173 of D:\Sites\devdesktop\drupal-7.59\includes\cache.inc).

Problem/Motivation

When a bundle or field is created or deleted the list of field storage definitions for a given entity type might change. The storage handler, however, holds a reference to the table mapping which in turn holds a reference to the (previous) field storage definitions in memory. Thus, the old table mapping will be used incorrectly after the creation or deletion.

See #2599228-72: Programmatically created translatable content type returns SQL error on content creation for more information.

Proposed resolution

Properly clear/re-initialize the table mapping at the right places.

See 2599228-72--interdiff-cache-fix.txt from #2599228-72: Programmatically created translatable content type returns SQL error on content creation for a start.

When a dialog is opened with the "modal" option, all other elements on the page are hypothetically disabled. Even though those other elements are masked, you can still scroll-through the modal to the body, which is awkward and not expected behavior. This can lead to the user being confused after closing a modal as the page has scrolled past where they initiated the modal originally.

This patch disables body-level scrolling when a dialog is opened as a modal, which should address this problem.

Hi,

I need some help to characterize this issue, i try to figure out what is going bad in Drupal as our hosting provider OVH doesn't help on site management.
I see this kind of message since last night but people said site crashed in the afternoon.
[Thu Sep 20 02:41:51 2018] [error] [client ****] [host ****] AH10039: FastCGI: server "/homez.105/****/www/docroot/index.php" stderr: PHP message: PDOException: SQLSTATE[HY000] [1203] User **** already has more than 'max_user_connections' active connections in /home/****/www/docroot/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php on line 79 #0 /home/****/www/docroot/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php(149): PDO->__construct('mysql:host=ll21...', '****', '****', Array)
Is it a clue for someone?

Best regards,

Gilles

It would be great if it was possible to configure the translation table for nodes! Especially for multilingual websites with many different use cases it would make it possible to customize and tailor more what information to display there. As example it would be possible to display a column for moderation states of different translations (if that is important for the translation system on the site), or to display different language version of images/files, if that is important for the type of content that should be translated. So to make the content translation tab/table as a view would give more flexibility for multilingual site builders!

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

[guessing path module?]

1. If people upload files, I would like them to be private, so that those files can only be seen by other local users who log in.
2. If a picture is uploaded to a person's page, I would hope that that picture would be visible on the collected "People" page.

It seems that as both of those involve an "upload", I can't treat them differently, but hopefully I'm missing something - any hints?

In Configuration/Media/File system, I have "Default download method = Private local files served by Drupal." which I think is necessary for 1).

In Configuration/People/Account settings, I have "Picture directory: pictures""Subdirectory in the file upload directory where pictures will be stored", so there doesn't seem to be anything I can do...

(This is on Drupal 7.59)

Problem/Motivation

Drupal core benefits from proper deprecation testing use @trigger_error(... - see https://www.drupal.org/core/deprecation.

Contributed modules also want to leverage the same system for testing to prove they are up-to-date with the latest API changes and to handle deprecating their own code. However this is tricky because a contributed module typically has to support the current patch branch, the future development branch and the old patch branch which is still security supported. As of 25th Sept 2018 that's 8.5.x, 8.6.x and 8.7.x. If core adds a new deprecation in 8.6.x and new code to support that deprecation (eg. #2996789: Deprecate Drupal\field\Tests\EntityReference\EntityReferenceTestTrait) then it is not possible to have passing tests on all three branches. In 2996789 the contrib maintainers argue for the deprecation to be removed from 8.6.x but this only pushes the problem down the line and they'll still have fails in 8.7.x.

Possible solutions

1. Only add deprecation messages to core at a later date. I.e introduce the new code path in 8.6.x and only commit the deprecation @trigger_error() in 8.8.x. That way when 8.8.x starts to trigger the deprecation the 8.7.x (patch) and 8.6.x (security) branches have the code and everyone can easily move. @alexpott thinks this is a terrible solution because it means new usages of deprecated code will be added to core and we will forget to add deprecations.
2. We could do solution 1 and mitigate @alexpott's concerns by opening a future deprecation branch (eg. 8.8.x) to commit deprecation messages to but that will increase complexity for everyone working on core especially core maintainer. And @alexpott still thinks this is not a good solution
3. Contrib needs a way to say ignore deprecations when testing against these branches. So for example a contrib module could disable deprecation testing against the patch and security branch (now 8.5.x and 8.6.x) but enable it against the future dev branch (8.7.x). That way the contrib module can prove they work against the currently support Drupal branches but also be aware of future work coming up. Additionally it would be great to be test any matrix the contrib author would like. I.e. to have testing with and without deprecations against the future dev branch.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

When applying the telephone link field formatter on number with 5 digits or less, Drupal miserably breaks, displaying some kind of WSOD with the following message: "The website encountered an unexpected error. Please try again later". Another message can be then found in the watchdog: InvalidArgumentException: The URI 'tel:112' is invalid. You must use a valid URI scheme. in Drupal\Core\Url::fromUri() (line 301 of /media/alex/4126b75c-86e8-4b12-a7c2-08e2d7dbfb08/alex/201310/drupal/core/lib/Drupal/Core/Url.php).

Steps to reproduce

• Create a content type with a telephone field.
• In the "Manage Display" page, choose the "Telephone link" field formatter for this field.
• Create a node of that content type with "123" as value of this field.
• The exception is thrown when the page is displayed.

Cause

The bug occurs in the parse_url PHP function, which processes numbers with 5 digits or less like TCP ports.

Proposed resolution

• Not allowing numbers with 5 digits or less: however, short numbers do exist, like emergency numbers, internal numbers, etc.
• We might have to deal with these numbers differently, though: are there specifications about this?
• Writing our own function, instead of the parse_url PHP function.
• Use a tiny hack to force parse_url to behave as expected. (add an empty query string at the end of the uri)

The underlying parse_url PHP function problem can be managed in a follow up issue. See https://www.drupal.org/node/2575577

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

1. Define 3 batches with operations.
2. batch_set($batch_0);
3. batch_process();
4. During the processing of the first batch two new batches are being added through batch_set.
5. Because there is an active batch the new batch being added will be not placed at the end but prepended to the batch set stack right after the current active batch, but the operations of the other batches, that are already in the db queue will not be reordered. The batch set list will look now like this - $batch_0, $batch_1, $batch_2, but the queued operations will look like this - drupal_batch:49:0 (batch 0), drupal_batch:49:1 (batch 1), drupal_batch:49:1 (batch 2). This leads to having the batch set stack like 0-1-2, but the operations are queued in the wrong order - 0-2-1.

A current example in core is when installing a new module in hook_update_N:
1.DbUpdateController::triggerBatch() starts the processing of the updates in a batch.
2. During the updates a module is being installed.
3. The installation of a module triggers locale_system_update(), which on its turn will call batch_set() twice.
4. The second batch set from locale_system_update() depends on the first batch set from the same function.
5. The problems starts with the second call to batch_set() in locale_system_update().
6. What has happened now is the following:
6.1. The second batch set from locale_system_update() is put in front of the first batch set from locale_system_update(), which means it will be processed before the first one - wrong, because it depends on the first one and the first one should be executed before the second one.
6.2. The operations from the second batch set from locale_system_update() are being put together into the same queue of the first batch set from locale_system_update(), because the indexes of the batch set stack are the ones being used to determine the queue name and prepending the second batch set and reordering the indexes breaks all the corresponding queue mapping leading to executing operations in a batch set, which do not belong to that batch set.
7. In this case we notice the problem by having warning that the functions locale_translation_batch_status_check(), locale_translation_batch_fetch_download() and locale_translation_batch_fetch_import() could not be found. We see these warnings because the operations are being processed as part of the wrong batch set and not the correct $batch['file'] is being included! The warnings:

call_user_func_array() expects parameter 1 to be a valid callback, function 'locale_translation_batch_status_check' not found or invalid function name          [warning]
batch.inc:163
call_user_func_array() expects parameter 1 to be a valid callback, function 'locale_translation_batch_fetch_download' not found or invalid function name        [warning]
batch.inc:163
call_user_func_array() expects parameter 1 to be a valid callback, function 'locale_translation_batch_fetch_import' not found or invalid function name          [warning]
batch.inc:163

Proposed resolution

1. Ensure that when multiple batches are being added during an active batch, that they will be put into the batch set stack before the ones that are already in the queue, but the order of the batches added during an active batch should be maintained. This means:

1. batch_set($batch_1);
2. batch_process();
3. During the processing of an operation from $batch_1, batch_set() is called twice with $batch_2 and $batch_3.
4. $batch_2 should be processed before $batch_3.

2. Ensure that when prepending and appending batch sets during an active batch the batch set queue mapping will be maintained by not breaking the indexes in the batch set stack.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

A created translatable content type added to the install config of a module or an install profile results in SQL error "Unknown column 'content_translation_source' in 'field list'" when attempting to add new content of that type.

Steps to replicate:
1. Create a content type with 'Enable translations' checked
2. Export content type as a feature
3. Add feature to install profile's info.yml dependencies along with language and content_translation modules
4. Install site profile
5. Log in, Add content of this type, Save

Error returned:

The website encountered an unexpected error. Please try again later.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'content_translation_source' in 'field list': INSERT INTO {node_field_data} (nid, vid, type, langcode, title, uid, status, created, changed, promote, sticky, revision_translation_affected, default_langcode, content_translation_source, content_translation_outdated) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14); Array ( [:db_insert_placeholder_0] => 2 [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => page [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => asdf [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 0 [:db_insert_placeholder_7] => 1445445894 [:db_insert_placeholder_8] => 1445445901 [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => und [:db_insert_placeholder_14] => 0 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 757 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Proposed resolution

Instead of manually creating/updating the content translation fields in a number of places (UI/Migration/Config Import) react to saving of the Content Language Settings config entity directly in content_translation.module. This both allows removing/consolidating code as well as covers the previously missing case of installation of module/profile config.

Problem/Motivation

\Drupal\node\NodeViewsData provides a custom join from the revision data table to the data table, which shouldn't be needed because \Drupal\views\EntityViewsData already has it:

      // Join the revision table to the base table.
      $data[$views_revision_base_table]['table']['join'][$views_base_table] = [
        'left_field' => $revision_field,
        'field' => $revision_field,
        'type' => 'INNER',
      ];

Proposed resolution

Remove the unneeded custom join.

Remaining tasks

Review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Problem/Motivation

The relationship that joins the node revision table to the base table fails to ensure the correct language is joined. This can be reproduced in content moderation by:

• Adding two languages.
• Creating a draft item of content and translating it.
• On the "Moderated content" tab, two entires will be displayed.

Proposed resolution

Fix the views data to add langcode as additional criteria for the join.

Remaining tasks

User interface changes

API changes

Data model changes