Update to 8.x-1.8 breaks my site

I'm also seeing this issue in my 1.8.0 release.

hook_update_8003 installs optional config which is missing a theme key and has an empty region.

I'd be curious if this happens on a new install as well.

I guess optional config should not be forced to be installed.
Hook updates are nor run at new install. System will find itself the available optional configs. I will test with some dummy dependency.

Ofcourse this happens on other themes than mine.
Are you able to complete the following test?
- go to /admin/structure/block 'Block layout'
- Choose a region, press [Place Block], choose 'Workflow Transition form', save
- Now go to /node/NUMBER in order to display a node.
- You should see a block with the Workflow Transition form.
Thanks.

I can confirm that I can see the Form under place block. 👍

Let's remove the Install Optional Config, since the system will do that automatically once al prerequisites are fulfilled.

Thank you for the fix @johnv

Hi Everyone, I have followed the steps in the #4 comment but the problem is still present. I have also applied a local patch to comment the code in the workflow.install file but the drush cim still not working and the errors are present. How can I solve this mistake?

Thanks.

@cicciobat, please specify your exact errors of your drush cim (config:import). And better to do it with both parts of the above commit applied.

The comment #4 was to establish if the block could be added manually. Ofcourse (in hindsight), some attributes may differ between the optional config and the manual config.

Hi, this is the error that I receive:

[error] Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
The <em class="placeholder">block.block.workflowtransitionform</em> configuration depends on the <em class="placeholder"></em> theme which will not be installed after import. in Drupal\Core\Config\ConfigImporter->validate() (line 823 of /var/www/*/app/deploy/main/*/core/lib/Drupal/Core/Config/ConfigImporter.php).

In ConfigImportCommands.php line 290:

  The import failed due to the following reasons:
  The <em class="placeholder">block.block.workflowtransitionform</em> configuration depends on the <em class="placeholder"></em> theme which will not be installed after import.


In ConfigImporter.php line 823:

  There were errors validating the config synchronization.
  The <em class="placeholder">block.block.workflowtransitionform</em> configuration depends on the <em class="placeholder"></em> theme which will not be installed after import.

As you can see the error come from the block.block.workflowtransitionform config. I've already do the updb but in dev and local environments.

Please apply above committed fix and try again with enabled update_hook.
If error appears, comment out the update_hook 8003.
You may try drush config-delete "your-config-name".

Ok but I need to change also the hook_update number, no? So the updb can be ran.

I tried, but the error is still present. I'll comment out the hook update and delete the config.

Can you each time re-run the update hook? That means it is not processed upon error ( Which is good).
It is a bit strange, since over 340 sites are now running in the new version, Apparently without update error.

No, the update run correctly but the cim not works if the cim is run after the updb.

I'm facing the same error:

[Exception]                                                                                                                                                                
  The import failed due to the following reasons:                                                                                                                            
  Configuration <em class="placeholder">block.block.workflowtransitionform</em> depends on the <em class="placeholder"></em> theme that will not be installed after import.

Following steps from comment https://www.drupal.org/project/workflow/issues/3454189#comment-15658795 🐛 hook_update_8003 to 8.x-1.8 installs optional config and breaks my site Active

And the error persists, after adding the change on this commit:
https://git.drupalcode.org/project/workflow/-/commit/c2128f2d818f5fe1b89...

Commenting workflow_update_8003 didn't change anything --- I'm assuming because it was run already.

Then I tried config delete, and the issue still there:
drush config-delete block.block.workflowtransitionform

Any other suggestions will be appreciated!

This patch worked for me --- but because I'm using pmt_bootstrap theme, so probably something else will be needed for a general solution.

I ran drush config-delete block.block.workflowtransitionform on dev, drush cex -y, commited the deleted config file, then pushed to prod : drush cim worked

#20 was correct for me also

Had the same error on Drupal v10.3.2 updating workflow 1.7 to 1.8.

#20 works, but to workflow 1.8 it's not a flawless update.

Can we please release this?

For the time being, attaching the current static patch to circumvent that issue.

I'm lacking context on why exactly it was done that way. Maybe we need to set the theme for that block config in the update hook to actually have it as originally intended?

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

@johnv: I think we should reopen this bug, as I don't believe it's completely fixed. I'm running a site-install on a plain vanilla site (D10.4) and the latest dev-1.x branch from git. We have some config we import after the install, and when I do this step, it apparently is still trying to install this block config and failing. I get the same The <em class="placeholder">block.block.workflowtransitionform</em> configuration depends on the <em class="placeholder"></em> theme which will not be installed after import. in Drupal\Core\Config\ConfigImporter->validate() (line 823 of /var/www/*/app/deploy/main/*/core/lib/Drupal/Core/Config/ConfigImporter.php). as mentioned above.

It's not clear to me what the *correct* way to ship a block config in a contrib module, since the theme and region keys can't be known ahead of time. It looks like core ships with some block configs that are specific to core themes, but I haven't found a good example of a contrib module that can't know what themes are installed.

In the latest relevant update, all hints to a 'region' are removed. There should be not theme-dependent settings.
Which theme are you using?

Above patch removes both references to region and theme.
The config_inspector report also reports an error for NULL theme.
Please test latest dev version.

@johnv: I can confirm that a fresh install with the latest dev branch will not complain about this optional config (unless I try to force the matter, but that's a different story). However, in futzing with this and thinking it through a bit more, I'm even more convinced that this is the wrong way to approach the problem of shipping a block in a contrib module.

The thing is, what ends up happening is we successfully import a config named block.block.workflowtransitionform which applies to *nothing*. It's never used. In order for a block config to be useful, it has to mention a theme and region. To do so, I still have to go to my theme's page and "Place block", which will in fact create a *new* config named block.block.MYTHEME_workflowtransitionform that represents the block config for my theme.

All of that being said, in the course of experimenting with this, I realized that I don't even understand what this block is supposed to be for. Even without having a "correct" theme-specific block config in my site, I still get the workflow transition field rendered by virtue of my form display config. If the block is intended to be an optional or alternate way of showing that form (perhaps in another context, or elsewhere on the node form page), then I would think it should be up to the site-builder to a) disable the field widget in the form display and b) place the block in the appropriate theme and region *which only they can know*. Does that make sense?

If there is a genuine need to install a block config when Workflow is installed, then I think we need to revisit the approach, and do something programmatically in a hook_install() helper routine that would a) determine what is the default theme, and b) create the block using Config API calls directly, rather than trying to import a yaml file.

I might be completely wrong here, but I really don't see what value this block config is adding to the module, and suggest we drop it entirely. Looking at the history of the file, I can see that it originated with the theme explicitly set to "bartik" which meant that it would only apply to sites using that theme (and again, to do what exactly?). Since it changed from that, it seems to have never been able to install successfully for anybody, so I don't think it'll be missed ;)

Indeed, I think we can just forget about adding the yml file.
The block is present, and usable if a site builder wants to add it.
I will remove the file.

@johnv: Sounds good! I'm glad I wasn't missing something about this block, and we have a way forward :)

The block config is removed.

I now think that that the other optional config for Action should be removed, too.

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