The Popup Controls block panel is causing other blocks to fail loading

[krugazul]

Describe the bug

The PUM block editor assets is causing an issue with the WooCommerce Products by Category block. Causing the block to fail loading. Specifically blocks that load PHP. This is pretty much all of the WC blocks.

Site information

Popup Maker version: 1.11.1
WordPress version: 5.5 & 5.4.2
PHP version: 7.4.8
WooCommerce version: 4.3.2

Expected behaviour

The block should load, without any errors.

Current behaviour

The Block starts to load, then fails and complains about the attributes being missing.

Steps to reproduce

1. Edit a page using the block editor.
2. Add a WooCommerce Block to the page.

Errors

Error loading block: Invalid parameter(s): attributes

Additional context

I tested this by commenting out the line including the PUM_Admin_BlockEditor class in Admin.php

[danieliser]

I believe these are all dynamic content blocks. If so this may be related to a Gutenberg issue WordPress/gutenberg#16850

Along with multiple other related issues:

• REST Block Renderer: Attributes registered using blocks.registerBlockType filter fails. WordPress/gutenberg#15935
• Common Block Functionality WordPress/gutenberg#15450
• REST Block Renderer: Accept the className attribute by default and add a filter WordPress/gutenberg#13249

Even the built in className field will break things in this case, so I'm not sure there is actually anything we can do reliably at this time other than have you disable our block editor functionality by some means.

[crpeng]

How do I disable Popup Maker block editor?

[danieliser]

@crpeng - Are you sure you didn't enable it under Popup Maker -> Settings. Disabled by default currently.

[ndiego]

@danieliser I just stumbled on this ticket as I have been dealing with the same issue. While not ideal, you can "register" the custom attributes in PHP, as well as in JS like you normally would, and this appears to resolve the issue for blocks that are using the ServerSideRender component. I found this workaround from the ticket: WordPress/gutenberg#16850, which you mentioned above. I am currently using it in two projects and have had no other issues. Hopefully this will be fixed in core at some point...

[fpcorso]

This same issue is also affecting blocks from Gravity Forms and All-in-one gallery as well as several other smaller plugins that have been reported. Changed the name of this issue to be more general.

[danieliser]

This occurs even if your block only uses the built in "classes" field unfortunately.

I like that we might be able to work around it, but ultimately this needs to be fixed properly in core, was hoping for sooner than later, but does not appear they are even taking it seriously. That said they did change quite a bit in dynamic block rendering for 5.6, so we may need to retest this as some of the unrelated changes might impact this as well, even though there has been no movement on the actual issue itself.

[jeffdaigle]

Just commenting to register my vote for adding a workaround to PUM rather than waiting for a fix in core. This is affecting several of my clients and is a fairly serious issue.

[danieliser]

@jeffdaigle Sorry should have been more clear, with their lack of action over the last few months I don't see any choice but for us to move forward with some hacks on our end unfortunately. But I do have concerns that won't be far enough due to the quite frequent usage of the built in CSS classes field that every block has by default.

Last I checked even with our plugin disabled, using a dynamic block and adding a custom CSS class results in the same issue.

[jaredatch]

Any updates on the hacks to work around this?

The WPForms block is broken (among many others) when users are using PopupMaker.

We've been tracking/patiently waiting for this to get resolved for 9 months, but the scale of the issue has kept increasing and is a burden on our support team.

If we can't get this resolve we're going to have to pull all our recommendations for PM 😞

[danieliser]

@jaredatch - The workaround was added a while back via #835. There was no “hack” we could do that would make it work with all blocks due to limits in the block editor at this time. They currently require predefining all attributes and there is no reliable way to filter in extra ones on custom 3rd party blocks without manually creating that hack for each 3rd party provider, something we can’t / won’t be doing.

In the mean time you can just exclude any blocks that are having issues with a simple filter.

Take a look at that solution and let me know.

[jaredatch]

So we should add this filter inside WPForms excluding our block? Will this affect our forms block?

Right now we are fielding many support request each week from users who can't use our block when PUM is installed (often based on our own recommendations), so you can see the bind that places us in 😬

[danieliser]

@jaredatch If you add your blocks to that filter it won’t have any negative impacts. It just tells our code that adds extra fields to skip adding those fields to your blocks. The bug in the block-editor essentially makes it so blocks with dynamic server side rendering fail validation because the extra field data attribute is present.

Simply preventing the field from showing in the first place prevents its from appending its value as well.

[ndiego]

I forgot I was subscribed to this issue and just wanted to chime in. I was able to solve this issue by "registering" the custom fields/attributes on the server as well as in JS. Here is an example from one of my plugins. This method works pretty flawlessly in my experience and defines the attributes for every block, including the WPForms block and any other dynamic block.

Anyway, just thought I would share. But if you already tested this route and found substantial issues, let me know! 😉

[danieliser]

@ndiego Is the $block there a reference variable? I don't see you passing back or loading globals. How are the changes in that loop saves back to global state?

[ndiego]

Haha you bring up a very good point. I always get a bit confused with the intricacies of PHP classes (scope, instances, etc.), but I believe this is updating the $registered_block_types variable in the WP_Block_Type_Registry class with the custom attributes. Here is the code reference. Full transparency, I pulled this code from here. Without this though, you get the dreaded "Error loading block: Invalid parameter(s): attributes" error for whatever custom attribute you are adding.

[danieliser]

@ndiego Much appreciate you chiming in, applied that patch and it does seem to be working without having to exclude blocks. Good save.

Will be in this weeks upcoming v1.16 update.