It is not possible to uninstall a module that provides a filter plugin via config import

I think I have the same issue, after upgrading from 8.6.16 => 8.7.1 anonymous users get a 500 error with this message:

Drupal\Component\Plugin\Exception\ContextException: The 'entity:user' context is required and not present. in Drupal\Core\Plugin\Context\Context->getContextValue() (line 73 of /app/web/core/lib/Drupal/Core/Plugin/Context/Context.php).

My authenticated session continues to work.

I'm also upgrading via lando composer update drupal/core webflo/drupal-core-require-dev --with-dependencies

• PHP 7.2.16
• mysql Ver 14.14 Distrib 5.7.25

Edit: Our error is regarding "context is required and not present" which may be unrelated, so we've opened a new issue here: https://www.drupal.org/project/drupal/issues/3057399. Thanks!

I'm using Drupal 8.7.2 on Apache, PHP 7.1 and Mariadb. This is the error I got in a simple "Manage form display" submission.

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "email" plugin does not exist.

AFAIK, "email" is a core plugin that doesn't require extra installation.

saw same issue today. clearing cache solved all problems

We had (have?) a similar behavior after upgrading from 8.6.13 to 8.7.3. In our case all of our paragraph types were affected, stopping content editing cold. We were getting this line in the logs:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity:paragraph:our_names" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are...

The paragraph types were completely functional at /admin/structure/paragraphs_type, but they could not be loaded/found when editing any of our content pages.

Our fix seemed to be forcing the types to update themselves. I added a description to each one and saved it, and that re-wrote whatever piece was missing in the database or configuration. Oddly, in reviewing later logs this was also affecting a button component (entity:components:our_buttons), but that disappeared when the paragraph type got fixed. Maybe updating one paragraph triggered a re-read of all the plugin information? (I don't know Drupal well enough to know if that's a thing...)

Just installed a fresh Drupal 8.7.4, enabled content translation and ECK, can't create entity bundles, I'm getting the same error.
Running cron or clearing cache dont work.

The website encountered an unexpected error. Please try again later.Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity:activity_type" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, layout_section, metatag, search_api_text, search_api_html, field_item:address, field_item:address_zone, field_item:address_country, field_item:block_field, field_item:comment, field_item:contact_storage_options_email, field_item:datetime, field_item:file, field_item:file_uri, field_item:geolocation, field_item:image, field_item:layout_section, field_item:link, field_item:metatag, field_item:list_string, field_item:list_integer, field_item:list_float, field_item:path, field_item:redirect_source, field_item:telephone, field_item:text_long, field_item:text_with_summary, field_item:text, field_item:video_embed_field, field_item:viewsreference, field_item:changed, field_item:decimal, field_item:timestamp, field_item:string, field_item:language, field_item:created, field_item:boolean, field_item:uri, field_item:password, field_item:string_long, field_item:entity_reference, field_item:uuid, field_item:integer, field_item:float, field_item:email, field_item:map, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment_type, entity:comment, entity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:eck_entity_bundle, entity:eck_entity_type, entity:editor, entity:entity_browser, entity:field_config, entity:field_storage_config, entity:file, entity:filter_format, entity:image_style, entity:language_content_settings, entity:configurable_language, entity:metatag_defaults, entity:node, entity:node:article, entity:node:page, entity:node:projected_day, entity:node:worked_day, entity:node_type, entity:rdf_mapping, entity:redirect, entity:search_api_server, entity:search_api_index, entity:search_api_task, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:slick, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user_role, entity:user, entity:userprotect_rule, entity:menu_link_content, entity:pathauto_pattern, entity:xmlsitemap, entity:view, entity:date_format, entity:base_field_override, entity:entity_form_display, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity_reference, timestamp, integer, language_reference, map, boolean, datetime_iso8601, list, any, language, duration_iso8601, string, email, timespan, float, uri, binary in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Drupal\Core\Plugin\DefaultPluginManager->getDefinition('entity:activity_type') (Line: 115)

I've encountered this issue after importing configuration from a folder in Drupal 8.7.5. I've managed to solve this problem by running drupal console commands drupal cr followed by drupal cr discovery. Hopefully this will help anyone.

I've also encountered this issue after upgrading to Drupal 8.7.5.

We encountered this issue as well after pulling & syncing a minor change to the 'syslogs' config.
The site was unreachable and drush ULI gave the errors above.

Running 'drush cr' from the command line fixed the issue.

UPDATE: continuing to have the same error anytime we clear the cache via the UI.

I have a similar issue, running drush cr leads to error:

The "ds_entity:taxonomy_term" plugin does not exist. Valid plugin IDs for D
rupal\views\Plugin\ViewsPluginManager are: aggregator_rss, comment_rss, ent
ity_reference_revisions, node_rss, entity:node, data_field, data_entity, se
arch_view, entity:user, rss_fields, fields, entity:aggregator_feed, entity:
aggregator_item, entity:block_content, entity:comment, entity:feeds_subscri
ption, entity:feeds_feed, entity:file, entity:media, entity:paragraphs_libr
ary_item, entity:shortcut, entity:taxonomy_term, entity:webform_submission,
entity:menu_link_content, entity:paragraph, entity_reference, opml_fields

After a lot of searching, I discovered that many of my problems were due to database conflicts resulting from having originally installed Drupal 8 via the drupal/project template using composer, but later updating individual modules using the UI. I had to go into the db and delete rows in the config table that had conflicting settings, in this case ds and ds_extras. Here was the SQL I used to find the offending entries, then I deleted the rows and re-enabled the modules:

SELECT * FROM `config` WHERE name LIKE '%ds.settings%'
SELECT * FROM `config` WHERE name LIKE '%ds_extras.settings%'

The errors about a missing plugin no longer tortures me.

We didn't encounter the issue just after updating to Drupal 8.7.5, but only recently. Also, the plugin in our case is "views_view:view.comment.page_published". Below is the exact error message

Uncaught PHP Exception Drupal\\Component\\Plugin\\Exception\\PluginNotFoundException: "The "views_view:view.comment.page_published" plugin does not exist

Users get this error intermittently on /admin/content page and as is the case with others, it goes off with a cache clear

In my case the issue is with Commerce payment gateways. It appears the Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php) function is picking up the payment gateway id instead of the plugin id used by the payment gateway.

When created a new payment gateway and gave it an id/name using one of the valid plugin IDs (Acceptjs in the attached is the only gateway with no issue), the error is gone.

Same persistent error after upgrading to drupal 8.7.8, the problem seems to be fixed after clearing the cache but returns after a while.

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "broken" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsHandlerManager are: "

Edited: after a while, error came out again

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "views_query" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: "

so annoying

Priority levels are documented. Please justify changes to critical.

I read the summary and all comments. It will be ideal if anyone can determine the steps to reproduce, beginning with “Install Drupal...”.

The OP’s original report is so interesting because different plugins are reported missing. I am interested to know the opcache configuration on affected sites.

I'm having the similar issue.
But instead of Drupal 8.7+, mine was drupal 8.6.16.

But the error didn't occur during core update, it's after I enabled a module (coincidentally it's feeds module I enabled).
Then the error shows.
Drupal\\Component\\Plugin\\Exception\\PluginNotFoundException: The "smallad_search" plugin does not exist.

The plugin that was "missing" is one of the module I uninstalled about 16 months ago.

I assume somewhere in the database the table still kept the uninstalled module config records.
And somehow Feeds module installation triggered it. (Could it be?)
As I've also enabled few modules on the same site without the error.

This doesn’t look Fixed

Thank you @ahimsauzi for pointing me in the right direction for the problem I was having with this. I have been using the Payment module without Commerce, and somehow ended up with an "Unavailable" method. I think what happened is that I was testing a new method and deleted content before deleting the method first. It seems that I can delete payment records directly in the database to fix the issue, although there's probably some other cleanup I need to do as well.

updating from 8.7.10 to 8.8.0 gives me similar error but for the filter module.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "filter_format" plugin does not exist. .....

Core Filter module is unchecked (not installed) whilst on 8.7.10 it was. Trying to enable this module gives error :

Unable to install Filter, filter.format.plain_text, filter.settings already exist in active configuration.

As admin I can acces the site but not all is working....

any clues?

In my case :
All the above patches were suppressing the fatal errors by providing a default class in case the actual class or handler were not reachable but again the reason behind the errors were still not known until , i checked my settings for drupal cache.
I am using varnish and with purge module. my drupal cache was set upto 30 min increasing the drupal cache time to 1 week removed the errors in my case.

I'm experiencing a similar error to #31. I've tried reinstalling and uninstalling the module with no luck. I have absolutely no clue how to proceed.

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

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "ace_filter" plugin does not exist. Valid plugin IDs for Drupal\filter\FilterPluginManager are: codemirror_editor, editor_file_reference, filter_html_image_secure, filter_url, filter_null, filter_html, filter_autop, filter_align, filter_caption, filter_htmlcorrector, filter_html_escape, linkit, media_embed in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I got some similar error messages in 2 times:
in the first time i got the error message: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "panels" plugin does not exist. Some steps i did (example: current version - panels 8.x-4.2, i don't remember exact version):
- composer require drupal/panels:4.3
- drush updb && drush cr
- composer require drupal/panels:4.4
- drush updb && drush cr
in the second time i got another error message: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "linkit" plugin does not exist.
- i did these steps above, i updated module via composer step by step and it worked properly.

Also updating from 8.7.10 to 8.8.0.

PluginNotFoundException: The "blazy_filter" plugin does not exist....

PluginNotFoundException: The "blazy_filter" plugin does not exist. Valid plugin IDs for Drupal\filter\FilterPluginManager are:            [error]
editor_file_reference, filter_html_image_secure, filter_url, filter_null, filter_html, filter_autop, filter_align, filter_caption, filter_htmlcorrector, filter_html_escape,
media_embed, php_code in docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53

I can't uninstall the module as it throws the same error. The solution in #28 didn't help me.

Whatever appears in the "plugin does not exist" error does not matter at all.

I can consistently reproduce this problem via pasting the following block at once in a terminal:

drush cr
drush eval "drupal_flush_all_caches();"
drush cr

I have the same problem on "comment plugin does not exist" after a fairly big import of config plus update from 8.7 to 8.8.
The problem disappears after either uninstalling and installing field_ui, or by issuing
drush cache-clear plugin
This is not meant any more for Drupal 8, but with drush 10 it works.
drush cache-rebuild
is supposed to clear the plugin cache anyway by calling drupal_rebuild().
My knowledge of what happens inside drupal_rebuild() is insufficient to evaluate if something is amiss there.
Is the plugin cache sufficiently cleared?

This keeps coming up for me and again now going onto D8.8.1

Please see #2061377: [drupalImage] Optionally apply image style to images uploaded in CKEditor 5 where this 8.8 patch #2061377-345: [drupalImage] Optionally apply image style to images uploaded in CKEditor 5 works for me.

I had a site crash earlier after installing that Develop Suite module which I couldn't fix and restarted a project.
This time the project was pretty advanced and after installing commerce 2 via composer (base) and extend (all submodules), I added some content and once I did a drush cr, crash again.

I tried deleting ds.settings, since Develop Suite gave me problems earlier (not anymore after installing on clean project).
Did not work.

But after trying #36, namely drush eval "drupal_flush_all_caches();" and then drush cr again, project works.
I can't say if the removal of ds.settings had anything to do with it, I'm still a beginner..
Also, the drupal flush gave me a code of 1, which in my understanding should be an error exit code, I don't know if parts of the script had something to do with resolving this issue. See attached printscreens.

I keep having this problem too out of sudden.
Current php using: 7.1.8
Tried 1) Installed a fresh Drupal 8.8.x, the error occurred after putting in DB connection details during the setup.
2) Duplicated an existing application (D8.7.9), failed to load the duplicated version. The same error occurred.

Please kindly help.

Uncaught PHP Exception Drupal\\Component\\Plugin\\Exception\\PluginNotFoundException: "The "field_item:string_long" plugin does not exist. Valid plugin IDs for Drupal\\Core\\TypedData\\TypedDataManager are: entity_revision_reference, entity_revision, entity_revision:block, entity_revision:block_content, entity_revision:block_content:basic, entity_revision:block_content_type, entity_revision:comment, entity_revision:comment:comment, entity_revision:comment_type, entity_revision:contact_form, entity_revision:contact_message, entity_revision:contact_message:feedback, entity_revision:contact_message:personal, entity_revision:content_moderation_state, entity_revision:editor, entity_revision:field_config, entity_revision:field_storage_config, ......

Same problem when trying to update webform to 8.x.5.5 to 8.x.5.6 on Drupal 8.7.10 site
Site is there but while trying to use any admin I get "The website encountered an unexpected error. Please try again later."

Error messages throw, "[04-Jan-2020 08:39:23 America/Los_Angeles] Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "SMTPMailSystem" plugin does not exist. Valid plugin IDs for Drupal\mailsystem\MailsystemManager are: webform_php_mail, php_mail, test_mail_collector" at /home/vrcfdru/public_html/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php line 53"

Updated Drupal 8.7.10 to 8.8.1 . So now i am not able to upload some file extensions like png, jpg, csv, xls etc Showing error
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity:file:undefined" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: formatted_price, entity_revision_reference, entity_revision, entity_revision:block, entity_revision:block_content, entity_revision:block_content:basic, entity_revision:block_content_type, entity_revision:comment, entity_revision:comment:comment, entity_revision:comment_type...

Please help

Thanks @eglaw for quick response.
Issue fixed by adding extensions in /admin/structure/file-types
Really Thanks.

Tried all things above.

Upgrading from Drupal 8.6.7 to 8.7.11.

Still facing

Post updating layout_discovery     [ok]
Failed: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "integer" plugin does not exist.

facing same problem (when adding field group for view form)

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "text" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FormatterPluginManager are: FieldAsLink_default, comment_default, comment_permalink, comment_username, datetime_time_ago, datetime_default, datetime_custom, datetime_plain, entity_reference_revisions_entity_view, file_filemime, file_url_plain, file_size, file_uri, file_link, file_video, file_rss_enclosure, file_extension, file_audio, file_table, file_default, fontawesome_icon_formatter, image, image_url, link, link_separate, oembed, media_thumbnail, metatag_empty_formatter, list_default, list_key, file_extracted_text, entity_reference_rss_category, text_default, text_summary_or_trimmed, text_trimmed, author, user_name, video_embed_field_video, video_embed_field_thumbnail, video_embed_field_lazyload, video_embed_field_colorbox, paragraph_summary, number_unformatted, language, uri_link, email_mailto, timestamp_ago, number_integer, timestamp, entity_reference_entity_id, string, basic_string, entity_reference_label, number_decimal, boolean, entity_reference_entity_view in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Drupal\Core\Plugin\DefaultPluginManager->getDefinition('text') (Line: 56)
....

in my case I had in custom entity

      $fields['annotation'] = BaseFieldDefinition::create('text_long')
      ->setLabel(t('Library annotation'))
      ->setDescription(t('Library annotation.'))
      ->setSettings(array(
        'default_value' => '',
        'text_processing' => 0,
      ))
      ->setDisplayOptions('view', array(
        'label' => 'inline',
        'type' => 'text',
        'weight' => -6,
      ))
      ->setDisplayOptions('form', array(
        'type' => 'text_format',
        'weight' => -6,
      ))
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', TRUE);

All worked fine untill adding field group, field was working
but to solve problem had to change

        'type' => 'text',

to

        'type' => 'text_default',

I updated my website from Drupal v8.7.10 to 8.7.11. I encountered a similar error when I checked the ‘recent log messages’ after the update and also every time I do ‘drush cr’. This error is causing issues while rendering two pages of my website.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "ds_entity:node" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: entity_reference_revisions, node_rss, entity:node, search_api, entity:user, rss_fields, fields, entity:block_content, entity:content_moderation_state, entity:crop, entity:entity_subqueue, entity:feeds_subscription, entity:feeds_feed, entity:file, entity:media, entity:paragraphs_library_item, entity:redirect, entity:search_api_task, entity:shortcut, entity:taxonomy_term, entity:tmgmt_job_item, entity:tmgmt_remote, entity:tmgmt_job, entity:tmgmt_message, entity:tmgmt_local_task_item, entity:tmgmt_local_task, entity:webform_submission, entity:menu_link_content, entity:paragraph, entity_reference, opml_fields in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition()

I have Drupal 8.8.1 it was running correctly, but suddenly I got the next message:
----------------------------------------------------------------------------------------------------------------------------------------------------------
The website encountered an unexpected error. Please try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "field_item:language" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, email, uri, map, any, list, timestamp, duration_iso8601, integer, datetime_iso8601, timespan, language_reference, string, float, language, binary, boolean, entity, entity:block, entity:block_content, entity:block_content:basic, entity:block_content_type, entity:comment_type, entity:comment, entity:comment:comment, entity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter_format, entity:image_style, entity:node_type, entity:node, entity:node:article, entity:node:page, entity:path_alias, entity:rdf_mapping, entity:search_page, entity:shortcut, entity:shortcut:default, entity:shortcut_set, entity:action, entity:menu, entity:taxonomy_term, entity:taxonomy_term:tags, entity:taxonomy_vocabulary, entity:tour, entity:user_role, entity:user, entity:menu_link_content, entity:menu_link_content:menu_link_content, entity:view, entity:base_field_override, entity:entity_view_mode, entity:entity_form_mode, entity:entity_form_display, entity:entity_view_display, entity:date_format, entity_reference in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Drupal\Core\Plugin\DefaultPluginManager->getDefinition('field_item:language') (Line: 248)
...
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
----------------------------------------------------------------------------------------------------------------------------------------------------------

The only thing I remember was changing the size of the font for the menu navigation of my site, using the Appearance menu, and then suddenly my site is not working anymore.

My server is runnign PHP 7.1, Mariadb 5.5.64, Apache 2, Centos 7, .

I just hit this too, a colleague pushed up some new config to content type display modes, which seems to bust my environment.
investigating.

I was getting:

The "image_scale" plugin does not exist. Valid plugin IDs for Drupal\image\ImageEffectManager are: (/var/www/drupal8/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php içindeki 53). in Drupal\Component\Plugin\Exception\PluginNotFoundException: Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition()

Drupal 8.8.2 were my version. Somehow my image effects were messed up. They were not even being displayed in effects lists when I tried to add a new image style. Stock image styles were impossible to edit. So installing image_effects module seemed to solve the problem:

composer require drupal/image_effects:^3.0

But when I flushed the caches the problem came back.

This is the biggest problem I have using Drupal. Surely with so many affected, someone can provide a full description of how to fix this. Uninstalling and reinstalling the module in question never works for me.

I found out why I was getting this error.

My Mysql server config and client config was incorrect.

When using Drupal the max_allowed_packet memory limit setting should be increased

#default setting is:
max_allowed_packet=16M

#should be changed to:
max_allowed_packet=32M

if this setting is incorrect, nasty things can happen. the default value is too low for Drupal 7 or Drupal 8.

Same problem here with commerce_stripe module.

The following fix doesn't work:
- uninstall/reinstall module
- drush cr
- Removing "vendor" and reinstalling it
- change max_allowed_packet from 16 to 32

The following command fixed the problem:
- drush eval "drupal_flush_all_caches();"

Definately keep your mysql conf for max_allowed_packet at 32M

that's the first time I've seen eval used this way, nice, I'll try it some time.

drush eval "drupal_flush_all_caches();"

I wonder why that would work where drush cr would not? Maybe you needed to drush cc drush and then drush cr
the max_allowed_packet setting change probably is what helped you out the most.

The solution in #54 worked for me as well.

For yamlform module related issue, it was fixed by updating yamlform module and composer update

I have encountered this issue as well on Drupal 8.8.4, PHP 7.3.16 and MySQL 5.7.25.

The scenario was, I enabled the Address module, did some site building on my content type with an Address field, filled up the field in a node, viewed the node page and everything was alright. I cleared caches and the error came up. I'm not sure what's going on as well.

The solution in #54 regarding `drush eval "drupal_flush_all_caches();"` worked for me.

Thank you very much!

For me it is: The "excel_export" plugin does not exist.

The following fix doesn't work:
- couldn't uninstall/reinstall module because of the error
- change max_allowed_packet from 16 to 32
- drush eval "drupal_flush_all_caches();"

The error seems there only when flushing the caches

"excel_export" plugin does not exist: I solved this by removing manually all view display using this plugin in th exported config of the views.
After that I could re-import the views and the problem was solved (with missing display)

Hi,

I've this issue too after I updated modules via composer.

[error] The "comment_username" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FormatterPluginManager are: ad_manager_ad_amp_formatter, ad_manager_ad_formatter, address_zone_default, address_plain, address_default, address_country_default, blazy, blazy_media, buzzlike_quiz_formatter, buzzlike_poll_formatter, color_field_formatter_text, color_field_formatter_swatch, color_field_formatter_swatch_options, color_field_formatter_css, datetime_time_ago, datetime_custom, datetime_default, datetime_plain, entity_reference_revisions_entity_view, file_size, file_link, file_table, file_video, file_url_plain, file_default, file_rss_enclosure, file_filemime, file_extension, file_uri, file_audio, image_url, image, image_title_caption, instagram_embed_formatter, instagram_amp_embed_formatter, link_separate, link, metatag_empty_formatter, list_key, list_default, redirect_source, slick_image, slick_text, entity_reference_rss_category, text_default, text_summary_or_trimmed, text_trimmed, twitter_amp_embedded_tweet_formatter, twitter_embedded_tweet_formatter, author, user_name, video_embed_field_lazyload, video_embed_field_colorbox, video_embed_field_thumbnail, video_embed_field_video, paragraph_summary, string, timestamp_ago, entity_reference_entity_id, uri_link, number_integer, entity_reference_entity_view, language, number_unformatted, timestamp, number_decimal, email_mailto, basic_string, entity_reference_label, boolean
[error] Update failed: views_post_update_limit_operator_defaults
[error] Update aborted by: views_post_update_limit_operator_defaults
[error] Finished performing updates.

I did a 'DELETE FROM config WHERE data LIKE %contenthub_filter%'; when my problem occurred when upgrading from CH 1.x to 2.x and my configuration for the REST module was using the 'contenthub_filter' plugin. I assume you could just search the config for the plugin ID and remove the offending rows, then config-import again from a known config.

Worked for me.

#36 fixed for me!
Thanks so much!

I'm getting this when installing from config in 8.8.x. Clearing the caches isn't an option for me because the error is occurring on the pipelines build.

[info] Executing: mysql --defaults-file=/tmp/drush_7KTq7A --database=drupal --host=127.0.0.1 --port=3306 --silent -A < /tmp/drush_8NWUMm

 [info] Installing from existing config at /mnt/tmp/local.prod/source/docroot/../config/default
 [notice] Starting Drupal installation. This takes a while.

In DiscoveryTrait.php line 53:
                                                                               
  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                  
  The "field_item:list_string" plugin does not exist. Valid plugin IDs for Dr  
  upal\Core\TypedData\TypedDataManager are: entity, entity:field_storage_conf  
  ig, entity:field_config, entity:lighting_display, entity:lighting_slot, ent  
  ity:menu, entity:action, entity:user, entity:user_role, entity:entity_form_  
  mode, entity:entity_view_mode, entity:entity_form_display, entity:entity_vi  
  ew_display, entity:date_format, entity:base_field_override, entity_referenc  
  e, field_item:block_field, field_item:created, field_item:email, field_item  
  :boolean, field_item:language, field_item:map, field_item:timestamp, field_  

  item:integer, field_item:entity_reference, field_item:string_long, field_it  
  em:float, field_item:changed, field_item:uuid, field_item:password, field_i  
  tem:string, field_item:decimal, field_item:uri, binary, string, timestamp,   
  map, integer, timespan, list, uri, duration_iso8601, datetime_iso8601, lang  
  uage, float, email, boolean, any, language_reference                         

field_item:list_string seems to exist in core, so I can't understand why it wouldn't be able to find it. Is the core config not being included in the installation?

I've seen this issue when a layout plugin was renamed. The error was:

 [error]  Drupal\Core\Config\ConfigException: Errors occurred during import in Drush\Drupal\Commands\config\ConfigImportCommands->doImport() (line 245 of /var/www/drupalvm/drupal/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php).

  The import failed due to the following reasons:
  Unexpected error during import with operation update for core.entity_view_display.block_content.mycustomtype.default: The "pattern_lab_layout:slider" plugin does not exist. Valid plugin IDs for Drupa
  l\Core\Layout\LayoutPluginManager are: layout_twocol_section, layout_threecol_section...

I updated the description of this ticket to add a temporary workaround that I found, but it doesn't solve the issue.

I get this error frequently right after dropping all tables and reloading a dump file then immediately without warming any caches or visiting /logging into the site, I start importing data using a script, then this exception comes up.

The solution for me in this situation is to after dropping tables and reloading from my dump file (due to code change/testing import script) is to after reloading the db is to log into the website. Sometimes actually have to create a bogus piece of content, but usually just logging in does it. then after this, my script usually works without errors from that point on.

or rather than reload again, cache rebuild , then log in, do some light task or two, then it usually wakes up this way too.

for certain tasks, it seems that some caches need to be populated first before executing. I haven't gone into detail with this otherwise.

I am hitting this issue on NEW project. We are building out on Drupal 8.8.4. The project uses a full config dump that is imported locally and during CI as part of a site install. For us, we are trying to add and enable the address module. Once config is exported with the necessary core.extension, field, and entity config updates (yes, valid config) when our CI attempts to run and import this config, we get a failure because of:

In FieldStorageConfigStorage.php line 174:
                                                                               
  Unable to determine class for field type 'address' found in the 'field.stor  
  age.node.field_test_address' configuration                                   
                                                                               

In DiscoveryTrait.php line 53:
                                                                               
  The "address" plugin does not exist. Valid plugin IDs for Drupal\Core\Field  
  \FieldTypePluginManager are: contact_storage_options_email, datetime, dater  
  ange, dynamic_entity_reference, entity_reference_revisions, file_uri, file,  
   image, layout_section, link, metatag, list_float, list_string, list_intege  
  r, path, redirect_source, telephone, text_with_summary, text, text_long, vi  
  deo_embed_field, webform, integer, uri, entity_reference, uuid, float, emai  
  l, timestamp, string, language, created, changed, map, string_long, passwor  
  d, decimal, boolean                                                          
                             

As some others in the chain have suggested, visiting the site in a browser (a few times) then ultimately doing a drush cr results in a working site. From what I see in the output during these attempts, I see multiple contrib plugins (including address, webform_submission, etc.) throw the same error. Then, as if all the plugins have been discovered and registered properly, THEN the site will bootstrap and load. It seems like something related to the entity installation / creation process in 8.8 is not properly registering plugins when drush commands (site install, cr, etc.) are run ONLY when the site is bootstraped via a browser?

To reproduce:

1. install a site with core 8.8.4
2. do a site install, export config
3. add the address module
4. enable the address module
5. add a single address field to a content bundle (i did basic page)
6. export configuration
7. re-install the site
8. run a drush config-import from the config dump

We also see this issue when NOT doing a clean install + config import, but taking a database for the site from one of our cloud environments and attempting to do a config import to enable the address module + import the necessary config for the new fields.

FYI this may be related to https://www.drupal.org/node/3034742.

In my case, I am enabling a module (via core.extensions) AND attempting to import config that places field / entity changes related to that module (and its plugins). If I add an update hook to a module to enable a module before the config import runs, THEN flush the cache, THEN do a config import (that places the necessary field config) I do not get these errors.

I'm guessing that something related to config imports that no longer allows all of those steps to be executed simultaneously in a single config import step. Just a guess based on what I'm seeing with just a config only change and a config + install / update hook change. Also, potentially related to https://www.drupal.org/node/3066005

FYI downgrading to drush 9.7.2 from drush 10.2.2 seems to stop the errors from happening. Continuing to dig into what's going on there.

Core 8.8.4 + Drush 9.7.2 seems to work.

Updating to Core 8.8.5 with Drush 10.2.2 "works" but I do have some issues with other modules. Specifically, the Google Tag module starts to throw:

In EntityTypeManager.php line 150:
                                                          
  The "google_tag_container" entity type does not exist. 

Updating to the current head of drush 10 (so that https://github.com/drush-ops/drush/issues/4350 is merged) seems to work across the board.

I'm not sure how strictly related https://www.drupal.org/project/drupal/issues/3119373 is, but the Drush issue links to it and that's what prompted me to update to Core 8.8.5. This issue "may" be fixed via this other issues?

i've stumbled across this issue.. i have been having a similar 'plugin missing' notice. i have found that truncating the cache_discovery table triggers a rebuild - this error goes away, until something does, once again create the error. have had this happen in my project over last 4months..

5 hours to figure out:

Unable to determine class for field type 'simplenews_issue' found in the 'field.storage.node.simplenews_issue' configuration

In this situation, it was a rogue module that was added and installed through a patch: "simplenews_rules", then later removed but apparantly not properly uninstalled? No idea... Since we CAN'T DISABLE modules anymore, it takes forever to track these kinds of problems down now-a-days.

I just love how fragile Drupal 8 is. It's by far, the biggest "software baby" I've ever had to deal with.

The first reports of this error started with 8.7.x
I am wondering if this fragility was introduced in 8.7.x ?

#71 - I've wondered that myself.

Anybody has multi-site application or modules placed in sub-directories. this patch worked for me.
https://www.drupal.org/files/issues/2018-07-11/specify_sitepath_cache_re...

#79
what issue is that patch from? can you relink to it please?

--
My project is (was, now off that project..) a Multisite setup (running custom profile) and does have nested module folders..

@skaught, its this issue: https://www.drupal.org/node/2985199

the number is usually in the patch.

I also have had multiple times this plugin error on config import. I have been trying to import group_content:xyz plugin config from the group module.

What I can say to help narrow down the issue is that drush cim triggers the error, resulting in the crash, letting the site totally stuck with blank page, even if I drush cr... unless I access the cache flush link from the browser, the one which is available in the extended admin toolbar (starting with /admin/flush?token=tokenhere).

Core 8.8.3
Drush 10.2.2

#79 saved my day (multisite install), I used this patch: https://www.drupal.org/project/drupal/issues/2985199#comment-13286385

#2985199: Extensions in Multisite Directories Not Registered When Rebuilding Cache

Interesing. I just uploaded a site i developed locally to a server. All files+db. Directly WSOD.
Ok drush, the drush cr. Also doesn twork because of

Unable to determine class for field type 'list_integer' found in the 'field.storage.node.field_ausstattung' configuration 
The "list_integer" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\FieldTypePluginManager are: asin, comment, computed_string_long, computed_float, computed_string, computed_decimal, computed_integer, datetime, entity_  
  reference_revisions, file, file_uri, fontawesome_icon, image, layout_section, link, metatag, list_string, list_float, path, redirect_source, starrating, text_long, text_with_summary, text, webform, yoast_seo, entity_reference, float  
  , decimal, changed, map, integer, uri, timestamp, string_long, language, created, email, string, uuid, password, boolean             

That is a standard core field and not listed. Also using a multisite but i have no modules in the subdirs for the domains.

Drupal 8.9.1
Drush: 10.2.2
php 7.2.3

Solution
Edit. This is a cache problem.
Drush 9.7.2 works with a php 7.2.3 installed, then drush cr will work!
Truncating cache_* tables by hand was not enough

as mentioned below by DamienMckenna try adding this core patch to your composer.json
#3126063-30: Harden SubProcess process plugin

OR, apply the patch manually.

Please try out this issue to see if it fixes the problem: #3126063: Harden SubProcess process plugin

I ran a composer update today to pull in core 8.9.3 and a bunch of other contrib updates. After the update, I ran into this error and chased it all over the place.

Finally I discovered that, why yes, the plugin in question _was_ actually missing. One of the contrib modules (salesforce) had changed its composer.json so that a couple of dependencies were moved from "require" to "suggest"; and then a sub-module (salesforce_mapping) had added those same dependencies as "require". For whatever reason, composer didn't pick up on this and the dependencies were removed. So in my case, dynamic_entity_reference really was missing and causing the error.

So...one possible troubleshooting path for this error is to look at which plugin the PluginNotFoundException is naming and verify that the module that provides it hasn't gone awol.

drush en computed_field; drush cr; worked for me.

I also had to reenable my theme too drush en THEME

Hallelujah!

Question: Does this occur when you install a module and then uninstall the module via composer, but perhaps it has not uninstalled the module properly.

So, I'm seeing this same error in my logs for the contact_form module, which we are no longer using. How can I tell Drupal that it is gone since it has been removed already. It hasn't been on the site for about 6 months.

I just ran into this issue again on a live site when logging in as an admin and going to /admin/content. The error was:

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "views_view:view.comment.page_published" plugin does not exist.

To the best of my knowledge, nothing has been altered in the last 24 hrs on the site that would have caused this issue.

I ran a cache rebuild and the issue was resolved. I've updated the description to include this temporary workaround, and the temporary workaround I had used previously for a different (but similar) error on this thread.

ya confirmed, still an issue, I'm using the patch in #3126063: Harden SubProcess process plugin
however still same thing pops up when I'm running drush scripts creating content by script after taking a dump file from one filesystem to another and loading that dump file, cache rebuild isn't enough in this case, I have to go manually create and delete the same type of node via the web interface otherwise my script throws the plugin not found exception

Hi Guys,

For those who have the same problem. In my case, the problem was related to multilingue experimental module which have been disabled with the new update of 8.9.6. So pay attention if any of your module use this experimental module as required you have to remove this requirement. Drupal added automatically this module in his core.

Baher

Thanks to everyone, I went through all the above comments and tried everything and the problem was persisted.

My problem belongs to a plugin from the `Webform_ui` module, However, I end up fixing using the following drush command, Which will call the Core user data service and delete the user data for that particular module.

drush php-eval "\Drupal::service('user.data')->delete('webform_ui', NULL, NULL);"

So if it's a views plugin causing the problem, you can try the following

drush php-eval "\Drupal::service('user.data')->delete('views', NULL, NULL);"

Then I ran drush cr too. This fixed my problem, Hope it helps someone. Thanks again.

Writing in to report that I just ran into this issue. Here were the steps I took:
1. Edit the form display for an Order Item Type
2. Move a field from hidden to displayed
3. Click save
4. Observe the following error:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "hidden" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\WidgetPluginManager are: (insert very long list here) in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php). 

A cache rebuild did not resolve the issue. I closed the browser tab, opened a new tab, repeated the exact same steps and it worked. I'm wondering if I did steps 2 and 3 too quickly and there was some JavaScript or AJAX running that didn't complete before I went to save. Hopefully, this example might help build a better picture of the nature of these types of issues.

This hasn't occured to me on my local dev (macos + lando) running 8.9.11, but kept occuring when trying to restore a database dump using backup_migrate on an ubuntu server I had spun up to act as a test server for others to hit.

drush eval "drupal_flush_all_caches();" worked to clear things up enough to get into the site, but my restore failed. After being left with a halfway restored but semi-functional site I ran backup/migrate again and it went cleanly and the site works great. Sadly I had adjusted mariadb to use max_allowed_packet=64M around the same time, fuddling things up a bit in terms of what the fix was.

Seems like it could definitely be environment dependent as I'm running the same composer.json to build the site. If it doesn't recur on my server it'd be likely that the db packet size configuration change fixes the issue (whilst the drush command gets you past it), and something in 8.7 has you hit edge cases where that packet size setting matters a bit more.

You can diff the output of phpinfo() (found also at admin/reports/status) from each platform to nail down the PHP platform differences precisely. I have done this any time evidence points to subtle environmental differences.

A production website just experienced the WSOD at /admin/content due to this issue. The specific exception was:

> PluginNotFoundException: "The "views_view:view.comment.page_published" plugin does not exist.

After a cache rebuild the page became available again. Does anyone have hints as to what might cause this issue?

I have seen The « » entity type does not exist. (empty « »)

The bug was painful to backtrace since it would occur randomly 1 time/month.

Long story short:
The site had a cron hook running drupal_flush_all_caches() once a day only, after a batch of entity update.
For performance reasons, the batch was using db->update query,
which had occasionally created a `Serialization failure: 1213 Deadlock`, leading to
The « » entity type does not exist.

Since drupal_flush_all_caches() was removed from hook_cron, no more `Serialization failure: 1213 Deadlock` occurred, nor The « » entity type does not exist.

I'm having this problem when i try to host my site in a test server, how can i solve it???

I'm using drupal 9

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. Valid plugin IDs for Drupal\Core\ImageToolkit\ImageToolkitManager are: gd in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I seem to be having a subset of this issues as well:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity:paragraph:" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: ...

I'm seeing this on install of 9.1 on a hosted server. Works fine on my dev, but after DB is created and before prompt for admin details.
Code was built from git clone of a simple build then composer install (which gets drupal core etc).
PHP 7.3.

(https://myserver.com/core/install.php?rewrite=ok&langcode=en&profile=sta...)

I'm getting: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "tag" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

drush watchdog-show is:

 65   24/Dec 11:18   php      Error      Drupal\Component\Plugin\Exception\PluginNotFoundException:  
                                          The "tag" plugin does not exist. Valid plugin IDs for       
                                          Drupal\views\Plugin\ViewsPluginManager are:  in             
                                          Drupal\Core\Plugin\DefaultP                                 
  63   24/Dec 11:18   system   Info       seven theme installed.                                      
  61   24/Dec 11:18   system   Info       bartik theme installed.                                     
  59   24/Dec 11:18   system   Info       toolbar module installed.                                   
  57   24/Dec 11:18   system   Info       quickedit module installed.                                 
  55   24/Dec 11:18   system   Info       path module installed.                                      
  53   24/Dec 11:18   system   Info       menu_ui module installed.                                   
  51   24/Dec 11:18   system   Info       menu_link_content module installed. 

After this trying to refresh install page results in same error on screen and in log

I had seen this once after upgrading to 8.9.9 for a different application with same hoster, but clearing cache seemed to fix.

I believe the tag plugin is at core/modules/views/src/Plugin/views/cache/ and I have
-rw-r--r-- 1 jon jon 6020 Dec 2 18:11 Time.php
-rw-r--r-- 1 jon jon 765 Dec 2 18:11 Tag.php
-rw-r--r-- 1 jon jon 764 Dec 2 18:11 None.php
-rw-r--r-- 1 jon jon 11134 Dec 2 18:11 CachePluginBase.php
which is same as my dev
This is a very simple plugin 'Simple caching of query results for Views displays.'

This new install of Drupal uses the extra directory level - ie xxx/web/core rather than xxx/core - dont know if this makes a difference in some scenarios

I noticed that composer require xxx was taking a very long time and being 'Killed' or running out of RAM (at 1.2Gb).
So I asked the hoster to change to composer 2. composer require then worked as it should and somehow the missing tag plugin error went away too. I diffed a slightly older copy of the vendor directory with the current and there were quite a few changes, so it could be that the autoloader code is better for my hoster environment. I'd love to understand this!

@Jons, FWIW I was using 8.9 locally and on a VPS with the newer /web/* structure and only encountered the issue on my host. Was using Composer 2 in both places, though with a swap file to give it a bit more breathing room on the server. I haven't had it come back since changing max_allowed_packet=64M - will chime in again if it does.

Thanks @erutan. just to be sure - are you changing max_allowed_packet in the server mysql - or in a client-side setting?
BTW My host server is saying I have 256M max_allowed_packet

FWIW I had this issue a few months ago and I can't remember the exact steps i took but i am almost certain it was memory based. So yeah changing max_allowed_packet might work or just increasing the memory php can use/has.
For me I had to change my host because I couldn't change my memory limit on shared hosting. After a switch to a better provider i was able to add more memory and fix the issue. I also ran into the issue on my local lando install, which makes sense because that's constrained too.

solved the problem, certain packages of the php version I was using were not installed

I have the same error.
Does not affect any functionality but it kind of fills the terminal. This started to happen when upgrading to Drupal ^8.7.11. Also, I have no custom block.

lia@lia docroot % ../vendor/drush/drush/drush en -y custom_module
 [error]  Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Custom block type. 
 [error]  Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Custom block type. 
 [error]  Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Custom block type. 
 [error]  Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Custom block type. 
 [success] Successfully enabled: custom_module

@jons Both. :)

I'm not sure that's correct or optimal, I have never dug into MySQL configuration in any depth though I'm comfortable being an amateur sysadmin.

On Ubuntu this is the relevant part of my /etc/mysql/my.cnf. The rest of is just comments explaining import/read order of other config files and said imports:

#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

max_allowed_packet=64M

I've encountered this again which happens to have been after upgrading to 9.1.4.

Deleting vendor and then doing composer install (composer 2) has not helped, nor clearing caches, nor trying php versions 7.3, 7.4, and my max_allowed_packet is 256M
- so several critical functions fail with same basic error in the ViewsPluginManager:
taxonomy pages (for instance, taxonomy/term/33)
any view pages in edit mode /admin/structure/views/view/block_content
content list page /admin/content
user list page /admin/people

A key point is that the error line shows that the plugin definitions simply have not been loaded. The XXX below is actually empty in the error line and is where the list of plugins is supposed to be shown, so something is failing to load the plugins, or clearing the array after load.
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "tag" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: XXX in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

OK - the problem is connected with composer.
I debugged the views:cache creation process on my dev, which was working, down a huge numbers of layers of code (OO simplifies?) to work out what is supposed to happen. I also used a custom cache view program. This showed that after a cache-clear (so the cache build process had to run - and which failed on prod) the cache data for cid='views:cache' was:
Array()

when it should have been:

Array (
    [tag] => Array (
            [parent] => parent
            [plugin_type] => cache

etc

The required cache plugin files were present and as it was an empty array (rather than no array) it may be that the array elements were built then removed in DefaultPluginManager findDefinitions() (extractProviderFromDefinitions()) - which happens if related modules are not detected.

Before I got to the point of verifying this, I deleted the core directory (where I'd deleted just vendor before) and did composer install. This rebuilt the core directory tree and the problem disappeared. So something in the earlier composer install, maybe something in the autoload processing had failed in an un-obvious way.
It might be useful to find a way to detect these kinds of errors, some kind of check diagnostic, as the failures are painful to find especially in a prod environment.

for those that keep hitting this, a workaround that I have to do to resolve this is to log into Drupal using the web user interface and create a node, save it, then delete it.
then after this, my script will work without the plugin not found exception

Possibly also need to run php -r "opcache_reset();"

@joseph.olstad It sounds like your issue may be different to mine - in that it seems that your node create is forcing a plugin build (to cache) one way which is then used by others (as you suggested earlier). Does it fail again if you clear all caches?

I usually see this error after restoring a DB dump from another copy of the site

usually I see this error when running drush

perhaps the version of php used on the command line isn't the same as the server version or there's something different about that, maybe opcache issue, but resetting opcache didn't seem to solve it but should help , workaround like I said was to log into drupal web ui , create a node or menu link then save and then delete the newly created node or menu link.
usually just adding a node and deleting it wakes up the system enough for my scripts to run (import scripts)

I'm wondering something. If we are restoring from another environment database, it means that the plugins may be different from the ones on the target environment. This means that the plugin classes collection must be refreshed. Is this not a symfony related thing, about the apc cache or something?

Sometimes, when I'm stuck into weird edge cases, I have to change the deployment_identifier in the settings file to circumvent the cache mechanisms to help deploying configurations. Could it be a starting point for figuring out a solution, for this specific edge case?

We ran into this after a deploy (to production). The site 500'ed and drush and the log were throwing all kinds of errors, seemingly about random modules, all similar to this:

Got error 'PHP message: Drupal\\Component\\Plugin\\Exception\\PluginNotFoundException: The "webform" entity type does not exist.

Sure enough, drush cr discovery from all the way back up in #14 resolved it immediately!

I'm. . .
wow.
i'm going to bed now.

#54, works fine.
drush eval "drupal_flush_all_caches();"
Thank you,

drush eval "drupal_flush_all_caches();" solves it for me until I clear caches in the Drupal UI again, which fails with the described error.

In my case "max_allowed_packet" is 1024MB so that's not the problem here (you can check this by the SQL Command: SHOW VARIABLES LIKE '%max_allowed_packet%' ).

Anyway I'm having the same problems as @Jons with composer as the Hoster limits PHP to 512M which is quite a lot, but composer uses even more so the server kills the process. I guess that breaks code... any ideas for that?

Same issue here Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity:custom entity" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are
Running 8.9.18 now. I can not really figure out how to go about debugging this one. I've never had problems with prod but lately this seems to be very shaky :(

@ichionid suggest you try my fix at #113 or anything that forces the code to be rebuilt that may be cached somewhere (including composer, vendor as well as Drupal). Use composer v2.

I had this for "product_variation plugin" on drush updb after updating commerce_recurring and commerce.
Installing "Commerce Product" resolved the issue.
I was then able to run drush updb successfully.

Error I received:
Failed: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "product_variation" plugin does not [error]
exist. Valid plugin IDs for Drupal\commerce_recurring\SubscriptionTypeManager are: standalone in
Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of
/var/www/mysite.com/drupal/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php)

Adding to local.settings.php

$settings['class_loader_auto_detect'] = FALSE;

I'm really sorry that so many people are having this issue, and that the plugin system isn't being more helpful about debugging this.
But without repeatable steps to reproduce the bug, it's impossible to figure out what the underlying bug actually is.

This is already tagged appropriately, fixing the category and moving to the latest version.

Tried #19 but the errors are still there.

I'm also experiencing this issue on a D7 to 9 migration site. If we wind up migrating the site, I'll rework the migration to run it step-by-step with Drush, and try to isolate when the issue crops up. (The first pass, we just used the /upgrade approach, and that had an issue after several hours).

I have this issue again with a core module, not contribs. This does not allow me to override image.settings variables in the settings.php at all. Neither can i import a modified image.settings.yml.

1. drush cex -y
2. Edit the image.settinsh file just changed default picture path
3. drush cim

Error:
[warning] Undefined array key "class" TypedConfigManager.php:363
[error] Drupal\Core\Config\ConfigException: Errors occurred during import in Drush\Drupal\Commands\config\ConfigImportCommands->doImport() (line 343 of /srv/http/WORKSPACE_DRUPAL/Drupal9/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php).
The import failed due to the following reasons:
.. image.settings: The "image.settings" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedData
Manager are: entity_revision, entity_revision:block, entity_revision:block_content, entity_revision:block_content:b
...only entity*. something

I wonder how i could debug that. I have modified and imported other configs like views that worked perfectly.

I found something that seems suspicious, here is an xdebug screenshot: http://www.root.artwaves.de/sharex/19-11-21--22-15-36.jpg
Somehow the $definition['class'] is not set but $definition['definition_class'] is there and the code like this sees Undefined::class leading to an error.

Info: This is a site that once was D7 and has been migrated to D8 ->D9. So it is possible that there could be some data screwed up by the migration.

If you have any ideas or tips how i could xdebug this, i am up for it.

That's a different exception entirely. This is about PluginNotFoundException.
But that sounds like a valid bug, and you have the steps... can you open a new dedicated issue?
Thanks!

Ah ok, thank you. I will open a new issue.
#3250497: Undefined array key "class" TypedConfigManager - The "image.settings" plugin does not exist

I had a similar Drupal\Component\Plugin\Exception\PluginNotFoundException error.
I used "composer update" and it worked for me.

I had similar error but with Plugin "update_product_stock". I have exported all config, see which file was producing the error and (I this case) whas a custom config file o I delete it and worked !

Sometimes the reason is also that an abandoned plugin, like "php" for example is still present in configs. In that case, export the configs, search for related code, KNOW WHAT YOU'RE DOING, remove the references and re-import the config.

EXPERTS ONLY ;)
Mostly due to missing dependency listings from Drupals history, I guess...

@Anybody I have exact that problem trying to uninstall PHP Module.
Could you explain your process a little bit more in detail? Thanks in advance.

@nojj as written above, this is only for experts and may break your Project. So definitely create (tested) backups and first read about the different topics to understand what you're doing.

1. Use drush or configuration export (admin/config/development/configuration) to export your whole configuration, e.g. drush cex
2. Use an IDE with the ability to search file content to search for "php" within the exported config .yml files
3. Manually check the lines with "php" in it, if it's related to the php module and eventually remove the lines
4. Re-import the config using config import (admin/config/development/configuration) or drush cim (overwrite the existing files in your config export folder)

Please use documentation and other sources to learn about Drupal Config first. I can't give all that information here.

@Anybody:
thank You very much. Helps me a lot!

Crazy... in another project I got

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "media_bundle" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 150 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).

I exported the config and searched for "media_bundle" and it was in:

rabbit_hole.behavior_settings.media_bundle_document.yml:id: media_bundle_document
rabbit_hole.behavior_settings.media_bundle_document.yml:entity_type_id: media_bundle
rabbit_hole.behavior_settings.media_bundle_image.yml:id: media_bundle_image
rabbit_hole.behavior_settings.media_bundle_image.yml:entity_type_id: media_bundle
rabbit_hole.behavior_settings.media_bundle_slide.yml:id: media_bundle_slide
rabbit_hole.behavior_settings.media_bundle_slide.yml:entity_type_id: media_bundle
rabbit_hole.behavior_settings.media_bundle_video.yml:id: media_bundle_video
rabbit_hole.behavior_settings.media_bundle_video.yml:entity_type_id: media_bundle

Updating these entries solved the problem...

So it always seems by case, but typically is outdated config...

Perhaps core can help with hints and further details... no perfect idea yet.

I had the Drupal\Component\Plugin\Exception\PluginNotFoundException error also on D9.3.3.

I like the idea of hints and tips!

Any chance somebody tested patch of #3207813: ModuleHandler skips all hook implementations when invoked before the module files have been loaded? I suspect these plugin not found exceptions to have the same root cause as #3031598: The "paragraph" entity type did not specify a translation handler.

I get that error a lot with various modules. A lot of times. Now i am on php 8.1.2
This time i dont even get the plugins name just "". I can see that it has to do with facets.
I think disabling a setting "index hirarchy" caused this. Then i enabled it again but same error.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. Valid plugin IDs for Drupal\facets\Hierarchy\HierarchyPluginManager are: taxonomy in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (Zeile 53 in /srv/http/WORKSPACE_DRUPAL/EIGENE_PROJEKTE/PRODUCT_DISTRI_D9/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Maybe that helps anyone debugging in any way.

@casey
I applied the #3207813: ModuleHandler skips all hook implementations when invoked before the module files have been loaded patch (on Drupal 8.9.20) and the problem keeps reappearing. The patch did fix the Paragraph issue, but not this one…

UPDATE 1: I spoke too fast (I was looking at old error messages). I will update this comment when I know more…

UPDATE 2: After a few days, the problem has not reappreared, which makes me think that indeed, this patch solved it

Wow, this issue is still around. :D

I currently don't have a failing website which I can debug.

So I'm doing a code inspection by reading the API for possible failures which are masked by the PluginNotFoundException.

Let's start by the class where this exception is thrown: DiscoveryTrait::doGetDefinition(array $definitions, $plugin_id, $exception_on_invalid).

  /**
   * Gets a specific plugin definition.
   *
   * @param array $definitions
   *   An array of the available plugin definitions.
   * @param string $plugin_id
   *   A plugin id.
   * @param bool $exception_on_invalid
   *   If TRUE, an invalid plugin ID will cause an exception to be thrown; if
   *   FALSE, NULL will be returned.
   *
   * @return array|null
   *   A plugin definition, or NULL if the plugin ID is invalid and
   *   $exception_on_invalid is TRUE.
   *
   * @throws \Drupal\Component\Plugin\Exception\PluginNotFoundException
   *   Thrown if $plugin_id is invalid and $exception_on_invalid is TRUE.
   */
  protected function doGetDefinition(array $definitions, $plugin_id, $exception_on_invalid) {

    // Avoid using a ternary that would create a copy of the array.
    if (isset($definitions[$plugin_id])) {
      return $definitions[$plugin_id];
    }
    elseif (!$exception_on_invalid) {
      return NULL;
    }
    $valid_ids = implode(', ', array_keys($definitions));
    throw new PluginNotFoundException($plugin_id, sprintf('The "%s" plugin does not exist. Valid plugin IDs for %s are: %s', $plugin_id, static::class, $valid_ids));
  }

Fact: The only thing that could trigger the issue is an empty or not up-to-date definitions list given in the arguments.

The expected plugin list comes from DiscoveryTrait::getDefinitions(). This is an abstract function, with no PHPDoc (could be added for sure).

Let's dig into the DefaultPluginManager which overrides (implements) it. DefaultPluginManager is one of the many occurrences where the exception can be seen.

public function getDefinitions() {
  $definitions = $this
    ->getCachedDefinitions();
  if (!isset($definitions)) {
    $definitions = $this
      ->findDefinitions();
    $this
      ->setCachedDefinitions($definitions);
  }
  return $definitions;
}

Theory #1: The cached definitions are outdated

For some reason, during the config import, the plugin manager was never asked to refresh its plugin list, or it was asked too early so an expected config dependency on a new plugin could not be satisfied.

Or the plugin discovery failed silently, returning only the currently cached plugin list. For instance, this may happen in Drupal\Component\AnnotationPluginDiscovery\AnnotatedClassDiscovery::getDefinitions() if the doctrine annotation parser fails to read the new annotated plugin. A debug flag could be added in this function in the else path where this comment is located: // Store a NULL object, so the file is not reparsed again..

Theory #2: The plugins come from a new or removed module

If the definitions are not yet set in the cache, DefaultPluginManager::getDefinitions() tries to findDefinitions().

protected function findDefinitions() {
  $definitions = $this
    ->getDiscovery()
    ->getDefinitions();
  foreach ($definitions as $plugin_id => &$definition) {
    $this
      ->processDefinition($definition, $plugin_id);
  }
  $this
    ->alterDefinitions($definitions);

  // If this plugin was provided by a module that does not exist, remove the
  // plugin definition.
  foreach ($definitions as $plugin_id => $plugin_definition) {
    $provider = $this
      ->extractProviderFromDefinition($plugin_definition);
    if ($provider && !in_array($provider, [
      'core',
      'component',
    ]) && !$this
      ->providerExists($provider)) {
      unset($definitions[$plugin_id]);
    }
  }
  return $definitions;
}

providerExists($provider) calls the module handler to check for module status. If the module is not (yet) ready, the definition is removed.

Theory #3 (highly speculative): imported configs have circular dependencies

This could explain why cim + cr + cim works...

If it happens to you, can you check if the YAML config files have circular dependencies?

(Sorry for the long post.)

You can also cause this propblem with a broken custom config where you define some variables. I did that myself by accident :(

Hi !

I applied the same code form DefaultPluginManager::findDefinitions()

      foreach ($this->filters as $filter => $filter_definition) {
        $provider = $filter_definition['provider'];
        if ($provider && !in_array($provider, ['core', 'component']) && !\Drupal::service('module_handler')->moduleExists($provider)) {
          unset($this->filters[$filter]);
        }
      }

I think I am able to reproduce this issue on a clean install. I am trying to create a custom content entity whenever there is base field definition

BaseFieldDefinition::create('list_string')

it is causing error. I have created a test module for this issue to be reproducible. I am not facing this issue while accessing entity from UI but the issue is occurring when running phpunit tests.

I have attached phpunit test error log in this snippet.

    $fields['type'] = BaseFieldDefinition::create('list_string')
      ->setRevisionable(TRUE)
      ->setTranslatable(TRUE)
      ->setLabel(t('Type'))
      ->setDescription(t('The Type of the Movie or Series.'))
      ->setSettings([
        'allowed_values' => [
          'movie' => t('Movie'),
          'series' => t('Series'),
        ],
      ])
      ->setDisplayOptions('view', [
        'label' => 'above',
        'type' => 'list_default',
        'weight' => 28,
      ])
      ->setDisplayOptions('form', [
        'type' => 'options_select',
        'weight' => 28,
      ])
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', TRUE)
      ->setDefaultValue('movie');

The above field is causing following error .

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "field_item:list_string" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, entity, entity:block, entity:field_config, entity:field_storage_config, entity:filter_format, entity:node, entity:node_type, entity:omdb_api, entity:path_alias, entity:action, entity:menu, entity:user_role, entity:user, entity:view, entity:date_format, entity:entity_form_display, entity:entity_form_mode, entity:entity_view_display, entity:entity_view_mode, entity:base_field_override, entity_reference, field_item:text, field_item:text_long, field_item:text_with_summary, field_item:boolean, field_item:changed, field_item:created, field_item:decimal, field_item:email, field_item:entity_reference, field_item:float, field_item:integer, field_item:language, field_item:map, field_item:password, field_item:string, field_item:string_long, field_item:timestamp, field_item:uri, field_item:uuid, any, binary, boolean, datetime_iso8601, duration_iso8601, email, float, integer, list, language, language_reference, map, string, timespan, timestamp, uri

You can test this issue by enabling the following test module .

Steps to reproduce :

git clone --branch '8.x-dev' https://git.drupalcode.org/sandbox/Bhanu951-3103712.git example_codes

cd example_codes

git checkout -b test-3056633 4265f9ce565694b1e4ab4aa80afcc0df401a1906

or

git checkout 4265f9ce565694b1e4ab4aa80afcc0df401a1906

./vendor/bin/drush en omdb_api -y

php ./vendor/bin/phpunit web/modules/custom/example_codes/omdb_api

Edit:

This issue happened due to missing module options in tests setup. Once its added I no longer see the error.

Just to add to this mess. I have recently updated from D8.9 to D9.4. Now every time I en/pmu a module with drush i get:

[error] Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Workflow.

It doesnt matter what module it is. Also, my watchdog is flooded with these messages so i suspect en/pmu a module is not the only thing tripping this exception.

I have 1 Workflow (workflow field) defined and i resaved it. I also have a slew of Views which use the workflow field in them. I resaved all of those. None of this helped.

i removed the single workflow field and disabled the workflows module. I now get more errors:

[error] Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Workflow.
[error] Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Workflow.
[error] Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Role.
[error] Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Role.
[error] Drupal\Component\Plugin\Exception\PluginNotFoundException while computing Views data for entity: Role.

I think Tim mentioned this above.. but yes, certainly wouldnt hurt to have some information in this exception which gives some hint as to what the issue is. I also sort of get that this was changed to a "support request"; but certainly this is a bug.

Ok, ignore my comments. I though this was a core exception; but this is coming form the Config Views module. Likely just a bug there.

Hello,

Have have the same problem:
Drupal\Component\Plugin\Exception\PluginNotFoundException : Plugin ID 'menu_link_content:ec98d2fd-6c0d-421e-93c6-a5fe28588db4' was not found. dans Drupal\Core\Menu\MenuLinkManager->getDefinition() (ligne 206 de /home/user/web/mydomain/public_html/web/core/lib/Drupal/Core/Menu/MenuLinkManager.php).

I have try to:
Add in /etc/mysql/my.cnf

[client-server]
max_allowed_packet=64M

I have make a :

drush cr
drush eval "drupal_flush_all_caches();"
drush cr

Restart the server too.

No way, nothings seems to work :\

I will be resolved by clearing the plugin render cache. Thanks all !.

I hit this issue this week after updating to Drupal 10.0.7. Typical solutions such as running drush cr were failing with the error

In EntityTypeManager.php line 139:
The "XXX" entity type does not exist.

with XXX usually being date_format, but also user and others. I also tried truncating the cache tables by hand but that still didn't fix the issue.

Adding my fix (based on #113) for anyone who finds themselves here after Googling some error messages.

The only solution I could find was to delete the /vendor, /web/core and /web/modules/contrib folders and re running composer install. Once that was complete I could run drush cr succesfully.

Once that was done, the site was running again.

Obviously make sure you have backups and understand composer, etc before deleting folders in your install.

Same, I hit this issue this week

This issue is not just for filter plugins. So patch #147 is not going to solve the issue.

I have this issue when trying to add a new Action plugin. When trying to import the new system.action.my_action_id.yml config item, it can't find the plugin I created in my_module\src\Plugin\Action\MyAction.php

Clearing the cache didn't help, and attempting to reinstall the module runs into the same issue when it tries to import the config from my_module\config\install\.

I used this command to fix the issue
drush eval "drupal_flush_all_caches();"

That's no different than running drush cache:rebuild (drush cr), which didn't fix it for me.

Getting this while doing a feed import:

[error] Drupal\Component\Plugin\Exception\PluginNotFoundException: The "node_type" plugin does not exist. Valid plugin IDs for Drupal\Core\Condition\ConditionManager are: language, current_theme, request_path, user_role, webform, entity_bundle:block_content, entity_bundle:comment, entity_bundle:crop, entity_bundle:feeds_feed, entity_bundle:media, entity_bundle:node, entity_bundle:paragraph, entity_bundle:redirect, entity_bundle:shortcut, entity_bundle:taxonomy_term, entity_bundle:webform_submission, entity_bundle:menu_link_content in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /var/www/html/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Clearing cache does not help.

I suspect it is a specific issue with feeds. We WERE getting it with PathAuto, but they fixed their problem: https://www.drupal.org/project/pathauto/issues/2925169 and there is a similar issue here: https://www.drupal.org/project/ctools/issues/3300682

However, I just wish the traceback on the error actually told you where the problem is. As it stands, it's almost impossible to figure out where in the code we need to look in order to fix anything.

Edit: Yeah, it had nothing to do with feeds. The error was just reporting during that process because [reasons?]. The actual issue was: https://www.drupal.org/project/view_mode_page/issues/3300706

Thanks Anybody,
The comment (137) by Anybody provided the solution.

This was very frustrating.

I was upgrading a site from Drupal 9.5.9 to Drupal 10.0.9
No matter what I did, I kept getting the error below and WSOD on all content.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "node_type" plugin does not exist. Valid plugin IDs for Drupal\Core\Condition\ConditionManager are: current_theme, request_path, user_role, webform, entity_bundle:block_content, entity_bundle:contact_message, entity_bundle:media, entity_bundle:menu_link_content, entity_bundle:node, entity_bundle:shortcut, entity_bundle:taxonomy_term, entity_bundle:webform_submission, entity_bundle:paragraph in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of /Users/meuser/Sites/ost9/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I exported the config for the whole site.
I searched for "node_type".

There were 3 .yml files with "id node_type"

• menu_position.menu_position_rule.member_location.yml
• menu_position.menu_position_rule.news_item.yml
• user.role.admin.yml

I rolled back to original and got the site up again.

I uninstalled Menu Position 8.x-1.0
I uninstalled Automatic Entity Label 8.x-3.0

I did the upgrade again ----- this time success - upgraded to Drupal 10.0.9 with no errors!!

I reinstalled both modules and it still worked.

I exported the config from the upgraded Drupal 10.0.9 site.
I searched for "node_type".
There were no .yml files with "id node_type"

Hopefully this may help someone else.

I'm having this error on my drupal site when i Add a new payment area. Please help as I'm new to Drupal and don't have much expertise.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. Valid plugin IDs for Drupal\commerce\ConditionManager are: commerce_conditions_plus_and_operator, commerce_conditions_plus_or_operator, order_billing_address, order_currency, order_customer, order_customer_role, order_email, order_item_purchased_entity:commerce_product_variation, order_purchased_entity:commerce_product_variation, order_shipping_address, order_store, order_total_price, order_type, order_payment_gateway, order_item_product, order_item_product_category, order_item_product_type, order_item_variation_type, order_product, order_product_category, order_product_type, order_variation_type, order_item_quantity, shipment_address, shipment_quantity, shipment_weight in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
Drupal\Core\Plugin\DefaultPluginManager->getDefinition() (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 83)
Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 324)
Drupal\commerce_conditions_plus\Element\ConditionsTable::addNewCondition()
call_user_func_array() (Line: 114)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 595)
Drupal\Core\Form\FormBuilder->processForm() (Line: 323)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 23)
Stack\StackedHttpKernel->handle() (Line: 718)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I used config export drush cex and then researched "node_type" in config files with IDE.
In my case the asset injector module was throwing:

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "node_type" plugin does not exist. Valid plugin IDs for Drupal\Core\Condition\ConditionManager are: domain, language, current_theme, request_path, user_role, webform, entity_bundle:block_content, entity_bundle:comment, entity_bundle:contact_message, entity_bundle:media, entity_bundle:menu_link_content, entity_bundle:node, entity_bundle:shortcut, entity_bundle:taxonomy_term, entity_bundle:token_custom, entity_bundle:webform_submission, entity_bundle:paragraph" at ...\core\lib\Drupal\Component\Plugin\Discovery\DiscoveryTrait.php line 53

Probably JS scripts which were referencing to node_type.

UPDATE: just found out it's not code's fault, but the module itself. Before switching from D9.5 to D10 I noticed a duplicated section for content types - one is faulty in D10 node-type and the other newer one is bundlenode which is correct for D10. I had to manually insert records for the proper version and it started working.

EDIT: just change records in config files and reimport them.

This error came up for me because I'm trying to update to drupal 10 but removed some plugins from composer.json. I had to reinstall lightning_core to fix it.

It's hard to try and fix everyone's individual issues with this error. In a nutshell, your config files are referencing items which are available in plugins which are not installed.

To fix my issue, I had to install lightning_core

Use php debug or print out the entity variables in this file, to figure out which plugin's class is being requested.

docroot/core/lib/Drupal/Core/Entity/EntityTypeManager.php

getDefinition()

Looking at these variables will help you figure out which module to install.

This is my suggestion :
#3378101: Change PluginNotFoundException to an error message when not use the plugin

Only throw PluginNotFoundException when use it, other case show user an error message instead.

I was able to fix by the following steps:

1. Search for id: node_type in config directory.
2. Replace id: node_type with id: 'entity_bundle:node'
3. Run Drush cim.

Following the breadcrumbs, #164 helped me out. In my case, the culprit was pathauto. I was able to resolve the issue by uninstalling the module, exporting the config, re-installing the module, then recreating my one (fortunately) pattern. The only difference to the config yaml, other than the uuid values changing, was:

id: node_type was removed, and
id: 'entity_bundle:node' was added.

Now that I read this, #170 may have been a better route, and saved me the trouble of uninstalling, reinstalling, and recreating the alias pattern.

There are possibly similar issues elsewhere affecting other parts of the site than the filter system, e.g. #3354054: PluginNotFoundException: "The "views_view:view.comment.page_published" plugin does not exist. Valid plugin IDs for Drupal\Core\Menu\LocalTaskManager are..., is it possible there's a problem deeper in the system?

For me it's The "group" entity type does not exist. ( the error log says it's coming from linkit_filter). it's on a page that had a View Attachment. The content type that the view uses has a URL field but it's not using LinkIt, just link.

Anyway ideas.

I'm having a similar issue with plugin not found with "latest_version_tab", which should be dynamically handled by drupal core modules (or that's my current understanding). in my case it seems related to local task manager and content moderation. I'm still scratching my head over the call stack. This "latest_version_tab" plugin not found seems to be triggered on pages where there isn't a "latest version" at all, we are using workflows and content moderation but these pages where the error is occurring are pages where the published revision is even with the latest revision, so there is no "more recent" revision unpublished in the moderation workflow. I am not sure why drupal is looking for the "latest_version_tab" plugin for a page where there is no latest version. I'm trying to figure out why it seems like drupal thinks this page needs/expects a latest version link in the local task block, and then barfs when it can't find the plugin for it. I'm not that familliar with the inner code workings of task manager partnered with revisions/workflows, but I'm trying to dig in since it's causing random WSODs that we can't replicate, clearing cache works to get the site back alive, but this is a really slippery one to figure out.

Our team had to take a D9 theme and migrate it (along with it's configs) to D10 so this does fit in with the "seems to be happening after upgrading to D!0" trend with this overall thread. However, if this is a bad config somewhere we can't seem to figure out what it is. There is also a similar issue here: https://www.drupal.org/project/drupal/issues/3164711 but that issue was closed/can't reproduce and it seemed to be an issue with D9.

The exception and call stack are below:

a:6:{s:5:"%type";s:57:"Drupal\Component\Plugin\Exception\PluginNotFoundException";s:8:"@message";s:10381:"The "content_moderation.workflows:node.latest_version_tab" plugin does not exist. Valid plugin IDs for Drupal\Core\Menu\LocalTaskManager are: entity.block.edit_form, block.admin_display, block.admin_display_theme:claro, block.admin_display_theme:themag, block.admin_display_theme:themag_st, entity.block_content.collection, entity.block_content.canonical, entity.block_content.delete_form, entity.block_content_type.edit_form, captcha_settings, captcha_examples, captcha_points.list, config.sync, config.import, config.export, config.export_full, config.import_full, config.export_single, config.import_single, entity.config_split.canonical, entity.config_split.edit_form, entity.config_split.delete_form, entity.config_split.activate, entity.config_split.deactivate, entity.config_split.import, entity.config_split.export, entity.config_split.collection, content_moderation.workflows:content_moderation.moderated_content, content_moderation.content, dblog.view_logs, dblog.clear_logs, diff.general_settings, diff.fields_list, entity.embed_button.collection, embed.settings, encrypt.list_tab, encrypt.settings_tab, entity.entity_browser.edit_form, entity.entity_browser.edit_form_overview, entity.entity_browser.edit_widgets, entity.entity_browser.delete_form, entityqueue.entities:entity.block_content.entityqueue, entityqueue.entities:entity.config_split.entityqueue, entityqueue.entities:entity.entity_subqueue.entityqueue, entityqueue.entities:entity.media.entityqueue, entityqueue.entities:entity.menu_link_content.entityqueue, entityqueue.entities:entity.node.entityqueue, entityqueue.entities:entity.poll.entityqueue, entityqueue.entities:entity.redirect.entityqueue, entityqueue.entities:entity.shortcut.entityqueue, entityqueue.entities:entity.taxonomy_term.entityqueue, entityqueue.entities:entity.user.entityqueue, entity.entity_subqueue.canonical, entity.entity_subqueue.delete_form, environment_indicator.settings.tab, environment_indicator.collection.tab, entity.field_storage_config.collection, field_ui.fields:overview_block_content, field_ui.fields:form_display_overview_block_content, field_ui.fields:display_overview_block_content, field_ui.fields:field_edit_block_content, field_ui.fields:field_storage_block_content, field_ui.fields:field_form_display_default_block_content, field_ui.fields:field_display_default_block_content, field_ui.fields:field_display_full_block_content, field_ui.fields:field_display_token_block_content, field_ui.fields:overview_entity_subqueue, field_ui.fields:form_display_overview_entity_subqueue, field_ui.fields:display_overview_entity_subqueue, field_ui.fields:field_edit_entity_subqueue, field_ui.fields:field_storage_entity_subqueue, field_ui.fields:field_form_display_default_entity_subqueue, field_ui.fields:field_display_default_entity_subqueue, field_ui.fields:overview_media, field_ui.fields:form_display_overview_media, field_ui.fields:display_overview_media, field_ui.fields:field_edit_media, field_ui.fields:field_storage_media, field_ui.fields:field_form_display_default_media, field_ui.fields:field_display_default_media, field_ui.fields:field_form_display_inline_media, field_ui.fields:field_form_display_media_library_media, field_ui.fields:field_display_compact_preview_media, field_ui.fields:field_display_full_media, field_ui.fields:field_display_gallery_grid_media, field_ui.fields:field_display_media_library_media, field_ui.fields:field_display_paragraph_preview_media, field_ui.fields:field_display_slick_media, field_ui.fields:field_display_token_media, field_ui.fields:overview_node, field_ui.fields:form_display_overview_node, field_ui.fields:display_overview_node, field_ui.fields:field_edit_node, field_ui.fields:field_storage_node, field_ui.fields:field_form_display_default_node, field_ui.fields:field_display_default_node, field_ui.fields:field_display_diff_node, field_ui.fields:field_display_full_node, field_ui.fields:field_display_large_compact_teaser_node, field_ui.fields:field_display_large_teaser_card_node, field_ui.fields:field_display_medium_card_with_square_image_node, field_ui.fields:field_display_medium_compact_teaser_node, field_ui.fields:field_display_medium_teaser_card_node, field_ui.fields:field_display_medium_teaser_card_with_teaser_text_node, field_ui.fields:field_display_medium_teaser_item_node, field_ui.fields:field_display_rss_node, field_ui.fields:field_display_search_index_node, field_ui.fields:field_display_search_result_node, field_ui.fields:field_display_small_compact_teaser_node, field_ui.fields:field_display_small_teaser_card_node, field_ui.fields:field_display_small_teaser_item_node, field_ui.fields:field_display_teaser_node, field_ui.fields:field_display_tiny_teaser_item_node, field_ui.fields:field_display_token_node, field_ui.fields:overview_poll, field_ui.fields:form_display_overview_poll, field_ui.fields:display_overview_poll, field_ui.fields:field_edit_poll, field_ui.fields:field_storage_poll, field_ui.fields:field_form_display_default_poll, field_ui.fields:field_display_default_poll, field_ui.fields:field_display_teaser_poll, field_ui.fields:overview_taxonomy_term, field_ui.fields:form_display_overview_taxonomy_term, field_ui.fields:display_overview_taxonomy_term, field_ui.fields:field_edit_taxonomy_term, field_ui.fields:field_storage_taxonomy_term, field_ui.fields:field_form_display_default_taxonomy_term, field_ui.fields:field_display_default_taxonomy_term, field_ui.fields:field_display_full_taxonomy_term, field_ui.fields:field_display_token_taxonomy_term, field_ui.fields:overview_user, field_ui.fields:form_display_overview_user, field_ui.fields:display_overview_user, field_ui.fields:field_edit_user, field_ui.fields:field_storage_user, field_ui.fields:field_form_display_default_user, field_ui.fields:field_display_default_user, field_ui.fields:field_form_display_register_user, field_ui.fields:field_display_author_info_user, field_ui.fields:field_display_compact_user, field_ui.fields:field_display_full_user, field_ui.fields:field_display_token_user, field_ui.fields:overview_paragraph, field_ui.fields:form_display_overview_paragraph, field_ui.fields:display_overview_paragraph, field_ui.fields:field_edit_paragraph, field_ui.fields:field_storage_paragraph, field_ui.fields:field_form_display_default_paragraph, field_ui.fields:field_display_default_paragraph, field_ui.fields:field_display_mg_compact_paragraph, field_ui.fields:field_display_preview_paragraph, field_ui.fields:field_display_token_paragraph, entity.entity_view_mode.edit_form, entity.entity_form_mode.edit_form, entity.entity_view_mode.collection, entity.entity_form_mode.collection, entity.filter_format.edit_form_tab, filter.admin_overview, google_analytics.admin_settings_form_tab, google_tag.default_tag_tab, google_tag.settings_form_tab, google_tag.container_list_tab, entity.image_style.edit_form, entity.image_style.collection, jm_cache.cc_open_modal, entity.key_config_override.collection, media.tasks:entity.media.canonical, media.tasks:entity.media.delete_form, entity.media_type.edit_form, entity.media_type.collection, entity.media.collection, media_directories_ui.media_directories_overview.tab, media_library.table, media_library.grid, entity.menu.view_modes_settings, entity.menu.view_modes_settings.default, entity.menu_link_content.canonical, entity.menu.edit_form, entity.menu.collection, metatag_defaults, metatag.settings, entity.node.canonical, entity.node.edit_form, entity.node.delete_form, entity.node.version_history, entity.node_type.edit_form, entity.node_type.collection, entity.path_alias.collection, entity.poll.canonical, entity.poll.edit_form, entity.poll.delete_form, poll.poll_overview, poll.settings, preview_link.entity_links:block_content.preview_link_generate, preview_link.entity_links:entity_subqueue.preview_link_generate, preview_link.entity_links:media.preview_link_generate, preview_link.entity_links:menu_link_content.preview_link_generate, preview_link.entity_links:node.preview_link_generate, preview_link.entity_links:taxonomy_term.preview_link_generate, recaptcha.admin_settings_form_tab, redirect.list, redirect.settings, redirect_404.fix_404, entity.responsive_image_style.edit_form, samlauth.configuration, search.plugins:node_search, shortcut.set_switch, entity.shortcut_set.customize_form, entity.shortcut_set.edit_form, entity.shortcut.canonical, simple_sitemap.sitemaps, simple_sitemap.status, simple_sitemap.types, simple_sitemap.settings, simple_sitemap.inclusion, simple_sitemap.entities, simple_sitemap.custom, entity.slick.collection, entity.slick.edit_form, slick.settings, structure_sync.general, structure_sync.taxonomies, structure_sync.blocks, structure_sync.menu, system.rss_feeds_settings_tab, system.site_maintenance_mode_tab, system.site_information_settings_tab, system.themes_page, system.theme_settings, system.theme_settings_global, system.theme_settings_theme:claro, system.theme_settings_theme:themag, system.theme_settings_theme:themag_st, system.modules_list, system.modules_uninstall, system.admin, system.admin_index, entity.date_format.collection, entity.date_format.edit_form, entity.version_history:block_content.version_history, system.admin_content, system.performance_settings, entity.taxonomy_term.canonical, entity.taxonomy_term.edit_form, entity.taxonomy_term.delete_form, entity.taxonomy_vocabulary.overview_form, entity.taxonomy_vocabulary.edit_form, update.status, update.settings, update.report_update, update.module_update, update.theme_update, entity.user_role.edit_form, entity.user_role.edit_permissions_form, user.account_settings_tab, user.register, user.pass, user.login, entity.user.canonical, entity.user.edit_form, entity.user.collection, user.admin_permissions, entity.bundle.permission_form:permissions_block_content_type, entity.bundle.permission_form:permissions_media_type, entity.bundle.permission_form:permissions_node_type, entity.bundle.permission_form:permissions_taxonomy_vocabulary, entity.user_role.collection, user.role.settings, views_ui.settings_tab, views_ui.settings_basic_tab, views_ui.settings_advanced_tab, views_ui.list_tab, views_ui.reports_fields, entity.view.edit_form, entity.view.edit_display_form, pathauto.patterns.form, pathauto.settings.form, pathauto.bulk.update.form, pathauto.admin.delete, views_view:view.files.page_1, views_view:view.samlauth_map.page, entity.paragraphs_type.edit_form, entity.paragraphs_type.collection";s:9:"%function";s:58:"Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition()";s:5:"%file";s:83:"/var/www/html/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php";s:5:"%line";i:53;s:17:"@backtrace_string";s:7050:"#0 /var/www/html/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(25): Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition()
#1 /var/www/html/docroot/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition()
#2 /var/www/html/docroot/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(83): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance()
#3 /var/www/html/docroot/core/lib/Drupal/Core/Menu/LocalTaskManager.php(263): Drupal\Component\Plugin\PluginManagerBase->createInstance()
#4 /var/www/html/docroot/core/lib/Drupal/Core/Menu/LocalTaskManager.php(290): Drupal\Core\Menu\LocalTaskManager->getLocalTasksForRoute()
#5 /var/www/html/docroot/core/lib/Drupal/Core/Menu/LocalTaskManager.php(358): Drupal\Core\Menu\LocalTaskManager->getTasksBuild()
#6 /var/www/html/docroot/core/lib/Drupal/Core/Menu/Plugin/Block/LocalTasksBlock.php(95): Drupal\Core\Menu\LocalTaskManager->getLocalTasks()
#7 /var/www/html/docroot/core/modules/block/src/BlockViewBuilder.php(171): Drupal\Core\Menu\Plugin\Block\LocalTasksBlock->build()
#8 [internal function]: Drupal\block\BlockViewBuilder::preRender()
#9 /var/www/html/docroot/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(111): call_user_func_array()
#10 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(797): Drupal\Core\Render\Renderer->doTrustedCallback()
#11 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(386): Drupal\Core\Render\Renderer->doCallback()
#12 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(458): Drupal\Core\Render\Renderer->doRender()
#13 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#14 /var/www/html/docroot/core/lib/Drupal/Core/Template/TwigExtension.php(474): Drupal\Core\Render\Renderer->render()
#15 /tmp/someenvprod/php_storage/twig/refs/tags/pipelines-build-version/1.0.4/sitename/twig/651c79a5091cd_page--layout-builder-enab_cWANDOXnBZPVjkUKgA-Bshhuj/bJlK2EuJOpNYOG693jgXH4DBBV1LqZbpzLb088q8lds.php(54): Drupal\Core\Template\TwigExtension->escapeFilter()
#16 /var/www/html/vendor/twig/twig/src/Template.php(394): __TwigTemplate_618eeaf42370d16879ebe70a43b62376->doDisplay()
#17 /var/www/html/vendor/twig/twig/src/Template.php(367): Twig\Template->displayWithErrorHandling()
#18 /var/www/html/vendor/twig/twig/src/Template.php(379): Twig\Template->display()
#19 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(40): Twig\Template->render()
#20 /var/www/html/docroot/core/themes/engines/twig/twig.engine(53): Twig\TemplateWrapper->render()
#21 /var/www/html/docroot/core/lib/Drupal/Core/Theme/ThemeManager.php(372): twig_render_template()
#22 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(445): Drupal\Core\Theme\ThemeManager->render()
#23 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#24 /var/www/html/docroot/core/lib/Drupal/Core/Template/TwigExtension.php(474): Drupal\Core\Render\Renderer->render()
#25 /tmp/someenvprod/php_storage/twig/refs/tags/pipelines-build-version/1.0.4/sitename/twig/651c79a5091cd_html.html.twig_7zwbrb3i83LMTfxPRAN_sdvFP/ijhtjG8FEH8x8Z_h3LQErV4QMb2bPGgyr4MUlVV3lx8.php(162): Drupal\Core\Template\TwigExtension->escapeFilter()
#26 /var/www/html/vendor/twig/twig/src/Template.php(171): __TwigTemplate_e8de942a1490ca3511adedde44242f4b->block_body()
#27 /tmp/someenvprod/php_storage/twig/refs/tags/pipelines-build-version/1.0.4/sitename/twig/651c79a5091cd_html.html.twig_7zwbrb3i83LMTfxPRAN_sdvFP/ijhtjG8FEH8x8Z_h3LQErV4QMb2bPGgyr4MUlVV3lx8.php(131): Twig\Template->displayBlock()
#28 /var/www/html/vendor/twig/twig/src/Template.php(394): __TwigTemplate_e8de942a1490ca3511adedde44242f4b->doDisplay()
#29 /var/www/html/vendor/twig/twig/src/Template.php(367): Twig\Template->displayWithErrorHandling()
#30 /var/www/html/vendor/twig/twig/src/Template.php(379): Twig\Template->display()
#31 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(40): Twig\Template->render()
#32 /var/www/html/docroot/core/themes/engines/twig/twig.engine(53): Twig\TemplateWrapper->render()
#33 /var/www/html/docroot/core/lib/Drupal/Core/Theme/ThemeManager.php(372): twig_render_template()
#34 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(445): Drupal\Core\Theme\ThemeManager->render()
#35 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()
#36 /var/www/html/docroot/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(158): Drupal\Core\Render\Renderer->render()
#37 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(592): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#38 /var/www/html/docroot/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(159): Drupal\Core\Render\Renderer->executeInRenderContext()
#39 /var/www/html/docroot/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse()
#40 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
#41 /var/www/html/docroot/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func()
#42 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(187): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#43 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#44 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle()
#45 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#46 /var/www/html/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#47 /var/www/html/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#48 /var/www/html/docroot/modules/contrib/shield/src/ShieldMiddleware.php(270): Drupal\page_cache\StackMiddleware\PageCache->handle()
#49 /var/www/html/docroot/modules/contrib/shield/src/ShieldMiddleware.php(137): Drupal\shield\ShieldMiddleware->bypass()
#50 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\shield\ShieldMiddleware->handle()
#51 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#52 /var/www/html/docroot/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#53 /var/www/html/docroot/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#54 /var/www/html/docroot/index.php(19): Drupal\Core\DrupalKernel->handle()
#55 {main}";}

Refocussing this on the concrete issue of filter plugins.

Adding steps to reproduce.

Added an MR to take care when we're syncing the entity.

@larowlan, excellent work.

It would be very very nice to get this backported even into 9.5.x with a tagged release
10.0.x and 10.1.x given how much of a positive impact this will have on the upgrade process helping people through the upgrade process from Drupal 9.5 through 10.0 and into 10.1 and beyond.

People get trapped into this, I might even suggest backporting to 9.4.x, 9.3.x and tagging a release for those also in case anyone is still stuck on this issue where it's blocking their upgrade process.

I've seen this issue many times and managed to work around the issue but it's not easy to figure out for someone with less grey hairs than me.

Seems will still need test coverage though.

D9 is EOL so don't think any new releases will be done, could be wrong not sure if there are special cases but I haven't seen it.

Thanks!

@larowlan in #177: AFAICT that is precisely what the already-RTBC #3017054: Consistently sort filter formats to simplify config exports is solving?

Thanks @Wim Leers - I wasn't aware of that one, added to my list 🙌

That one is in!

What does that mean for this issue? 🤔 Does that mean we should restore the original scope? I'm not familiar yet with the ins and outs of this issue, so letting @larowlan or somebody else make a more informed suggestion than I could right now 😅

@Wim Leers we still need the check for isSyncing in editor.module (And in ckeditor in contrib).

I think we should be dealing with these issues on a per-module/sub-system basis. The filter one (which is now just the isSyncing check in editor module) is actionable. Each other issue needs its own issue.

Needs work for a re-roll after the filter sorting one went in.

Related to this, we found a similar scenario:
* Update a text format to remove a filter ("My Filter") that comes from a specific module ("My Filter Module").
* Uninstall the module.
* Export the configuration, confirm that both the filter.format.*.yml and core.extensions.yml files are updated.
* Attempt to load the config changes in another copy of the same site using Drush, this error will be shown:

[error] Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Unable to uninstall the My Filter Module module because: Provides a filter plugin that is in use in the following filter formats: Full HTML. in Drupal\Core\Config\ConfigImporter->validate() (line 814 of core/lib/Drupal/Core/Config/ConfigImporter.php).

Do we have any possible solution for this??
This issue starts occurring after upgrade from Drupal 9 to Drupal 10. its not easily reproducible, However if we do lots of content entries it occurs but not every time.

The patch provides an error on D10.2 and editing and trying to create a new fitler type using ckeditor5:

?destination=/admin/config/content/formats|1||Warning: Undefined array key "provider" in Drupal\filter\Entity\FilterFormat->filters() (line 148 of d10.2.x/html/core/modules/filter/src/Entity/FilterFormat.php)

I also experience the error reported in #188. In addition, I am unable to create any new filter text formats because I am unable to select CKEditor5 as the text editor. I get an error indicating that I must select and configure it when I try to save. I removed the patch to create the new filter, but am now experiencing the original plugin error reported.

Hiding old patches and screenshots, going to take a stab at this today.

I can't reproduce the PluginNotFoundException, but I do get another error

Unable to uninstall the Linkit module because: Provides a filter plugin that is in use in the following filter formats: Basic HTML

This is following the steps in the IS, but without the environment switch, so:

1. drush si standard
2. drush en linkit -y
3. Login and enable the Linkit filter on Basic HTML
4. Dump your database
5. Disable the filter on Basic HTML
6. drush pmu linkit
7. Export configuration
8. Restore the database
9. drush cim -y

On both 11.x and the current MR branch I get the above error.

This is looking much trickier than I'd hoped. Tried adding another isSyncing() check in FilterUninstallValidator but at that point the filter config hasn't been marked as syncing :(

EDIT: We also can't check \Drupal::service('config.installer')->isSyncing(), that doesn't get set until after validation.

Further testing shows the Plugin (X) instance class "Drupal\my_module\Plugin\Filter\X" does not exist. appears if you try to config import when the actual plugin file doesn't exist. Perhaps the original error was reported when people were trying to deploy the uninstallation of the module, the removal of the plugin AND they had removed the module from composer. I don't think that's something we support currently (there's other issues floating around about being able to uninstall a module that no longer exists on the file system) so we can focus on the config dependency issue here.

In my case I have a DEV server and a LIVE (production) server. We have yet to be able to reproduce the errors in DEV that we see in LIVE. We are looking into possible server differences but we have not found any yet. We've tested backups of LIVE in DEV and still can't recreate in DEV. The first "plugin" error I get in LIVE is for CKEditor5. Any page that needs to use the WYSIWYG in the admin is not accessible. CKEditor5 is not listed in the Text Formats page. Just "---" where it should say CKEditor5.

We are in the process of cloning the LIVE environment so we can recreate the issue and debug it in LIVE-CLONE without affecting the actual LIVE site.

Not quite sure what fixed the issue since I'm not quite sure what the problem was but here is what we did:

- Created a clone of the entire LIVE server
- Changed local Host file to point us at the new clone site
- Went to a page that uses CKEditor to be sure it was still causing an error (success)
- Since using drush cr possibly made the site worse, I tried going through individual cache commands and checked the site after each one to be sure it was still working
- cd ../../var/www/drupal
- ./vendor/bin/drush cache-clear theme-registry
- ./vendor/bin/drush cache-clear css-js
- ./vendor/bin/drush twig-compile
- ./vendor/bin/drush cache-clear router
- ./vendor/bin/drush cr
- ./vendor/bin/drush eval "drupal_flush_all_caches();"
- ./vendor/bin/drush config:status
- ./vendor/bin/drush cex
- ./vendor/bin/drush cr
- lastly I clicked the Cache Rebuild button in the admin UI

The site was no longer giving me anymore of the "plugin not found" errors. So we did the same in the LIVE server with the same results.

Unfortunately, I did not test any pages using CKEditor during any of these steps so I can't say which step made the magic happen. Sorry, I forgot and I'm kicking myself.

But our site is back up and running so hope this helps someone else with their similar issues.

Not sure about what status to leave this in, but with: #2579743: Config entities implementing EntityWithPluginCollectionInterface should ask the plugins to react when their dependencies are removed this can now be fixed.

Unfortunately contrib needs to add the interface and correct behavior.

Maybe we can gather some of the modules here and open issue in contrib for 11.3?

Re #197: I'm not sure the new APi from #2579743: Config entities implementing EntityWithPluginCollectionInterface should ask the plugins to react when their dependencies are removed will help that much, because Drupal\filter\Entity\FilterFormat::onDependencyRemoval() already loops through all the filter plugins on module uninstall and removes them if possible. The problem is that only disabled filter plugins are removed, because it's a security risk to remove enabled filters from a format. And there's the FilterUninstallValidator that runs before onDependencyRemoval(), and the validator prevents a module from being uninstalled if any of its filter plugins are enabled in formats. During config sync, module install/uninstall happens before config objects and config entities are updated, so even the incoming configuration has those plugins removed, the validator does not know that.