After running the migration, I get the following error when visiting an admin page:

Fatal error: Class 'Drupal\webform\BreadCrumb\WebformBreadcrumbBuilder' not found in /var/www/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 264

No amount of cache clearing fixes this. We have the latest beta of version of Webform downloaded, and it says Webform is enabled after the migration is complete.

We only have a few forms and less than 100 submissions between them.

I attempted to run the migration via an update as well, to see if I could catch anything else, and it throws this error multiple times:

Error: Class name must be a valid object or a string in
/var/www/docroot/core/modules/field/src/FieldStorageConfigStorage.php, line 155

So that might shed some light on what is going on.

CommentFileSizeAuthor
#12 after_migration-2836246-12.patch864 bytesjrockowitz

Comments

jazzdrive3 created an issue. See original summary.

jazzdrive3’s picture

jazzdrive3 commented
Issue summary: View changes
jrockowitz’s picture

jrockowitz commented

Both of those errors indicate that the webform module is missing. My immediate guess is that the migration failed to complete and switch core to using the webform module. Your migrated config and data might be fine.

I was able to easily replicate the below error on plain install (w/o a migration) by just deleting (actually renaming) the webform module's directory.

Fatal error: Class 'Drupal\webform\BreadCrumb\WebformBreadcrumbBuilder' not found in .../core/lib/Drupal/Component/DependencyInjection/Container.php on line 264

The 'Class name must be a valid object' error is also related to missing Field plugins provided by a missing module. If you debug that error you will be able to figure what is the exact field plugin that is missing, my best guess is that it will be the webform field.

Because I just changed the webform directories name to '_webform', running `drush cr` actually fixed the issue because core was able to rediscover the new location of the webform module.

A few thoughts and things you can try…

  • Make sure the webform module and yamlform module are in the same directory. This ensures that core will find the new webform module when it is enabled during the migration.
  • Are both the yamlform and the webform module enabled?
  • `drush pm-list --status=enabled --no-core --format=list`
  • Can you do a `drush config-export` and see if the webform config is exported?
  • Is is possible to test migration with just the YAML Form module enabled?
jazzdrive3’s picture

jazzdrive3 commented

Thanks for the follow-up.

- They are in the same directory
- Webform is enabled after the migration.
- There is webform defined configuration that is exported.
- We did the migration with just YAMLform module enabled, but the Webform module files present. If we try it with the Webform module enabled, we get a bunch of integrity constraint violations in the database, and our old stuff isn't migrated.

It really seems the problem is the WebformBreadcrumbBuilder service. If I comment that out of the services.yml file, we still get the "Error: Class name must be a valid object or a string in
/var/www/docroot/core/modules/field/src/FieldStorageConfigStorage.php, line 155" during the migration, but the site loads fine afterward. Weird.

jrockowitz’s picture

jrockowitz commented

You definitely should not do a migration with the Webform module enable.

Can you access the migrated Webforms with the WebformBreadcrumbBuilder service removed?

I really don't think WebformBreadcrumbBuilder service is the source of the problem... it is just a symptom.

Some more questions...

What modules do you have enabled?

Are you using YAML Form nodes?

Do you have any entity reference pointing to YAML forms?

What OS and PHP version are you using?

Are any errors or warning being logged during the migration?
I will admin I am little stumped...

jazzdrive3’s picture

jazzdrive3 commented

I comment out the webform.breadcrumb service entry in webform.services.yml, and it seems everything works. I can access the webforms and edit them and view them.

We weren't using the YAMLform node module, but we do have a form reference field attached to another (custom) content entity type.

I put the migration code into an update hook:

$migrate_manager = \Drupal::service('yamlform_to_webform.migrate_manager');
$migrate_manager->migrate();

And it throws Fatal error: Class name must be a valid object or a string in /var/www/docroot/core/modules/field/src/FieldStorageConfigStorage.php on line 155

We do have some config stored in Features, so I'm going to update all of that and see if that makes a difference. And then maybe get a more detailed stacktrace.

jazzdrive3’s picture

jazzdrive3 commented

I stepped through this a bit.

Turns out the error in FieldStorageConfigStorage does not happen until the caches are rebuilt. It chokes when it gets to our form reference field. It gets Drupal\yamlform\Plugin\Field\FieldType\YamlFormEntityReferenceItem as the class, and of course that doesn't exist anymore.

So I guess we need to clear the config of that item?

jrockowitz’s picture

jrockowitz commented

The YAML Form to Webform migration script is a pretty major process which updates to database tables, columns, and records. I never tried to do it via an update hook. I always felt that it would be executed in a separate drush command. Please try the migration outside on an update hook and see if it works. If it works, then we can focus on running the migration via an update hook.

BTW, another guess is a config import during your update hooks is reverting some of the migration's changes.

jazzdrive3’s picture

jazzdrive3 commented

I'm not normally running it during an update hook. I only did that so I could see the errors, and then step through it. It causes the same problems and throws the same errors if I just do the drush command.

It's the only update hook that is running at the moment, with nothing else happening.

jrockowitz’s picture

jrockowitz commented

Okay, definitely sounds like the migration is not changing YamlForm to Webform in your configuration files.

Can you run the migration, export your config, and do a search for the word YamlForm & yamlform and see if it is still in some of your configuration file?
What are files still refer to YamlForm?

Then see if the word Webform is anywhere.
What are files correctly refer to Webform?

Is there any pattern to this madness?

It is very possible I will have to do slightly different and more direct migration of the configuration file stored in the DB. This is not a big deal especially if your data migration is okay.

jazzdrive3’s picture

jazzdrive3 commented

Ran the update fresh and exported my config. No yamlform strings anywhere in the exported config.

The only things in the database I can find with yamlform are in the key_value and key_value_expire tables. In key_value_expire, they are part of the form and form_state collection. I guess these are where forms are cached?

jrockowitz’s picture

jrockowitz commented
Status: Active » Needs review
StatusFileSize
new after_migration-2836246-12.patch864 bytes

Wow, you found the only table and columns that are missing from the migration. The key_value.collection column was not being updated. I am surprised other people are not having issues.

I am willing to bet that the attached patch solves your problem.... or at least I really hope so

BTW, what version of Drupal are you using? I am still very surprised I could not duplicate this issue.

Status: Needs review » Needs work

The last submitted patch, 12: after_migration-2836246-12.patch, failed testing.

jazzdrive3’s picture

jazzdrive3 commented

The patch didn't seem to make a difference. I have done some more step throughs to try and narrow down what is happening.

When EntityViewsData cascades and gets all the field definitions for an entity (in our case, our custom content entity type), it eventually gets to our form item. It's type is "webform", so it passes $this->fieldTypeManager->getPluginClass() the type of webform. But it returns NULL. It's can't find the plugin class. But in the definitions list of FieldTypePluginManager.php, the yamlform plugin definition already exists. So it seems there is this weird limbo.

And in our table for that form field "__field_form" and in the revision table, the value in the bundle column is still "yaml_form".

Thanks!

jrockowitz’s picture

jrockowitz commented

Huh, that is starting to make more sense. I am not replacing the string 'yaml_form' because I have never use it in my code. I am going to add 'yaml_form' to the migration script and maybe this will fix your problem.

  • jrockowitz committed 434c371 on 2836246-migration-issue 
    Issue #2836246 by jrockowitz: After Migration, Webform Classes can't be...
jrockowitz’s picture

jrockowitz commented
Status: Needs work » Needs review

Let's see if the attached patch works.

jazzdrive3’s picture

jazzdrive3 commented

So these changes seem to fix the original issue of the WebformBreadcrumb class not being found. So thank you!

Still getting some cache rebuilt errors around config, so we'll need to figure out something else for the the build process, since we can't put it in an update hook. But that's something we can easily work around.

Thanks for your persistence.

jazzdrive3’s picture

jazzdrive3 commented
Status: Needs review » Reviewed & tested by the community

  • jrockowitz committed 53ed898 on 8.x-1.x 
    Issue #2836246 by jrockowitz: After Migration, Webform Classes can't be...
jrockowitz’s picture

jrockowitz commented
Status: Reviewed & tested by the community » Fixed

I applied the patch. Please keep me posted on the config related issues.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.