Unable to create events after upgrade from 4.x to 5.1.0

The error happens also when trying to create events even outside a group.
I have created an issue reporting so here:
https://www.drupal.org/project/social/issues/3050098

I opened a PR to solve this, please see https://github.com/goalgorilla/open_social/pull/1349

Is there a quick workaround for now? I got a production site that is unusable now.

I rolled back, and stayed on 8.x-4.10.
There doesn't seem to be a proper workaround and upgrade to 5.x remains broken.

#3 solved the issue on my site as well! THANKS!

Confirming that #3 also fixed this for me! Thanks @igasi.

just changing this to needs review so that it will be easier for people like myself to find under pending patches

Yess, #3 helps!
Thx

The fact that a check for hasField works here strikes me as odd. A field is part of an entity (configuration) so whether the values for that entity have already been created shouldn't matter.

Could someone try the following for me:

• Do not use the patch in #3
• Verify that the problem is still there
• Run drush entity-updates
• Check whether this fixes the issue

You'll need to ensure you're using Drupal 8.6 or lower to avoid https://www.drupal.org/node/3034742

If this fixes the issue as well then we should instead write an update hook to properly update the stored field configuration for the Event bundle.

In response to to @Kingdutch:

I backed out the patch and confirmed the error is present again. I then ran your drush command but the error was not fixed. Here is my output from the drush command:

 [success] No entity schema updates required
 [success] Finished performing updates.

However, attempting to create or access an Event still results in the following error:

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

Thanks for test it @fcgreg I tried and I get still the same error.

@Kingdutch I was digging a little more, I think the validation is ok, but is needed to ensure that the field is being created when is running an update, OpenSocial 5.x work without problem when is installed from scratch but for and update from previous versions, there are many configs that are not applying correctly on of this is field.field.node.event.field_event_enroll the field.storage.node.field_event_enroll is presented.

The reason because is not applying is because some modules in this case social_event is already installed, and after during the development to the new version, new config yml file were added to config/install or config/optional, for new instance of OpenSocial this does not affect because during installation Drupal perform an import of this configs, but during an update not, Drupal does not check is some config was removed or added from that folder, also this could be related with another issues presented, mostly config missing.

I think the proper workaround, is check for all new configs added in this new version and apply a hook update to ensure the configs were applied correctly if not apply them.

Maybe is needed some approach similar to this PR https://github.com/goalgorilla/open_social/pull/1338/files for social_event or another to import specific yml configs fro install/optional folder.

If the new configuration is not there then this suggests that either the feature revert was not run (drush -y fra --bundle=social) or did not run correctly. See 2.1 step 4 of the installation and updating instructions.

For the people that are experiencing this problem: Have you reverted the feature state before experiencing this problem? Does reverting the feature state as indicated solve the problem?

As an aside: we're investigating alternatives for the use of the features module but this is a difficult problem to tackle so for now this step is required during updates.

Thanks for the PR and the reports. We will include this code in 5.2 to be released on Wednesday. However I think it's important to note here that you should always follow the update instructions of the software you use. If you use OS as intended you should not run into this problem.

That being said it doesn't hurt to be a bit more defensive here and we will add this check now. I can't guarantee that you won't run into other issues with OS if you choose not to follow the update instructions.

Note on Features, like Kingdutch is mentioning in #14 we want to remove dependency to Features as well. There is already some discussion going on to improve this experience: https://www.drupal.org/project/ideas/issues/2957423

Features did help us very well, you have to imagine we started working on Open Social in the early days of Drupal 8 when CMI wasn't what it is now. It was the tool that did the job for us in order for us to get where we are now. So credit is definitely due there.

Unfortunately it's making the upgrading and updating tasks so difficult, so yes we want to improve on it, but it will take a serious amount of effort in order to do so and we hope we can do so in the near future!

But thanks for all your input and effort guys :)

Hi grn,

In our own projects extending Open Social we use Configuration Overrides, either as classes or using the drupal/config_override module. This ensures that we don't need to duplicate configuration managed by Open Social but only add our own changes on top of it. That should make upgrading with feature reverts easier.

When working with an array in a configuration file, e.g.:

dependencies:
  - Dependency 1
  - Dependency 2

When using a configuration override class you can give the override a string key:

$overrides['configuration']['dependencies']['my_dependency_1'] = "Dependency 3";

This will ensure that the dependencies get properly merged as integer keys would otherwise be overridden.