Blocks do not appear after being placed with the Rules module enabled (or other missing schemata for Condition plugins)

Hi @dbourrion:

What is the enabled theme?

Are there any errors in Drupal's log or the PHP log?

I have the some problem.
syslog is empty. Old blocks (located before) displayed.

I have the same problem.
I'm not able anymore to see new placed blocks in the layout, I can move the existing ones but cannot see any new added one. I've just upgraded to Drupal 8.2 then I've enabled the new "Place Blocks" module and later uninstalled it. I do not know if it is related to "Place Blocks" or not.
I also noted that, after adding a new block in admin/structure/block and saving the block config, I'm redirected to admin/structure/block/library/mytheme and not back to admin/structure/block.
I have the same result when using Bartik as theme and I have no error in the drupal log and in the system php log.

Regards
Oto Tortorella

This qualifies as major.

I have the same issue here.

Regarding the redirect after placing a block, there is an issue on that: #2794559: [regression] After placing a block and saving, you are directed to the block library (example: admin/structure/block/library/bartik) rather than to the block layout.

@catch and I discussed this. More information is needed from the affected sites but we think this should be critical based on reports.

Happy to provide further information and ready to test solutions!

@cilefen it seems to me odd that in the appearance of a lot of weird themes http://i.imgur.com/U1QKDeg.png
and in visable section very match new tabs http://i.imgur.com/OjHT9Ke.png

I can give you access to the site and ssh. If need, my email alexd73@gmail.com

Does this only occur after installing the Place Block module? If the module is uninstalled, can the blocks be placed again?

I just have the two themes that came with the installation. However, I also have a long list underneath "Visibility". Since this is the first time I used Drupal 8 I thought that's the way it's supposed to be?!

I don't have the Place Block module installed.

@alexd73 It seems you have $settings['extension_discovery_scan_tests'] = TRUE.

Re #13: Those extended conditions are from the Rules module.

Does every affected site have Rules enabled?

With Rules installed, placed blocks do not appear, and pre-Rules placed blocks disappear after being saved with Rules enabled, as they take on Rules visibility conditions.

In fact - Rules seemed to cause this problem. I uninstalled rules and can place blocks now!

The problem is still present also with Place Block Module uninstalled

This problem does not exist in 8.1.10 but does in 8.2.0.

Debugging this.

This is due to #2537732: PluginFormInterface must have access to the complete $form_state (introduce SubFormState for embedded forms). Now just to find out why!

Not quite the same, but #2800951: EntityField block broken on 8.2 due to SubFormState changes and #2798261: Using $form_state->getValue() in BlockBase's blockForm throws "subform and parent form must contain the #parents property" exception also look like fallout from that change.

Rules creates the problem, I confirm that uninstalling it solves.

In \Drupal\Core\Condition\ConditionPluginCollection::getConfiguration(), we compare the $default_config to the $instance_config.
This was failing for all rules conditions, for two reasons.

One, rules provides NO config schema for it's plugins. Core does for all its own, see node.schema.yml line 108, which corresponds to \Drupal\node\Plugin\Condition\NodeType.

Two, \Drupal\block\BlockForm::validateVisibility() used to massage the 'negate' value the ensure the type is correct. This code was not updated in the SubFormState issue above.

This still needs tests, and Rules should add schema, but this fix works and is correct.

Here's an update path.

This looks reasonable, but yeah let's add test coverage.

Also discussed this issue with @xjm and @alexpott and we think it's worth putting out an early 8.2.1 for, probably early next week.

This is only solving a single special case. Any other Boolean config values in conditions will cause this same problem.
Working on a general solution.

This is an entirely new approach, so no interdiff.

Last PASS patch didn't actually include the test in the FAIL patch.

Wow, the specific browser test I added is completely unnecessary. Adding a schema-less condition plugin to block_test.module broke a ton of tests!

I'm not entirely suer about using sub pieces of schema in the way introduced in this patch.

+++ b/core/lib/Drupal/Core/Config/ConfigValueCaster.php
@@ -9,117 +9,47 @@
+  protected function initSchemaWrapper($data) {
+    $typed_config_manager = $this->typedConfigManager();
+    $definition = $typed_config_manager->getDefinition($this->getName());

If we pass name into here then we can get rid of the abstract getName() which will remove the oddity of getName on the condition plugin returning a config name.

Going back to the quick-fix in #25, plus tests. The config stuff was a bit heavy-handed.

@tim.plunkett - we can open a follow up to discuss further fall out and a better fix. Maybe the config changes are the right way but I wouldn't want to rush that. Or maybe a better way will occur to us.

The test failures in #2815829: Adding or editing a block through the UI saves the entity twice imply that a bigger fix is needed anyway, we can work on it there.

The fix in #37 will resolve the immediate issues and #40 outlines the existing followup. I think we are good to go here.

Committed/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!

That patch didn't include the upgrade path from #26.

After discussion with @catch, @cilefen and @xjm we decided to revert this and wait for upgrade path tests.

Also sorry everyone for the premature rtbc in #41 I should have spotted the missing upgrade path.

The patch adds the missing update path and provides a simple test that adds a block with missing schema and the incorrect config prior to running updates and runs them.

The fix may be mine, but the update path tests are all @alexpott, so I'm RTBCing the patch.

Thanks for the update path test.

Committed/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!

As of D8.6.4, this problem still exists.

I installed and enabled the rules module.

I changed a block configuration to specify block display on additional pages.

That block no longer appeared anywhere and no amount of attempting to adjust the block settings fixed the problem that the block would not appear anyway. Changing the block settings to appear on every page did not fix the problem.

--

Attempting to uninstall the D8 rules module then demands that all blocks touched by the rules module be deleted by the D8 rules module uninstall. Thus, uninstalling the D8 rules module then creates catastrophic configuration and content loss for the affected D8 site.

--

This is a critical problem.
It seems that the D8 rules module is not only unusable, the D8 rules module causes catastrophic configuration and content loss.

--

p.s. this critical problem required a rollback to the D8 site's previous day's automated daily backup (a very bad scenario)

Hi websiteworkspace,
If you do have this problem, you may need to create a new issue in the Rules issue queue, and reference it back to this one, because not many people will be seeing this issue now that it it closed.
Jonathan