Updating my test site from 8.2.7 to 8.3.0 fails in the database update. Same thing happens whether I do it with drush or through the web interface. Here is the full error output:

system module
Update add_region_to_entity_displays

Failed: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity_reference_autocomplete_category" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of /home/bemsi/public_html/ja/drupal8-composer/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

PHP 5.6.28 with the status page all green except for this db problem and the warning about experimental modules (Datetime Range, Migrate).

What extra info can I provide?

Comments

lynxlynxlynx created an issue. See original summary.

cilefen’s picture

Component: database update system » plugin system
Priority: Normal » Major
lynxlynxlynx’s picture

Drush is at 8.1.10, yes. The site update was done through composer, first core&deps, then a general update (no arguments).

grepping for autocomplete_category only showed it in database dumps, so I don't know how to find its source.

List of extra modules:

$ drush pm-list --no-core
 Package                          Name                               Type    Status         Version       
 Chaos tool suite                 Chaos tools (ctools)               Module  Enabled        8.x-3.0-beta1 
 Chaos tool suite (Experimental)  Chaos tools blocks (ctools_block)  Module  Not installed  8.x-3.0-beta1 
 Chaos tool suite (Experimental)  Chaos tools Views (ctools_views)   Module  Not installed  8.x-3.0-beta1 
 Custom                           Linkit (linkit)                    Module  Enabled        8.x-4.3       
 Other                            Diff (diff)                        Module  Enabled        8.x-1.0-rc1   
 Other                            Pathauto (pathauto)                Module  Enabled                      
 Other                            Token (token)                      Module  Enabled        8.x-1.0-rc1   
 Performance and scalability      Sessionless BigPipe                Module  Enabled        8.x-1.0       
                                  (big_pipe_sessionless)                                                  
 SEO                              Simple XML Sitemap                 Module  Enabled                      
                                  (simple_sitemap)                                                       
gnuget’s picture

berdir’s picture

Status: Active » Postponed (maintainer needs more info)

entity_reference_autocomplete_category is not from facets and I have not found *anything* on google, could have been custom code. Do you remember having installed any special modules or or so related to entity reference fields/autocomplete handling that you removed again?

Please enable verbose error logging and provide a full backtrace.

It's possible that you have some kind of widget configuration that uses a plugin that no longer exists. At runtime, it possibly falls back to the default plugin but the update code might not do that.

Try doing a configuration export and search for it in there, that should tell you which entity type/bundle that is, then you can go to the UI and reconfigure the problematic field.

lynxlynxlynx’s picture

I don't remember installing anything exotic (it's tracked in git), except testing a cms2cms migration. However the bridge's source code also contains not even partial matches.

However, looking at drush cex, there are mentions in core.entity_form_display.node.article.default.yml and the field that it applies to was surely created by the migrator.

In the form display settings, nothing looked odd. Switching the mode from "Select list" to "Autocomplete" made the db update work though. I guess this report can be closed.

berdir’s picture

Good to know that you were able to solve it for your site.

Lets keep this open for now, I think our update function should play safe and add a try/catch wrapper or include a hasDefinition() check before calling getDefinition() for those plugins. Clearly we're doing it when displaying articles, otherwise your site would have failed like that a long time ago.

Possibly that can also be done in the related issue, though then we could close this as a duplicate.

lynxlynxlynx’s picture

Just a small follow-up: the update to 8.3.1 went fine. Toggling back to a select list also changed the exported config appropriately, so I don't expect further problems when 8.3.2 comes around.

xjm’s picture

However, looking at drush cex, there are mentions in core.entity_form_display.node.article.default.yml and the field that it applies to was surely created by the migrator.

This is really interesting; what version of Drupal 8 did you migrate into originally?

lynxlynxlynx’s picture

Judging from my initial report: 8.2.7. Could have been .6 or .5 too, but nothing older.

Version: 8.3.0 » 8.3.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.

Version: 8.3.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
quietone’s picture

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

@lynxlynxlynx, thanks for reporting back!

Reading through this again. The creator of the issue has solved the problem, so that is good.

However, looking at drush cex, there are mentions in core.entity_form_display.node.article.default.yml and the field that it applies to was surely created by the migrator.

It has been some time since I delved into the migration of fields, but this is not surprising. Migrate will do it's best to re-created everyone from the source site and sometimes would create things for which there was no plugin on the destinations. Over time the field migration have been improved.

I do not see anything to do here.

Therefore, closing as outdated. If this is incorrect reopen the issue, by setting the status to 'Active', and add a comment explaining what still needs to be done.

Thanks!