Display title setting has wrong schema type

Migrating Pittsburgh 2023 to Pittsburgh2023 tag for cleanup

Tried re-rolling patch. Please review

Seems reroll caused failures. And should target 11.x

Added Reroll with respect to 11.x

Will let the tests finish but don't think the reroll was correct. Look at the file sizes. Almost tripled in size.

The last submitted patch, 28: 2544708-28.patch, failed testing. View results →

@smustgrave, Added reroll patch against 11.x with respect of #26, As Bartik and Seven theme are not the part of D10, 11, So below configurations are not part of this reroll, Please have a look and advise If this is a correct one.

core/profiles/standard/config/optional/block.block.bartik_account_menu.yml
core/profiles/standard/config/optional/block.block.bartik_breadcrumbs.yml
core/profiles/standard/config/optional/block.block.bartik_content.yml
core/profiles/standard/config/optional/block.block.bartik_footer.yml
core/profiles/standard/config/optional/block.block.bartik_help.yml
core/profiles/standard/config/optional/block.block.bartik_main_menu.yml
core/profiles/standard/config/optional/block.block.bartik_messages.yml
core/profiles/standard/config/optional/block.block.bartik_powered.yml
core/profiles/standard/config/optional/block.block.bartik_search.yml
core/profiles/standard/config/optional/block.block.bartik_tools.yml
core/profiles/standard/config/optional/block.block.seven_breadcrumbs.yml
core/profiles/standard/config/optional/block.block.seven_content.yml
core/profiles/standard/config/optional/block.block.seven_help.yml
core/profiles/standard/config/optional/block.block.seven_messages.yml

Seemed to have failures.

Rerolled the patch - note that umami profile and olivero adds weight to this change as there's a number of additional block configs that required updating.

Hiding patches as work has switched to MR 4729 which is on 11.x

Moving to NW for CC failure.

Am confused as the patch sizes have shifted each patch. So not sure if things were being removed or added.

Tagging for issue summary for what is being fixed.

@smustgrave stuff is being added to the merge request. Turns out there are a LOT of tests and config for blocks, lots of which set the label_display, hence the merge request growing.

welly → closed merge request !4729

welly → closed merge request !5068

welly → closed merge request !5069

welly → closed merge request !5071

Sorry about the mess above! I'm still learning this new system.

I've got most of this done now, but having a problem with some tests passing, which you can see here - https://git.drupalcode.org/issue/drupal-2544708/-/jobs/202425

Would welcome some advice on how to get those tests passing. I believe it will be because the block config in the config tarball will have the old schema but not 100% sure how to update that.

I'll put this into "needs review" so we can get some eyes on it but appreciate it's not quite ready!

Test fails because of 'type' issue, Try to fixed that.

The changes you made to MessageViewBuilder.php and LayoutBuilderEntityViewDisplay.php I'm pretty certain are not correct although the other two ()help.post_update.php and MigrateBlockTest.php) look to have been missed. The failing tests are update tests which need a correct update hook - the one I added isn't quite correct. Will be looking at this on Friday and hopefully will be able to get this passing all tests! :-)

Seems there's still work to be done.

@welly As mentioned in #49, reverted the file changes for 'MessageViewBuilder.php' & 'LayoutBuilderEntityViewDisplay.php'. During the investigation last I have added those, but now its reverted and try to fix the remaining tests.

Adding the configuration schema tag.

Have hit a bit of a wall with these tests.

Failed tests I'm coming up against are the following:

1. https://git.drupalcode.org/issue/drupal-2544708/-/jobs/381558#L1695

I'm struggling to see where the string type variable is coming from. When I put breakpoints into the code, I can see that the config value for core.entity_view_display.node.page.default:third_party_settings.layout_builder.sections.0.components.aeb0f8ae-7f1a-4d65-aaeb-c26ce56fa27d.configuration.label_display is set to "0". I just don't know where that is coming from.

It doesn't seem to be here: https://git.drupalcode.org/issue/drupal-2544708/-/blob/2544708-display-t...

2. https://git.drupalcode.org/issue/drupal-2544708/-/jobs/381558#L818

This seems to be unrelated to my PR so again, struggling to see how this is failing. If I check

core/tests/fixtures/config_install/multilingual.tar.gz there doesn't seem to be any deleted views configs so again, struggling to understand how this is failing.

3. https://git.drupalcode.org/issue/drupal-2544708/-/jobs/381557

All the tests are passing so not sure what the fail is here.

ERROR: Job failed: pod "runner-tdd8nzs6-project-119803-concurrent-1-w67bvbwo" status is "Failed"

And there are some failed tests in the Functional Javascript tests which I'll come back to as I've not looked at them too closely yet.

So any advice would be much appreciated!

Going to look at the modified fixtures and see if they need repairing....

Looks like there is still a failure in TimestampFormatterSettingsUpdateTest, but that is the only remaining failure, that should be fixed.

So I've spent a bit of time trying to resolve this TimestampFormatterSettingsUpdateTest error without success. When that test runs, the runUpdate method call in testPostUpdateTimestampFormatter fails with the following assertion failures

There should be no errors in configuration 'core.entity_view_display.node.page.default'. Errors:

Schema key core.entity_view_display.node.page.default:third_party_settings.layout_builder.sections.0.components.b961467b-96b6-47da-baab-fec95554f963.configuration.label_display failed with: variable type is string but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData
Schema key core.entity_view_display.node.page.default:third_party_settings.layout_builder.sections.0.components.89467df8-8ca7-48a6-9f92-8292f125dd36.configuration.label_display failed with: variable type is string but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData

Failed asserting that Array &0 (
    'core.entity_view_display.node.page.default:third_party_settings.layout_builder.sections.0.components.b961467b-96b6-47da-baab-fec95554f963.configuration.label_display' => 'variable type is string but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData'
    'core.entity_view_display.node.page.default:third_party_settings.layout_builder.sections.0.components.89467df8-8ca7-48a6-9f92-8292f125dd36.configuration.label_display' => 'variable type is string but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData'
) is true.
 

I've tried to debug where the config change is occurring that is inserting those two components but I've had absolutely no success. I'd like to get this issue over the line but this one has me stumped and I've hit a wall.

Would appreciate any help with this one!

Thank you

wim leers → credited longwave → .

Surfaced again at 🐛 Cannot place a code component with an image prop Active , kudos to @longwave for connecting it to this issue!

I opened a new MR based on the old MR because both rebasing and merging ended up with way too many conflicts to resolve, I don't think this is complete by any means but it's a start.

The update path test is running into 🐛 Fix bugs in update path surfaced by config validation Active where block.block.claro_help_search does not have a UUID and so fails to save.

longwave → changed the visibility of the branch 2544708-display-title-type-fix to hidden.