Conflict with SureCart blocks?

When creating a checkout form with SureCart (WordPress Ecommerce For Creating Fast Online Stores – By SureCart – WordPress plugin | WordPress.org), you can add a number of their dedicated blocks to your form.

However when Cwicly is activated, it changes which blocks are available to you.

Here’s a demo: Loom | Free Screen & Video Recording Software | Loom

The set of blocks that are available to you when Cwicly is enabled are what you normally see when outside the scope of editing a checkout form.

Not sure if this is a Cwicly thing, or if I should bring it up with SureCart instead?

Hello @sunny,

That’s interesting.

It seems that SureCart is not registering the blocks on the server side, which means that we have no way of telling the editor which blocks to allow/remove (we do this because of the Role Editor functions).

The reason we check things on the server side is to make sure that users without the sufficient capabilities don’t have a way to activate the blocks inside the editor (if we remove the blocks on the client side, they can easily be reactivated with a single line of code).

Might be worth asking SureCart if they can register SureCart on the server. If not, then I’ll see what we can do to include blocks that aren’t.

Thanks for the quick reply!

I just passed this info on to their developer. I’ll let you know what they come back with :slight_smile:

@Louis Here’s their response:

"Yes, SureCart is registering blocks using JavaScript since there is no Server Side render callback. It seems that Cwicly will want to handle this use case as many blocks are not registered on the server. This is not a requirement for block registration.

If they want to limit blocks by role, they will want to use the canUser function to check the current users role:

And filter the registerBlockType in Javascript:

Block Hooks | Block Editor Handbook | WordPress Developer Resources"

1 Like

Hi @sunny,

Thanks for sharing that.

It’s definitely not a requirement, but removes all server side filtering capabilities (not just allowing/disallowing blocks) that powers WordPress blocks.

Anyway, thanks for bringing this up. We’ll get something sorted out in the next day or so :+1:

1 Like

Awesome. Thanks as usual.

(I passed along your feedback as well).

I’ll add that it’s a good point they make about blocks being registered client-side only, so thanks again!

1 Like

Hello @sunny,

Thanks for the report once again.

This should be fixed in 1.2.1.8

1 Like

Indeed it did. Thank you!

@Louis Actually, it looks like I can no longer use Cwicly blocks anywhere on the site (both local and my live site).

In the Blocks manager, they appear as hidden and it doesn’t let me toggle them on:

Happens even with all other plugins disabled.

Any ideas why that would be happening?

@sunny Thanks for reporting this. Definitely something went wrong with the last update.
We have just pushed a fix with 1.2.1.8.1.
So sorry for this.

2 Likes

Looks to be all good now!

1 Like