Problem/Motivation

It's possible for the revision ID in {node} and the one in {node_revision to be out of sync.

All reports on this issue point to this happening due to migrations, although since migrate uses the entity API, it's posted against that.

Proposed resolution

Remaining tasks

Better/shorter steps to reproduce.

User interface changes

API changes

Data model changes

Original report:

Hello Views crew. I just did an upgrade from D6 to D8 using drupal update module.

After doing the update I used the UI to delete all the content types the client doesn't require anymore.

When I go to /admin/content

I get the following PHP error:

[24-Dec-2015 13:25:36 America/Denver] Recoverable fatal error: Argument 1 passed to Drupal\views\Plugin\views\field\EntityOperations::getEntityTranslation() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in [path.to.my.site]/core/modules/views/src/Plugin/views/field/EntityOperations.php on line 116 and defined in [path.to.my.site]/core/modules/views/src/Entity/Render/EntityTranslationRenderTrait.php on line 74

So it looks like Drupal8 is using a View to list the content on this page. All the content should just be in English there is no translation going on on the old D6 site. I looked at the source code on the lines given but I am still getting up to speed on D8 architecture - anyone have any insight into the issue? Why would this sort of error happen on the basic admin/content page?

Thank you.

Seb
http://fountain-city.com

Problem/Motivation

Migrate has the concept of de-duplication, where it looks for things with identical machine names, and creates a copy if there's a match.

This is actually creating duplicates (or avoiding overwrites), but it's not really de-duplication.

Proposed resolution

Don't know, but something matching better what actually happens would be good.

Remaining tasks

User interface changes

API changes

Data model changes

API page: https://api.drupal.org/api/drupal/includes%21menu.inc/function/menu_cach...

Enter a descriptive title (above) relating to function menu_cache_clear, then describe the problem you have found:

Description contains duplicate word: cached cached

Problem/Motivation

Nodes - as the canonical example of revisionable entities - store the revision author, the revision timestamp and a log message for each revision. The Node entity declares these fields in its baseFieldDefinitions().

Custom blocks only provide a log, but no revision author or timestamp.

We should make this consistent and make it easy for contrib entity types to provide the same behavior.

#2666808: Add a revisionable entity base class and log interface introduced three revision metadata fields, which are named "revision_created, revision_user, revision_log_message". However the core still assumes at some places that they are called "revision_timestamp, revision_uid, revision_log". That is the case where the node entity and the block entity use the previous nomenclature. But unfortunately this is not the only place.. There is one another really important place and it is in SqlContentEntityStorage::getTableMapping where the only the old nomenclature is used to put these revision metadata fields in the "entity_type_id_revision" table. #2666808: Add a revisionable entity base class and log interface did not extend the list with the new revision metadata fields and what now happens is that if you use the new RevisionLogEntityTrait your revision metadata fields will not be put like they should in the "entity_type_id_revision" table, but they will be put in the field table.

Proposed resolution

Provide a revision_metadata_keys key in the entity annotation which provides a mapping of common identifiers like "log", "uid", "created" to the actual field names. Because there are places where we need the list of revision metadata fields explicitly, for example in SqlContentEntityStorage::getTableMapping() or in ContentEntityBase::hasTranslationChanges() with #2615016: [PP-1] ContentEntityBase::hasTranslationChanges doesn't skip the revision metadata fields leading to wrong result, this is not part of the entity_keys key even though it is similar in nature. This also allows to ignore (at least for the scope of this issue) the fact that entity key fields get a NOT NULL constraint in the SQL schema. Note that calling EntityType::getKeys() will also not return the revision metadata keys.

In order to provide backwards-compatibility, in the case that revision_metadata_keys is not set, we will check the field definitions if fields with the appropriate names (revision_log, revision_log_message) exist and use those as as values. This behavior can be disabled by a boolean parameter which is utilized in RevisionLogEntityTrait because due to the above checking of the field definitions, checking the revision metadata keys while building the field definitions would lead to infinite recursion.

Because the hardcoding of incorrect revision metadata field names in SqlContentEntityStorage::getTableMapping() entity types using RevisionLogTrait have the database columns for the revision metadata fields in the wrong table. (They are in the revision data table, but they should be in the revision table.) To correct this, an update function is provided that moves the field values to the correct table and fixed any views that reference the old table names in their views field configuration.

Remaining tasks

Follow-up issue for D9 to remove the hard coded revision metadata field list from \Drupal\Core\Entity\RevisionLogEntityTrait::getRevisionMetadataKey and RevisionLogEntityTrait should create the fields only if they are mentioned in the entity annotation.

Follow-up issue for D9 to remove the backwards compatibility parameter from \Drupal\Core\Entity\ContentEntityTypeInterface::getRevisionMetadataKeys and make the annotation for revision metadata keys obligatory for revisionable entities.

User interface changes

API changes

New functions :
-EntityTypeInterface::getRevisionMetadataKeys
-EntityTypeInterface::getRevisionMetadataKey
-EntityTypeInterface::hasRevisionMetadataKey

Change record

https://www.drupal.org/node/2831499

For now it's possible to have pagination only based on elements. It would be really helpful to have a pager for grouping as well.

Let's say we have 100 nodes, each node tagged with 1 of 5 terms from 1 vocabulary. Then we group those nodes by their term. Now under navigation option there shall be the possibility to page the results by a given number of groups. For example 1 group per page, so that now we have 5 pages, and every element of that group on one single page.

I am trying to modify an existing d8 views join (not to add a new one).

I am able to get the join data using $query->getJoinData(), but I can not put modified join back to the $query.

Let's say I am trying to remove the 'langcode' condition with the code below.

function mymodule_views_query_alter(Drupal\views\ViewExecutable $view, Drupal\views\Plugin\views\query\Sql $query) {
    $joindata = $query->getJoinData("node__field_joined_whatever", "node_field_data");

//$joindata contains the join I need, so far so good

    foreach($joindata->extra as $ix=>$val) {
      if (isset($val['field']) && $val['field'] == 'langcode') {
        unset($joindata->extra[$ix]);
      }
    }

//here I have modified join array, but there is nothing like '$query->setJoinData()'
...

}

Is there a way to put a $joindata back to the $query?

Whenever a comment is edited, the "created" timestamp still gets changed in two ways:

a) admin edit
While #1005004: Editing a comment destroys its creation date makes sure it isn't completely overwritten, it still gets rounded down to the full minute.
This is because the "Authored on" field in the Admin section only takes H:i(hh:mm), and this value gets saved to the record, whether it has been changed or not. This won't be a big thing in most cases, but we never know - it's simply not correct.
Probably the "Authored on" field should take H:i:s(hh:mm:ss), which seems the cleanest way and is consistent to the node edit form.

b) user edit
The second part of #714958: Comment timestamp lost when edited by administrator wasn't fixed either:

When a non-admin edits a comment, the "created" date is always set to now.

For non-admins the "Administration" section stays hidden. However, the "Authored on" field is fed with an empty string, which upon saving is automatically replaced by now().
Instead, the created date should be given, if existing (it obviously doesn't exist for new, unsaved comments).

EDIT (@diqidoq): fixd for D8, but not for D7, please read comments #97/#98 why this issue isn't fixed yet. Any thoughts on this are much appreciated.

Dears,
I am trying to use contextual filters with relationships and have the error below (with the relationships):

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'movadomfpadrupal._taxonomy_term__field_domaine' doesn't exist: SELECT node_field_data.langcode AS node_field_data_langcode, node_field_data.title AS node_field_data_title, node_field_data.nid AS nid, taxonomy_term_field_data_node__field_population.tid AS taxonomy_term_field_data_node__field_population_tid FROM {node_field_data} node_field_data LEFT JOIN {node__field_population} node__field_population ON node_field_data.nid = node__field_population.entity_id AND (node__field_population.deleted = :views_join_condition_0 AND node__field_population.langcode = node_field_data.langcode) LEFT JOIN {taxonomy_term_field_data} taxonomy_term_field_data_node__field_population ON node__field_population.field_population_target_id = taxonomy_term_field_data_node__field_population.tid LEFT JOIN {taxonomy_term__field_domaine} taxonomy_term_field_data_node__field_population__taxonomy_term__field_domaine ON taxonomy_term_field_data_node__field_population.tid = taxonomy_term_field_data_node__field_population__taxonomy_term__field_domaine.entity_id AND (taxonomy_term_field_data_node__field_population__taxonomy_term__field_domaine.deleted = :views_join_condition_2 AND taxonomy_term_field_data_node__field_population__taxonomy_term__field_domaine.langcode = taxonomy_term_field_data_node__field_population.langcode) LEFT JOIN {} _taxonomy_term__field_domaine ON taxonomy_term_field_data_node__field_population__taxonomy_term__field_domaine.field_domaine_target_id = _taxonomy_term__field_domaine.id WHERE (( (node_field_data.status = :db_condition_placeholder_4) AND (node_field_data.type IN (:db_condition_placeholder_5)) )) ORDER BY node_field_data_title ASC; Array ( [:db_condition_placeholder_4] => 1 [:db_condition_placeholder_5] => service [:views_join_condition_0] => 0 [:views_join_condition_2] => 0 )

I have services contents associated with taxonomy terms (populations) using an entity reference field (field_population).
"Populations" taxomony are associated to domain entries (https://www.drupal.org/project/domain) using a reference field (field_domaine).

In my view (called "services" which displays services contents) when I add the relationship to the "Populations" taxonomy terms, everyhtning goes well.
When I add the relationship to the reference to a domain field, I go the error.
What am I doing wrong ?

View details is in attachment

Thanks for your help?

hello. i would like to rewrite the value of my view's path field in views-view-fields.html.twig template. I tried the following and the link is messed up.
<a href="{{ fields.path.content }}" alt="">{{ fields.title.content }}</a>

my guess is it needs to be written with some type of filter combination and i looked everywhere and can only find examples on how to do this in a node.html.twig file but not in views templates. would somebody kindly advise on how to write this? Many thanks!

Hi,

I want to remove certain entities from the view results, before the view's pager is generated.

By now I am doing it in hook_views_post_execute(). The problem here is, that the number of results on the view pages is different then.

I do not want to create a views filter, which would require manual interaction from the user inside the views interface in the webbrowser.

I have tried also hook_views_query_alter(). The problem here is, that my module's class methods are processing entity id's (node id's in particular). It might would work with the SQL IN statement, but this is probably a problem for bigger site's and a huge performance impact. Since I need to iterate over all entity id's from the site and check access then.

My questions:

• Is there any method inside the Views module, which allows me to remove the entity id's from the view results or shall I really use hook_views_query_alter()?
• Also - if it comes to the hook_views_X methods - isn't there any more elegant class method or event? Since hooks are a mostly deprecated way in Drupal 8.

Cheers!

Currently when we are editing or loading an entity translation we first load the entity in the default translation and then initialize a new entity translation object for the desires translation. This however is unnecessary and for performance and memory reasons we should be loading the entity directly into the desired translaton and have only one instead of two entity objects.

This is actually pretty easy to do and we just have to set the property $activeLangcode in ContentEntityBase to the current content language code if the entity has a translation for it otherwise leave it set to the default language code as it is now. This however will be a really big BC break and in order to avoid it we could for Drupal 8 just introduce a site setting according to which we have the new or the previous behavior and deprecate the setting and in Drupal 9 make the new behavior the default one.

Problem/Motivation

CEB::getTranslation keeps a translation cache under $this->translation for each initialized translation, however when we call getTranslation on the default translation the default translation is not put into the translation cache which leads to initializing an additional entity object translation when retrieving the default translation from a non-default translation.

Proposed resolution

When retrieving a translation put the current translation into the translation cache as well.

Remaining tasks

Reivew & Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

I've noticed that ContentEntityBase::getTranslatedField is called recursively for non translatable fields and also in __sleep the field values of non translatable fields will be stored twice and the function getValue will be called for all the translations for which a field has been initialized. Also if you iterate over $values you will get unneeded iterations over the same values. In the case where the an referenced entity of a non translatable field will be returned by FieldItemList::getValue this would cause $values to contain the referenced entity not only once but one time for the default langcode and additionally so many times as the number of entity translations, which in case of serializing the parent would cause a bigger serialized object.

Proposed resolution

Remove the recursive call of ContentEntityBase::getTranslatedField and store directly non translatable fields only under the default langcode by keeping track which field are translatable and which not.

Remaining tasks

Review.

User interface changes

API changes

Data model changes

Problem/Motivation

When i create install profile for multilanguge site i need to provide default translated strings for different settings. In my case it is custom setting for custom search form block provided in custom module.
i put yml of the block into profile/config/install
my settingsis:
...
settings:
id: mymodule_search_block
label: 'My module search block'
provider: mymodule
label_display: '0'
form_type: global
text: ''
placeholder: 'Enter your search'

i also place translated string into profile/config/install/language/fr/ folder

settings:
label: 'My module search block'
placeholder: 'Saisir votre recherche'

also discribed schema yml file placed in mymodule/config/schema/ folder

block.settings.myblock:
type: block_settings
label: 'Search form block'
mapping:
placeholder:
type: label
label: 'Placeholder'

shema was checked with config_inspector module.
so placeholder is translatable setting of block config

but after install profile translated doesn't come into locale_target and then language config override disappear
after invoking http://cgit.drupalcode.org/drupal/tree/core/modules/locale/src/LocaleCon...
on the last install stage because it is translatable setting and because it is not present in locale.

So it looks like bug that it doesn't come to locale during installation.

Problem/Motivation

PHP's empty() function is not enough to check for $settings['min'] or $settings['max'] for numeric item - \Drupal\Core\Field\Plugin\Field\FieldType\NumericItemBase::getConstraints(), because their value can be numeric zero, and in such case constraint is not returned.

This results in possible invalid numeric values for items that have min or max boundary set to 0.

Rough example:

Custom entity class, baseFieldDefinitions()

    $fields['hour'] = BaseFieldDefinition::create('integer')
      ->setLabel(new TranslatableMarkup('Hour'))
      ->setSetting('min', 0)
      ->setSetting('max', 23);

Custom code

  $e = CustomEntity::create([ 'hour' => -100 ]);
  $violations = $e->validate();

Validation passes w/o errors, because NumericItemBase::getConstraints() does not return constraint to check for minimum.

Proposed resolution

Replace !empty() check with check for non-empty string (because an empty string is default value of min/max settings):

if ($settings['min'] !== '') {}

Problem/Motivation

steps to reproduce the problem

1. drush dl drupal
2. remove core/profiles/minimal
3. access to install.php through browser
4. Choose a language other than English
5. run install and got Error

The website encountered an unexpected error. Please try again later.
Drupal\Core\Config\UnmetDependenciesException: Configuration objects (automated_cron.settings, block.block.bartik_account_menu, block.block.bartik_branding, block.block.bartik_breadcrumbs, block.block.bartik_content, block.block.bartik_footer, block.block.bartik_help, block.block.bartik_local_actions, block.block.bartik_local_tasks, block.block.bartik_main_menu, block.block.bartik_messages, block.block.bartik_page_title, block.block.bartik_powered, block.block.bartik_search, block.block.bartik_tools, block.block.seven_breadcrumbs, block.block.seven_content, block.block.seven_help, block.block.seven_local_actions, block.block.seven_login, block.block.seven_messages, block.block.seven_page_title, block.block.seven_primary_local_tasks, block.block.seven_secondary_local_tasks, block_content.type.basic, comment.type.comment, contact.form.feedback, core.entity_form_display.block_content.basic.default, core.entity_form_display.comment.comment.default, core.entity_form_display.node.article.default, core.entity_form_display.node.page.default, core.entity_form_display.user.user.default, core.entity_view_display.block_content.basic.default, core.entity_view_display.comment.comment.default, core.entity_view_display.node.article.default, core.entity_view_display.node.article.rss, core.entity_view_display.node.article.teaser, core.entity_view_display.node.page.default, core.entity_view_display.node.page.teaser, core.entity_view_display.user.user.compact, core.entity_view_display.user.user.default, editor.editor.basic_html, editor.editor.full_html, field.field.block_content.basic.body, field.field.comment.comment.comment_body, field.field.node.article.body, field.field.node.article.comment, field.field.node.article.field_image, field.field.node.article.field_tags, field.field.node.page.body, field.field.user.user.user_picture, field.storage.node.comment, field.storage.node.field_image, field.storage.node.field_tags, field.storage.user.user_picture, filter.format.basic_html, filter.format.full_html, filter.format.restricted_html, node.type.article, node.type.page, rdf.mapping.comment.comment, rdf.mapping.node.article, rdf.mapping.node.page, rdf.mapping.taxonomy_term.tags, taxonomy.vocabulary.tags) provided by standard have unmet dependencies in Drupal\Core\Config\UnmetDependenciesException::create() (line 84 of core/lib/Drupal/Core/Config/UnmetDependenciesException.php).
Drupal\Core\Config\UnmetDependenciesException::create('standard', Array) (Line: 460)
Drupal\Core\Config\ConfigInstaller->checkConfigurationToInstall('module', 'standard') (Line: 132)
Drupal\Core\ProxyClass\Config\ConfigInstaller->checkConfigurationToInstall('module', 'standard') (Line: 141)
Drupal\Core\Extension\ModuleInstaller->install(Array, ) (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array, ) (Line: 1555)
install_install_profile(Array) (Line: 660)
install_run_task(Array, Array) (Line: 538)
install_run_tasks(Array) (Line: 115)
install_drupal(Object) (Line: 44)

Currently in order to retrieve the default language / language code we have to first retrieve the default entity translation object, but this is actually unnecessary as we have the information about the default translation on each entity translaton object under the property $defaultLangcode so it makes to provide direct access to it.

As of now to retrieve the default language and language code we have to do :
$entity->getUntranslated()->language();
$entity->getUntranslated()->language()->getId();
But this way we are going to initialize unnecessary a new entity translation object if there isn't an existing one in the entity translation object cache.

For performance reasons it makes sense to have a direct access to the default language without having to initialize the entity default translation.

Problem/Motivation

If en entity reference field is using a ViewsSelection handler, the underlying view is not initialised with the request of the page where the field is exposed. This is because the view is built in a subsequent request of the autocomplete widget. This is bad because that view cannot use default arguments from the original request (like path arguments or query parameters). We can imagine a lot of use-cases where the autocomplete list needs to be narrowed by a parameter from the URL.

There's a "test only" patch showing this bug.

Proposed resolution

Ideally we should store the entire original Symfony request when exposing the ER field and pass it later to the view. But this would lead to a very big variance that would had flood the storage, so I went with the next proposal:

1. In EntityAutocomplete: save the request URI in expirable key/value store, keyed by a hash built from URI.
2. Pass the hashed key along the URL of autocomplete request to EntityAutocompleteController::handleAutocomplete()
3. In EntityAutocompleteController::handleAutocomplete() retrieve the original URI from the key/value expirable store.
4. Pass the original URI to the matcher (EntityAutocompleteMatcher::getMatches()).
5. The selection handler plugin will be instantiated also with the original URI.
6. In ViewsSelection::initializeView() (right now only this handler has a legitimate interest on using this value) create a mock of the original request based only on the URI and pass is as request context to the view.

Remaining tasks

None.

User interface changes

None.

API changes

• The route system.entity_autocomplete takes an additional, optional parameter {original_uri_key}
• EntityAutocompleteController::handleAutocomplete accepts an additional, optional argument $original_uri_key
• EntityAutocompleteMatcher::getMatches accepts an additional, optional argument $original_uri

Data model changes

SelectionInterface plugins receive also the original URI as original_uri config.

Problem/Motivation

Authentication provider validation happens AFTER calling the controller— this was the title I was originally going to use for this issue, and was the bug I was going to report, but it turns out to be wrong! :)

First, you must know that Basic Auth's 401s are generated by converting AccessDeniedHttpExceptions (403s) to a 401.

While working on #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, I noticed that it's possible when POSTing to receive a 400 response for an empty body (i.e. a missing entity), before you'd get a 401 response for forgetting Basic Auth headers. This very much looks like a security hole, because that 400 is generated by the REST resource's controller code. Which means the controller code is executed before authentication mechanism validation. This means that data could be mutated before access is denied!

And this is only happening for EntityResource routes, because those routes actually grant access to all users (_access: 'TRUE' as a route requirement), consciously so, to rely on entity access checking in the controller.
(That could theoretically be improved by specifying a _entity_access route requirement. However, that was already explored in #2664780: Remove REST's resource- and verb-specific permissions for EntityResource, but provide BC and document why it's necessary for other resources and deemed unfeasible. Also, it does not really matter, this works fine too, and must also be supported.)

For all other REST resources, we do have route requirements that restrict access at the routing level (before calling the controller): each REST resource gets a permission by default. EntityResource opts out from that, because those extra permissions would be pointless: entities already have the Entity Access API. Consequently, the access checking for entity resources happens inside the controller, which is how you can get that 400 response before getting a 401.

In other words, what's special about EntityResource is:

1. It overrides ResourceBase::permissions()
2. Its controller code does the necessary access checking, but only after checking certain other things
   

     public function post(EntityInterface $entity = NULL) {
       if ($entity == NULL) {
         throw new BadRequestHttpException('No entity content received.');
       }
   
       // We need an $entity object to determine whether creating it is allowed.
       if (!$entity->access('create')) {
         throw new AccessDeniedHttpException();
       }
   
       …
   

My fear was that this applied to all REST resources (in which case permissions being required by default would be a hugely mitigating factor), but it does not: it only applies to the entity REST resource, because that one wants to rely on Entity Access checking in the controller, rather than permission checking during routing.

Proposed resolution

Add test coverage to document this expectation, and ensure this expectation is never violated.

This was the original analysis I wrote, which is wrong. The subsequent more detailed analysis is also wrong, but it does point out weaknesses/peculiarities in the current implementation, which make this implementation so hard to understand, and allowed me to be mislead for a long while:

The root cause is that routes that require a particular authentication provider to be used have to specify it as the _auth route option. That should be a route requirement.

The way authentication providers are implemented is fairly fascinating. It was introduced at #1890878: Add modular authentication system, including Http Basic; deprecate global $user. We already had the new routing system then (but it probably wasn't very well understood yet). Nobody ever objected or even questioned why it added the _auth route option rather than requirement. Ironically, #1890878-29: Add modular authentication system, including Http Basic; deprecate global $userdid propose to introduce an access check to validate the used authentication provider. And #1890878-36: Add modular authentication system, including Http Basic; deprecate global $user even added it! Damien Tournoud rightfully raised the question in #1890878-49: Add modular authentication system, including Http Basic; deprecate global $user why we were introducing our own framework/API for this rather than just reusing Symfony's Security component— it was shot down by others at the time (May 2013), because "code freeze was near".

Then Crell removed the access check in #1890878-101: Add modular authentication system, including Http Basic; deprecate global $user, with the following explanation:

I also moved the “were you authenticated by the RIGHT authenticator” check to its own route enhancer, since it’s going to fire all the time anyway and what it actually does is not deny access but change the active user.

This sounds sane. Unfortunately, it's not quite truthful. The enhancer he added would never result in a 403 (when using an authentication provider that is not global nor in the route's _auth option). But the access check did do that.

He didn't notice this resulted in a big gap. Of course, there was no test coverage to tell him this was now broken. Nor did anybody notice in the subsequent 57 comments until commit.

The only major changes since then were in #2286971: Remove dependency of current_user on request and authentication manager— that removed AuthenticationEnhancer in favor of AuthenticationSubscriber.

Remaining tasks

Write test coverage for this, to ensure maintainers/developers see that this is the intentional behavior and don't waste hours figuring out why it's misbehaving when it's actually behaving correctly.

User interface changes

None.

API changes

None.

Data model changes

None.