Split off from #2820364: Entity + Field validation constraints are processed in the incorrect order.
Make it required.
aggregator_update_8200() for an example. (Via @amateescu in #2820364-29: Entity + Field validation constraints are processed in the incorrect order.None.
None.
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.
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:
\Drupal\comment\CommentStatistics::update()depends onentity_type, which is neither required nor validatedCommentNameConstraintValidatordepends onentity_idandfield_name, but runs before either of those can even possibly be validated (entity_idis required, but that's not validated beforeCommentNameConstraintis validated)- 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
Unknown, see comments.
Comment's entity_type base field is required: #2885809: 'entity_type' base field on Comment is requiredComment'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.\Drupal\Tests\rest\Functional\EntityResource\Comment\CommentResourceTestBase::testPostDxWithoutCriticalBaseFields() is no longer sending an Accept request header.TBD
TBD
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
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.
Add Theme Hook Suggestions for Fields with View Modes
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).
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.
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!
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:
:not(.js-off-canvas-ignore), to the end of all selectors used in the off-canvas css library..off-canvas-ignore-parent to the parent element..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.
Discuss the problem, determine what solution we should use.
n/a
n/a
n/a
[guessing path module?]
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)
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.
@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.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).
The bug occurs in the parse_url PHP function, which processes numbers with 5 digits or less like TCP ports.
The underlying parse_url PHP function problem can be managed in a follow up issue. See https://www.drupal.org/node/2575577
| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Create a patch | Instructions | Done | |
| Update the issue summary | Instructions | Done | |
| Add automated tests | Instructions | Done | |
| Manually test the patch | Novice | Instructions | Done |
| Add steps to reproduce the issue | Novice | Instructions | Done |
| Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions | Done |
None.
None.
None.
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
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:
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.
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).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.
\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',
];
Remove the unneeded custom join.
Review.
Nope.
Nope.
Nope.
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:
Fix the views data to add langcode as additional criteria for the join.