Disables newly added blocks from displaying by default

Can you remember how this worked in D7? Without a test I guess it is correct behaviour as default value should be FALSE.

Can you share a patch with test if something is really broken, please?

I had the same problem.

It not only causes a problem for new blocks, but if you save an existing block (say an out-of-the-box system block), then that block will not display either.

Fortunately this workaround works, but it's only a work-around:

return TRUE;

It seems like after you enable the PHP filter module blocks won't display unless you check the "negate the condition" block in the PHP section. I fail to see why enabling this module should affect the entire block system.

I ran into this same problem with the new blocks not displaying after I turned on the PHP Filter module unless I put "return TRUE;" in the PHP field of the block.

In Drupal 7, the PHP Filter functionality was a radio button option to choose if you wanted to show block "Pages on which this PHP code returns TRUE (experts only)" as part of the "Pages" tab. Drupal 8 appears to make it a standalone "PHP" tab, which might be why the logic to use it isn't the same. It is not ideal to put "return TRUE;" in every block as a workaround.

Another strange thing I noticed is when uninstalling the PHP Filter module, it warns me that it will actually delete EVERY block I added to the site after installing PHP Filter module, regardless of whether or not I actually used the PHP field on the block. I don't believe the module should adversely affect every block on the site once it is installed.

Just wanted to chime in and say that I too have the same problem.

Comment #5 was very helpful. Thank you for that. I can handle checking a box for now, but I do not believe this behavior should exist. I have wasted a lot of time by re-installing everything one-by-one to troubleshoot this issue.

Also, as beefheartfan stated, I too noticed that the blocks are "deleted" when uninstalling the module. However, the block's placement in the block layout is the only thing that actually gets deleted as far as I can tell. The block itself continues to exist and you just have to place it within the block layout page again. This is an annoyance, but at least it doesn't actually delete them. Hopefully that can be fixed as well.

Everything in this thread is absolutely correct. A brief summary of the steps to replicate the issue are:

- Install/enable the module
- Create or edit a custom block leaving all settings at their default
- Place the block on your page
- The block doesn't show

This definitely should not be the default behavior.

I think I understood why this happens. I'm wondering why this should only happen to new blocks.

In past we had the Pages tab with 3 radios. Before you have not selected Pages on which this PHP code returns TRUE (experts only) the PHP code never run. Now with D8 the text area is empty and evaluates to FALSE (i guess). As the PHP visibility is active from the moment when you enable the module you end up with blocks not shown.

Two solutions are there. I have just added defaultConfiguration() to the condition plugin and we can set the default of 'php' to return TRUE; or we add conditions to evaluate() function to check if the textarea is empty and make this evaluating to TRUE by default.

Need to think about this and debug a bit more, but logic wise this makes sense to me. No idea how this has slipped through when the module was in core last time. I'm also not sure why this does not affect existing blocks.

I think this are our options here and I guess V2 is the better one as does not something magic under the hood. Otherwise - performance wise V1 is better I think.

Feedback is welcome...

Please provide some feedback if it works for you.