- πͺπΈSpain rcodina Barcelona
I ended up here because I'm doing a migration from core 9.5.11 to 10.1.5. On 9.5.11 we had Adminimal theme as admin theme and now we are enabling and configuring the Claro theme. The enabled Claro blocks are all set in yml config files. The problem is that when I import the configuration using customer's environment database the following error shows up:
In EntityStorageBase.php line 519: 'block' entity with ID 'claro_footer' already exists.
Using patch on #6 it avoids the import error. However, the blocks we have set in yml files doesn't get imported. Moreover, If do a "drush cex", it deletes the claro blocks I had defined on those files:
[notice] Differences of the active config to the export directory: +------------+-----------------------------------------+-----------+ | Collection | Config | Operation | +------------+-----------------------------------------+-----------+ | | block.block.claro_breadcrumbs | Delete | | | block.block.claro_content | Delete | | | block.block.claro_messages | Delete | | | block.block.claro_local_actions | Delete | | | block.block.claro_page_title | Delete | | | block.block.claro_primary_local_tasks | Delete | | | block.block.claro_secondary_local_tasks | Delete | +------------+-----------------------------------------+-----------+
Why they get deleted?
- First commit to issue fork.
- Merge request !11926Do not call block_theme_initialize() during config sync β (Closed) created by thejimbirch
- πΊπΈUnited States thejimbirch Cape Cod, Massachusetts
Added tests and got everything to green. I used AI to help me put this together as I am still pretty green to writing tests.
The 3 tests are:
testNoBlocksCreatedDuringConfigSync
Verifies that block_themes_installed() does not create blocks during a config sync.testBlockHooksModulesInstalledDuringSync
Confirms BlockHooks::modulesInstalled() avoids block creation during config sync.testBlockHooksModulesInstalledWithoutSync
Ensures BlockHooks::modulesInstalled() does create blocks when not syncing. - πΊπΈUnited States thejimbirch Cape Cod, Massachusetts
Adding Needs tests tag back in. I am awful at this. If I attempt again, I will assign it to myself but if anyone want to work on this, I will thank them profusely.
- π¨πSwitzerland berdir Switzerland
You weren't far off, had to debug through it as well. kernel tests are hard, there are always hidden subtle things that do not match a default setup.
In this case, some issues were:
* there already were some blocks that were created as claro has default blocks so I emptied that, a test theme might be better for this.
* And then the test passed but for the wrong reason, because no default theme was set in the kernel test, that doesn't happen automatically, so had to that.added a second test where we expect the initialize, refactored things to initialize shared things in setup, also use invoke() instead of calling the function as this will move to OOP soon.
- πΊπΈUnited States thejimbirch Cape Cod, Massachusetts
Thanks for the work, the explanation and the inline comments. I made one more minor change to fix coding standards and now all the tests are green. Removing Needs tests tag and I will add a change record.
Noting this should also close π Claro installed by recipes has incorrect block config Active
- πΊπΈUnited States phenaproxima Massachusetts
This is a straightforward bug fix and the tests prove that the bug is, in fact, tested.
- π³πΏNew Zealand quietone
Setting to NW because the test added here is failing.
- πΊπΈUnited States phenaproxima Massachusetts
I refactored the test for clarity, but didn't really change what it does. Restoring RTBC here, since we'd really like this in 11.2. Feel free to send it back to NR for a separate set of eyes if that is unpalatable :)
Looks like the change to
Drupal\Hook\BlockHooks::modulesInstalled()
does not have tests? Was this intentional?If not, it probably could be set up as a similar kernel test where a the block
modules_installed
hook is invoked on a profile in both syncing and non syncing cases to make sure blocks are and aren't added to installed themes correctly.If there's urgency to get this in, maybe that test can be a follow up (or the modulesInstalled change reverted), if technically scope is about theme install only.
- π¬π§United Kingdom alexpott πͺπΊπ
Let's do a similarly hacky test for modules_installed... it's all pretty side-effecty anyway.
- πΊπΈUnited States nicxvan
+1, I added a CR for the change in behavior and reviewed the test too.
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
This is a bug and there are no BC changes, I think this is fine to go in during a patch release so removing the target tag.
Requeued the failing test
Saving issue creds -
larowlan β
committed fc4cdce5 on 11.2.x
Issue #3182716 by thejimbirch, phenaproxima, primsi, alexpott, berdir,...
-
larowlan β
committed fc4cdce5 on 11.2.x
-
larowlan β
committed 68131d92 on 11.x
Issue #3182716 by thejimbirch, phenaproxima, primsi, alexpott, berdir,...
-
larowlan β
committed 68131d92 on 11.x
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Committed to 11.x and backported to 11.2.x
I think as this is a bug fix it could also be backported further. Setting to Patch to be ported to have branches created for 10.5/10.4 and 11.1
Thanks all
Published change record, which we may need to update if we backport
- πΊπΈUnited States smustgrave
Could this be a breaking change if backported?
Could this be a breaking change if backported?
I'm not seeing it, as long as the CR is updated to point at the right version.
- πΊπΈUnited States dww
π Copy block configuration from admin theme when enabling an admin theme Active is at least related, if not duplicate.
- π¬π§United Kingdom alexpott πͺπΊπ
This is going to save time during config import because the config import will delete all the blocks created by block theme initialize. This is why we've not noticed it till recipes because that's using the cofig sync flag to control what the module installer is doing.
- πΊπΈUnited States smustgrave
The gitlab diff in 11.1.x looked weird, nothing from the reroll but gitlab just noting
But appears to be good backports.
- πΊπΈUnited States thejimbirch Cape Cod, Massachusetts
Thanks for the RTBC @smustgrave. Itβd be great to see this backported.