Do not remove the layout-builder-block css class

Hey @john-pitcairn, I'll take a look in a few days.
There shouldn't be any pitfalls, to doing this update.

Which theme are you using with the LBL module?

Making this change means any other theme that overrides the layout builder lock css rules for padding or pointer will probably need to update their rules to be more specific as well - though they could just override the library entirely to avoid that.

I'm using a custom front end theme. We modify the layout builder css a lot to make it match the page view. This is a simple example of what we will do for a locked section:

Hi @Panchuk, can I help you check and test this issue?

@Chesterr feel free to take it

I checked and found no critical issues so I sent you an MR.

It also needs to not remove the class in prerender.

Like so. We can remove the for() loop entirely.

I also used a less specific selector than .layout-builder-lock.layout-builder-lock to be a bit friendlier to themers.

Ah we do need to remove the .js-layout-builder-block class. That will allow themes to target .layout-builder-block, but should prevent any js actions (which should be targeting the js- class).

I think anyone using layout builder lock and customising the render element in css or js may want to have eyes on this. It's possible somebody may be relying on the absence of the .layout-builder-block class.

Thanks for MR guys, it will be merged into the development branch after tests.

The MR has a conflict with the target branch.

I've updated the merge request, it's now ready to be merged. The tests have passed, but there is a stylelint warning. I'm not sure why it's showing up, as the log points to the 'padding' property, which seems correct to me.

The style link issue was fixed in the last merge request.

Class removed, tests passed -> no reason not to mark it as RBTC.

Solved coding standards issues and reviewed as part of initiative #LutskGCW24

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