Render block entities, not plugins unless all plugin settings can be configured

Just had a look into the "Place block" UI in core which works similar and saw that they're filtering out some other blocks, which we should also do, I guess. I'll add that as MR.

But the key point is, that the "Webform" entry also exists there and the webform entity is selected in the block configuration on the next page. So we're missing that step entirely.

Okay so finally my result is, that the current options don't make sense as long as you're not able to fully configure all configuration values of the block plugin.

That would mean we would have to implement the whole block plugin settings (form and save) logic from blocks to be able to provide all required settings. That will be a bunch of work!

Until that's possible, we should change the selection to

• Block entities (allows to select all block entities existing in the default theme - so they can be configured there, visible or in a hidden region)
• Views (can be kept as-is)

Would be super cool to be able to fully configure block plugins within this module, but that will be a lot more work than the whole module currently has.

As the current plugin logic can only work for very simple blocks, we should replace it like I implemented (and tested) in the MR.

At least when implementing 📌 Write tests Active we would have found out that the current logic only works for simple cases, not even for webforms or other blocks with required settings.

We'll need to create a separate version for this, as a breaking change can't be prevented sadly. An update hook should inform the (currently 13) users about the required manual change.

Back to NW, I forgot to implement the update hook to inform about the BC!
Like in 📌 Change ouibounce library structure to allow npm-asset / bower-asset installation Fixed

Text for the update hook:

Ouibounce Exit Modal block selection logic breaking-changed (BC) in 4.x! Downgrade to 3.x for now and read the issue for details or reconfigure your Ouibounce Exit Modal block settings. Custom HTML and views are not affected! See https://www.drupal.org/project/ouibounce_exit_modal/issues/3358189 🐛 Render block entities, not plugins unless all plugin settings can be configured Needs work
No database changes were made from 3.x to 4.x so you can up-/downgrade without fear, but reconfigure the Ouibounce block settings.

Rebased on 4.x and added the update hook. The rest of the code looks fine! Please review the update hook, if it functions as desired!

Perfect, thx :)

Merging and tagging!

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

Due to the changes made in this issue, Block plugins do not appear in version 4.0.0-rc1. All block plugins created under "[MODULE]/src/Plugin/Block" disappeared from the list. Please do not remove an existing function from the module. It can be added, but don't remove.

@lonalore thanks, but that change was needed to make a fix. So we created a new major release (4.x) which allows breaking changes. Please use 3.x for now, if you need the old behavior. But I think it will be better to migrate over.

We added an update hook to inform users, who didn't read the release notes.
https://git.drupalcode.org/project/ouibounce_exit_modal/-/commit/0d5cd28...

Please feel free to implement an update hook or suggest improvements to the update hook or release notes. This won't be reverted.

@lonalore PS: Sorry I didn't see / recocgnize, you're the original maintainer. My appologies.
I hope you see the reasons for the BC in 4.x and why we created the new major version.

So of course we can for example keep the 3.x as alternative recommended branch, for example. But for the future of this module the reasons for the changes in 4.x outlined above should be weighted higher from my perspective.

Looking at https://www.drupal.org/project/usage/ouibounce_exit_modal → the Drupal 8+ usage is quite low, so I think it's still the right time to do this.

I don't think it's a fix if we throw out an existing function. The update note doesn't mention that block plugin support has been dropped from the module.

Thanks @lonalore, so you'd suggest just re-adding the block plugin functionality plus keeping the new functionality?
I wonder if that wouldn't be very confusing for users. How should that be displayed in the UI? As separate group in the select?

Another option would be to fork the module, instead of creating 4.x with that functionality or using a hook and submodules to split it. The analysis can be found in #4 why we decided to make that change.

Any suggestions for the update hook text change then?

Yes, block plugins could be managed in a separate group in the select list. If the function is returned to the module, there is no need to change the update message. Thank you!

@lonalore still on my list, but very busy currently, sorry.