I have a content-type with an address field on it. The field is optional. I cannot send null as a value for that field or I get a 500 internal server error.

This happens on create (POST) or update (PATCH). I would expect to be able to remove such an optional field value from a node by sending a null value in a request.

I can successfully create a node if I pass in a valid address field or do not supply one at all. BUT in the case that I don't supply a value then the serialized response from the POST will contain the field attribute with a value of null. I would expect that if I changed an attribute value in such a result and send the content the server gave me directly back for an update (PATCH) it would succeed (say I just change the title of the node, the server should be able to deserialize what it serialized to me) but I can't because the server result contains null so my client needs to know to delete the field if the property is set and has a null value to avoid the 500 internal server error.

At this point it seems I simply cannot remove an optional address from the node since I cannot send an empty address (the server will complain that is invalid) and I cannot send null to have it completely removed. I haven't yet tried deleting the property on PATCH but this would go against the grain of the verb being a sparse UPDATE.

I.e. per the JSON API specification for PATCH

If a request does not include all of the attributes for a resource, the server MUST interpret the missing attributes as if they were included with their current values. The server MUST NOT interpret missing attributes as null values.

The stack trace:

Error: Call to a member function getClass() on null in /drupal/web/modules/contrib/jsonapi/src/Normalizer/FieldItemNormalizer.php on line 117 #0 /drupal/vendor/symfony/serializer/Serializer.php(182): Drupal\\jsonapi\\Normalizer\\FieldItemNormalizer->denormalize(NULL, 'Drupal\\\\address\\\\...', 'api_json', Array)\n#1 /drupal/web/modules/contrib/jsonapi/src/Serializer/Serializer.php(75): Symfony\\Component\\Serializer\\Serializer->denormalize(NULL, 'Drupal\\\\address\\\\...', 'api_json', Array)\n#2 /drupal/web/modules/contrib/jsonapi/src/Normalizer/FieldNormalizer.php(65): Drupal\\jsonapi\\Serializer\\Serializer->denormalize(NULL, 'Drupal\\\\address\\\\...', 'api_json', Array)\n#3 /drupal/vendor/symfony/serializer/Serializer.php(182): Drupal\\jsonapi\\Normalizer\\FieldNormalizer->denormalize(NULL, '\\\\Drupal\\\\Core\\\\Fi...', 'api_json', Array)\n#4 /drupal/web/modules/contrib/jsonapi/src/Serializer/Serializer.php(75): Symfony\\Component\\Serializer\\Serializer->denormalize(NULL, '\\\\Drupal\\\\Core\\\\Fi...', 'api_json', Array)\n#5 /drupal/web/modules/contrib/jsonapi/src/Normalizer/ContentEntityDenormalizer.php(77): Drupal\\jsonapi\\Serializer\\Serializer->denormalize(NULL, '\\\\Drupal\\\\Core\\\\Fi...', 'api_json', Array)\n#6 /drupal/web/modules/contrib/jsonapi/src/Normalizer/EntityDenormalizerBase.php(99): Drupal\\jsonapi\\Normalizer\\ContentEntityDenormalizer->prepareInput(Array, Object(Drupal\\jsonapi\\ResourceType\\ResourceType), 'api_json', Array)\n#7 /drupal/vendor/symfony/serializer/Serializer.php(182): Drupal\\jsonapi\\Normalizer\\EntityDenormalizerBase->denormalize(Array, 'Drupal\\\\node\\\\Ent...', 'api_json', Array)\n#8 /drupal/web/modules/contrib/jsonapi/src/Serializer/Serializer.php(75): Symfony\\Component\\Serializer\\Serializer->denormalize(Array, 'Drupal\\\\node\\\\Ent...', 'api_json', Array)\n#9 /drupal/web/modules/contrib/jsonapi/src/Normalizer/JsonApiDocumentTopLevelNormalizer.php(169): Drupal\\jsonapi\\Serializer\\Serializer->denormalize(Array, 'Drupal\\\\node\\\\Ent...', 'api_json', Array)\n#10 /drupal/vendor/symfony/serializer/Serializer.php(182): Drupal\\jsonapi\\Normalizer\\JsonApiDocumentTopLevelNormalizer->denormalize(Array, 'Drupal\\\\node\\\\Ent...', 'api_json', Array)\n#11 /drupal/web/modules/contrib/jsonapi/src/Serializer/Serializer.php(75): Symfony\\Component\\Serializer\\Serializer->denormalize(Array, 'Drupal\\\\jsonapi\\\\...', 'api_json', Array)\n#12 /drupal/web/modules/contrib/jsonapi/src/Controller/EntityResource.php(820): Drupal\\jsonapi\\Serializer\\Serializer->denormalize(Array, 'Drupal\\\\jsonapi\\\\...', 'api_json', Array)\n#13 /drupal/web/modules/contrib/jsonapi/src/Controller/EntityResource.php(306): Drupal\\jsonapi\\Controller\\EntityResource->deserialize(Object(Drupal\\jsonapi\\ResourceType\\ResourceType), Object(Symfony\\Component\\HttpFoundation\\Request), 'Drupal\\\\jsonapi\\\\...')\n#14 [internal function]: Drupal\\jsonapi\\Controller\\EntityResource->patchIndividual(Object(Drupal\\jsonapi\\ResourceType\\ResourceType), Object(Drupal\\node\\Entity\\Node), Object(Symfony\\Component\\HttpFoundation\\Request))\n#15 /drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)\n#16 /drupal/web/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->Drupal\\Core\\EventSubscriber\\{closure}()\n#17 /drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\\Core\\Render\\Renderer->executeInRenderContext(Object(Drupal\\Core\\Render\\RenderContext), Object(Closure))\n#18 /drupal/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)\n#19 /drupal/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\\Core\\EventSubscriber\\EarlyRenderingControllerWrapperSubscriber->Drupal\\Core\\EventSubscriber\\{closure}()\n#20 /drupal/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\\Component\\HttpKernel\\HttpKernel->handleRaw(Object(Symfony\\Component\\HttpFoundation\\Request), 1)\n#21 /drupal/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\\Component\\HttpKernel\\HttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#22 /drupal/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\\Core\\StackMiddleware\\Session->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#23 /drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\\Core\\StackMiddleware\\KernelPreHandle->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#24 /drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\\page_cache\\StackMiddleware\\PageCache->pass(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#25 /drupal/web/modules/contrib/jsonapi/src/StackMiddleware/FormatSetter.php(45): Drupal\\page_cache\\StackMiddleware\\PageCache->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#26 /drupal/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\\jsonapi\\StackMiddleware\\FormatSetter->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#27 /drupal/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#28 /drupal/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#29 /drupal/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\\StackedHttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#30 /drupal/web/index.php(19): Drupal\\Core\\DrupalKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request))

I'm upgrading from 1x and I must say I'm actually running into a lot of 500 internal server errors relating to property definitions within complex fields. So far I've been adding debug code to FieldItemNormalizer to figure out what's causing the server to choke and working around issues like this.

In this case if I add a few dd statements in the offending code:

public function denormalize($data, $class, $format = NULL, array $context = []) {
...
dd($class);
    if (!is_array($data)) {
      $property_value = $data;
      $property_name = $item_definition->getMainPropertyName();
dd($property_name.'='.isset($property_definitions[$property_name]));
      $property_value_class = $property_definitions[$property_name]->getClass();
      return $denormalize_property($property_name, $property_value, $property_value_class, $format, $context);
    }
...
}

The resulting output is:
Drupal\address\Plugin\Field\FieldType\AddressItem
followed by
=
so $property_name is empty as is its value in $property_definitions.

original D8 issue: #728702: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.

Problem/Motivation

If the user visits the site index for a Drupal site that has database credentials in settings.php but has not yet been installed completely, the user will receive a fatal error that does not in any way indicate that the user should visit install.php to complete the installation.

Proposed resolution

Detect an empty database during bootstrap, and redirect to install.php if installation is not already in progress.

Patch in #728702-17: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty. is confirmed to resolve this issue for both D7 and D8.
see patch in this issue rerolled from #728702-36: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.

Remaining tasks

None.

User interface changes

User will be redirected to install.php if there is a database configuration but the database is empty.

API changes

None.

Original report by @arpeggio

The setup are:
-database empty
-drupal updated from CVS
-set the C:\xampp\htdocs\sites\sites.php with $sites['localhost'] = 'kapitbisig.com';
-manually populated the the database credentials in C:\xampp\htdocs\sites\kapitbisig.com\settings.php

I got the following error message when I browsed http://localhost

Fatal error: Call to undefined function _system_rebuild_theme_data() in C:\xampp\htdocs\includes\theme.inc on line 586

Acquia performed a series of user tests around Layout Builder (I'm still working out how to make as much of those results as we can generally available to the community). But universally, this was a huge barrier to folks.

Excerpts from the findings:

Users had difficulty navigating among the many block types available to them. It was unclear how the categories were constructed. One user wanted meta-data versus media types (etc), but saw these types mixed within categories. Users wanted to sort (e.g., alphabetically, chronologically) among block types rather than use the categories provided.

Additionally, this sidebar is basically a never-ending barf of "Drupally words" to an audience of people (content authors) who shouldn't need to know/care that Drupal (or views or blocks or CTools or whatever) is what's powering the interface. Another key quote from the findings:

Users shouldn’t need to speak Drupal to use Drupal!

Indeed. ;)

#2977587: Improve block listing in Layout Builder by hiding uncommon block plugins attempts to solve this so by simply hiding some of the clutter behind a "more" link (not sure this is a great solution; it was more of a quick-and-dirty stop-gap back when we were advocating for this problem to be a stable release blocker for Layout Builder)

I think what we should do in this issue (or maybe sub-issues, but let's try to get a "vision" together here first) is:

- Brainstorm some solutions for this general problem (maybe also investigating into how other CMSes have solved this problem in their page building tools)
- If we stick with categories, come up with a sensible, "human readable" list of categories for blocks to be placed in (bearing in mind contrib will need to put things here too)
- Come up with an "MVP" we can try and get done in relatively short order, so we can ideally try and get something into 8.8 before October.

Thoughts/sketches welcome!

Problem/Motivation

WS-2018-0072 high severity
Vulnerable versions:< 2.2.0
Patched version: 2.2.0
Versions of https-proxy-agent before 2.2.0 are vulnerable to a denial of service. This is due to unsanitized options (proxy.auth) being passed to Buffer().

As per @lauriii this can be fixed publically.

it could be public because it only affects our development tooling, and it’s also already public information since its in a 3rd party dependency

Proposed resolution

Update the yarn package.

Remaining tasks

Create a patch

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Updated nightwatch to version 1.2.1
Updated chromedriver to version 75.1.0
Updated stylelint-no-browser-hacks to 1.2.1

This is a follow-up issue to #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`.

The tabbing was fixed in #118 and #119 so that the "Edit media" button is accessible by tabbing.

We should add functional javascript testing of the tabbing. Unfortunately, I spent some time on this and have been unable to simulate a tab key press in the test so far (in media/tests/src/FunctionalJavascript/CKEditorIntegrationTest.php).

After discussing with phenaproxima, we decided to defer this to a follow-up, so as not to block the issue on the test coverage for this feature.

For now we are going to manually test the feature. This follow-up is to add actual function javascript test coverage for tabbing to the "Edit Media" button.

Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8

Problem/Motivation

In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.

Priority is given to the D7 migration because the D6 one might be effected by the term node migrations.

This is for migrating node translation revision, migrating revision for entity translation is now being done in #3076447: Migrate D7 entity translation revision translations to D8.

Proposed resolution

The current focus is to get the D7 version working and then move those changes to D6.

D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.

• For each D6 and D7 revision, the migration source should yield every translation that we think goes along with it. This means multiple rows per revision, which is slightly confusing. But it will provide a mostly-sane revision history.
• Make sure to pull in the correct fields for each such revision-translation row. The row's vid-for-matching-revisions-together may not necessarily be the same as its vid-for-finding-field-values.
• Make sure the current revision of each node has the correct data in it. This must be true even if the current revision is not the highest one (ie: revision was reverted).
• Make the code to accomplish this comprehensible. Previous attempts had complex subquery-joins, which need at least more explanation. Maybe there's a better solution without weird joins?

Remaining tasks

From #55

1. Determine the dependency for these migrations. Running from the UI is different than is being done in tests and it does make a difference to the revisions in the destination site.
2. Make sure the d6 and d7 tests includes testing a fields on each revision
3. The vid of the first revision can be higher than the vid of the later revision. This is true for both d6 and d7.
4. Make sure that the use of migration_tag 'translation' is documented. It is used in
   • d6_node_translation.yml
   • d7_node_entity_translation.yml
   • d7_node_translation.yml
   • d7_node_revision_translation.yml
   • d7_user_entity_translation.yml
   • d7_taxonomy_term_entity_translation.yml/li>
   • d7_comment_entity_translation.yml
   • d6_node_revision_translation.yml
5. Make sure that the source plugin 'translation' property is documented
6. Make sure that the destination plugin 'translations' property is documented

Problem/Motivation

This issue is a follow-up issue based on accessibility feedback from rainbreaw.

See #2994702-107: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`

Dialog UI in standard profile (with Bartik theme) should use an outline around form elements when tabbing, as does demo umami profile.

Demo umami outline.

Standard profile, highlight, but no outline.

Proposed resolution

Suggested improvement, add outline:

Remaining tasks

• Review
• Commit

In Views UI Advanced settings, Contextual Filters are placed above Relationships. The problem with this order is that some contextual filters (arguments) only show up if the user chooses a relationship first.

People tend to work top down, so imho some misconceptions about contextual filters and relationships could easily be avoided by changing the order of those items and listing relationships above contextual filters.

In others words, contextual filters may depend on relationships, so the latter ones should be listed first.

After upgrading to 8.4 we noticed a performance decrease on one of our sites. The page that is taking minutes to load is a multilanguage page with several field collections and revisions enabled.

Some debugging lead me to the change in issue 2864995.

This change introduces a latestRevision() method which is used by QuickEdit (this explains why it is only when logged in). On a field collection that has about 4000 revisions, this query takes seconds to run.

If I understand correctly the change introduces a self-join to the base revision table. Because of this, for each revision in the table, a set of revisions + next revisions is added to the result. From this result only the row that has no next revision (is null) is used (in my case 7000000 rows are searched for the one that has no next revisions).

Maybe we can think of a more efficient way of querying the latest revision?

Problem/Motivation

Core currently provides support for embedding of images. It is currently impossible to embed a video or a document. Also, when #2801277: [META] Support remote media assets as first-class citizens by adding Media Entity module in core lands we'll need to embed media entities rather than files.

Contrib already has a solution for this. Entity embed is a module that supports embedding of any renderable entity and supports extensive display configuration.

Proposed resolution

Move parts of Entity embed into core (simplified text filter) and handle embedding through it. Entity embed display plugins, embed button config entities, and other related API surface will stay in contrib. The simplified text filter will only support embedding media entities; people wishing to embed other types of entities will need to use contrib. Existing WYSIWYG functionality would remain the same.

Remaining tasks

In order:

1. ✅ #2940029: Add an input filter to display embedded Media entities
2. ✅ #2994696: Render embedded media items in CKEditor
3. ✅ #2994699: Create a CKEditor plugin to select and embed a media item from the Media Library
4. #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`
5. SHOULD-HAVE #3066802: Add a new view mode for embedded media
6. SHOULD-HAVE #3074608: [PP-1] Optionally allow choosing a view mode for embedded media in EditorMediaDialog
7. SHOULD-HAVE #3073901: Determine an upgrade path from CKEditor image button to media library

Additional required bug fixes:

• #3067116: text_summary() returns malformed (not normalized) HTML for basic_html and other formats that use filter_html instead of filter_htmlcorrector
• #3067124: text_summary() returns a plain string, even if passed a MarkupInterface object

Additional related and follow-up issues

• #3074859: Add a button to remove an embedded media item from the editor
• #3074863: Improve the UX of captioning in CKEditor
• #3074867: Remove role attribute from figure tags generated by filter_caption
• #2910102: Improve icon colour contrast for WCAG 2.1

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Problem/Motivation

Cache of entities are not invalidated when the entity label changes.

Steps to reproduce for nodes & breadcrumbs (from #3):

1. Create a node with title 'Title A'.
2. Change the title to 'Title B' and check the 'Create new revision'.
3. Open the Revisions tab > Breadcrumb shows the right title (Title B).
4. Change the title to 'Title C' and check the 'Create new revision'.
5. Open the Revisions tab.

Expected: The title in the breadcrumb is 'Title C'.
Actual: the title in the breadcrumb is 'Title B'.

Steps to reproduce for users (from #48):

1. 1. Log in
2. 2. Edit your username and save.
3. 3. Return to the edit screen for your user account.

Expected: Breadcrumb shows your new username
Actual: You'll see your old username is still utilised in the breadcrumb.

Proposed resolution

Allow attaching cacheability metadata to titles with a new CacheableTitleResolverInterface that returns a static or dynamic title (with cacheable metadata).

Altering content moderation field using the default REST endpoints results in access denied when the moderation state change involves changing the publish state of the item because of the following:

function content_moderation_entity_field_access($operation, FieldDefinitionInterface $field_definition, AccountInterface $account, FieldItemListInterface $items = NULL) {
  if ($items && $operation === 'edit') {
    \Drupal::logger('content_moderation')->notice(print_r(\Drupal::routeMatch()->getRouteName(), 1));

    /** @var \Drupal\content_moderation\ModerationInformationInterface $moderation_info */
    $moderation_info = Drupal::service('content_moderation.moderation_information');

    $entity_type = \Drupal::entityTypeManager()->getDefinition($field_definition->getTargetEntityTypeId());

    $entity = $items->getEntity();

    // Deny edit access to the published field if the entity is being moderated.
    if ($entity_type->hasKey('published') && $moderation_info->isModeratedEntity($entity) && $entity->moderation_state && $field_definition->getName() == $entity_type->getKey('published')) {
      return AccessResult::forbidden('Cannot edit the published field of moderated entities.');
    }
  }

  return AccessResult::neutral();
}

I propose we make an exception for this when current route is any rest route. Patch attached.

Problem/Motivation

After the completion of the new Extension system API's in #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList and #2659940: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList, drupal_get_path() has been replaced with the theme, module and profile extension listing services. This issue will deprecate the usage of drupal_get_path() in core and replace with the relevant extension listing service calls (Module|Profile|Theme)ExtensionList::getPath().

Proposed resolution

Replace all dynamic uses drupal_get_path() with (Module|Profile|Theme)ExtensionList::getPath(). The earlier issue #2351919: Replace uses of drupal_get_path() with __DIR__ where possible had taken care of static includes where relative location of the files were fixed.

Remaining tasks

Reviews
Commit

User interface changes

None

API changes

drupal_get_path() is deprecated.

Problem/Motivation

At the moment every content entity type must implement hook_user_cancel() to do updates when a user is canceled. We have comment_user_cancel() and node_user_cancel() but we are missing taxonomy_user_cancel(), file_user_cancel() and media_user_cancel(). We need to handle both user_cancel_block_unpublish and user_cancel_reassign.

Also we have node_user_predelete() and comment_user_predelete() that will delete all the nodes and comments if the user is deleted. We might need something generic for that too.

Proposed resolution

Maybe we should have a generic implementation for entity types that implement EntityOwnerInterface and EntityPublishedInterface. However this might cause more problems as something like a commerce order might implement EntityOwnerInterface and I'm not sure that deleting them is correct.

Remaining tasks

Discuss solution - should we try for a generic solution or implement the hook for each module in core.

User interface changes

@todo - perhaps the user cancel form should give more indication of how many and what entities are going to be affected.

API changes

None - only new hook implementations.

Data model changes

Content entities updated correctly on user cancel.

Release notes snippet

@todo - this issue will definitely need a change record

Hey there!

I'm having a weird problem with Drupal\contact\Entity\Message-entities in Drupal 8.7.6.

We are using multiple Contact forms with some extra fields added via field-module.

Everything is working fine, but when I navigate to status report (/admin/reports/status), the site crashes with the following error:

Error: Call to a member function getType() on null in Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->getDedicatedTableSchema() (line 2213 of /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php)

Here's the code that causes the crash:

protected function getDedicatedTableSchema(FieldStorageDefinitionInterface $storage_definition, ContentEntityTypeInterface $entity_type = NULL) {
	$entity_type = $entity_type ?: $this->entityType;
	$description_current = "Data storage for {$storage_definition->getTargetEntityTypeId()} field {$storage_definition->getName()}.";
	$description_revision = "Revision archive storage for {$storage_definition->getTargetEntityTypeId()} field {$storage_definition->getName()}.";

	$id_definition = $this->fieldStorageDefinitions[$entity_type->getKey('id')];
	if ($id_definition->getType() == 'integer') {
	  // ...
	}
	// ...
}

It seems that the $entity_type (ContentEntityType with a class of Drupal\contact\Entity\Message) does not have the entity_key 'id'. Upon closer inspection that seems to be the case: $entity_type->hasKey('id') // => FALSE.

Message-entity annotation does not define an entity_key for id:

/**
 * Defines the contact message entity.
 *
 * @ContentEntityType(
 *   id = "contact_message",
 *   label = @Translation("Contact message"),
 *   label_collection = @Translation("Contact messages"),
 *   label_singular = @Translation("contact message"),
 *   label_plural = @Translation("contact messages"),
 *   label_count = @PluralTranslation(
 *     singular = "@count contact message",
 *     plural = "@count contact messages",
 *   ),
 *   bundle_label = @Translation("Contact form"),
 *   handlers = {
 *     "access" = "Drupal\contact\ContactMessageAccessControlHandler",
 *     "storage" = "Drupal\Core\Entity\ContentEntityNullStorage",
 *     "view_builder" = "Drupal\contact\MessageViewBuilder",
 *     "form" = {
 *       "default" = "Drupal\contact\MessageForm"
 *     }
 *   },
 *   admin_permission = "administer contact forms",
 *   entity_keys = {
 *     "bundle" = "contact_form",
 *     "uuid" = "uuid",
 *     "langcode" = "langcode"
 *   },
 *   bundle_entity_type = "contact_form",
 *   field_ui_base_route = "entity.contact_form.edit_form",
 * )
 */

It seems that Message is also the only entity in core without an "id" entity_key (aside from Drupal\entity_test\Entity\EntityTestNoId). Also it seems that the key has never been there.

If I modify the method getDedicatedTableSchema by adding a default value, the status report page renders fine:

protected function getDedicatedTableSchema(FieldStorageDefinitionInterface $storage_definition, ContentEntityTypeInterface $entity_type = NULL) {
    $entity_type = $entity_type ?: $this->entityType;
    $description_current = "Data storage for {$storage_definition->getTargetEntityTypeId()} field {$storage_definition->getName()}.";
    $description_revision = "Revision archive storage for {$storage_definition->getTargetEntityTypeId()} field {$storage_definition->getName()}.";

    $id_key = $entity_type->getKey('id');
    if ($id_key === FALSE) {
      $id_key = 'id';
    }
    $id_definition = $this->fieldStorageDefinitions[$id_key];

    if ($id_definition->getType() == 'integer') {
      // ...
    }
    // ...
}

This error has persisted on our production site through multiple Drupal versions but the messaging feature has been working flawlessly.

Could anyone point me to the right direction to fix this annoying error?

The issue is about adding a Relationship value object to wrap/replace entity reference fields within JSON:API. Having this abstraction is valuable because, unlike an entity reference field, a JSON:API relationship can have unique links/URLs of its own and is able to reference any resource regardless of its type (an entity reference field is limited to just one entity type). The former abstraction is useful for the JSON:API Hypermedia module and the latter will lay useful groundwork for supporting dynamic entity reference fields, reverse relationships, or resource types that aren't tied 1:1 with the entity system (useful for component-based decoupled designs).

Problem/Motivation

An entity type that has no bundle key (i.e. $entity_type->hasKey('bundle') === FALSE) is still able to expose multiple bundles, via hook_entity_bundle_info(). This is a logical nonsense. Not having a bundle key means: this entity type have no bundle (like the user entity type).

Proposed resolution

Don't allowhook_entity_bundle_info() (and hook_entity_bundle_info_alter()) to populate the bundle info list (see EntityTypeBundleInfo), with more than one entry which is the entity type ID itself, for such entity types.

Eventually consider deprecating such practice in the first step.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.

Problem/Motivation

While working on JSON:API Schema, which iterates over data types to derive a schema, this error occurs when comment module is installed:

[error] The "entity:comment:comment" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: {long list of data types...}

After some digging, it appears it's because EntityDeriver.php has this guard:

if ($bundle !== $entity_type_id) {
  $this->derivatives[$entity_type_id . ':' . $bundle] = [ ...

This is a problem because bundles can have the same ID as their associated entity type ID. This happens in core when the comment module is installed because of the "Default comment" bundle which has a machine name of comment.

Proposed resolution

Change the guard to check that the entity type does not have a bundle entity type and also to check that a bundle has not been defined by hook_entity_bundle_info(_alter) rather than the simple check that the bundle ID does not equal the entity type ID.

Remaining tasks

Supply a patch.
Write a test.
Review

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

I have quiz for around 200 user simultaneously in local server i create a submit form with ajax system when every user click the answer but only a few user successfully submit the answer in database most of them are failed maybe 95 % are failed to submit it what is going on? am i missed something ??
But when try it in one user it always look fine the answer is submitted successfully !

In multistep webform in drupal7

I have added captcha on preview page i.e last page of the form.
But when I move to back step I dont want to fill captcha means captcha should be filled only when click on submit button of the form.

I tried $form['actions']['previous']['#limit_validation_errors'] = array(); in form_alter but it is not working.

Thanks in advance.