Make WordPress Core

Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#64272 closed defect (bug) (fixed)

Block visibility: new support key conflicts with Block Visibility plugin

Reported by: dlh's profile dlh Owned by: desrosj's profile desrosj
Milestone: 6.9 Priority: normal
Severity: normal Version: 6.9
Component: Editor Keywords: has-patch has-unit-tests dev-reviewed commit
Focuses: Cc:

Description

The Block Visibility plugin predates the new block hiding functionality in WordPress 6.9, as was discussed early in the new feature's development.

While the current core functionality and the plugin's functionality can complement each other, they conflict in their use of the blockVisibility block support key.

The practical consequence of this conflict that I experienced is that isn't possible to turn off core's block-hiding functionality for a particular block (via register_block_type_args) while also allowing the Block Visibility plugin to apply to that block. The blockVisibility support key will be set to true by the plugin, and so core's UI will be turned back on. As things stand, when 6.9 is released, my sites that use the plugin would begin to see two ways to hide a block that behave differently, and as far as I can tell, I can't prevent it.

It would be disappointing for this conflict to make it into core since it was an avoidable conflict and since it's not too late to fix it. The original Block Visibility plugin has 40,000 installations, which might not be large, but it's also not small. But, if that's what's going to happen, I think it would be respectful to acknowledge it.

Change History (13)

#1 @jorbin
3 months ago

  • Milestone changed from Awaiting Review to 6.9

Moving to 6.9 for visibility. Not sure if this should be reported in https://github.com/WordPress/gutenberg/ instead though cc/ @cbravobernal

Related to: #64061.

#2 @cbravobernal
3 months ago

Thanks for the ping @jorbin . It's indeed an issue. I created an issue on Github so we can discuss a possible solution:

https://github.com/WordPress/gutenberg/issues/73403

#3 @wildworks
3 months ago

#64276 was marked as a duplicate.

#5 @wildworks
3 months ago

Unfortunately, the attached patch cannot be tested until the next Gutenberg sync is run.

This is because the old blockVisibility key is still used in block.json, which is updated by the Gutenberg sync.

#6 @palak678
3 months ago

I appreciate you outlining the problem. I tested this locally, and the issue persists.

Many blocks have blockVisibility set to true when the Block Visibility plugin is active. As a result, even if I try to disable the core visibility UI using register_block_type_args, it turns it back on.

This indicates that the plugin's visibility UI and the core visibility UI appear simultaneously. Users will find that confusing, and developers are powerless to stop it.

The plugin is utilized on about 40,000 websites and predates the new core feature. It would be beneficial for site owners and plugin developers to at least acknowledge the conflict in order to get ready for WordPress 6.9.

Kindly see the below image :

https://postimg.cc/gallery/cSfkmvm

#7 @wildworks
3 months ago

  • Owner set to wildworks
  • Resolution set to fixed
  • Status changed from new to closed

In 61285:

Editor: Rename block visibility support key to visibility.

Renames the support key to visibility to avoid conflicting with the Block Visibility plugin's existing blockVisibility key.

Follow-up to [61014].

Props andrewserong, annezazu, cbravobernal, dlh, jorbin, joen, johnjamesjacoby, palak678, ramonopoly, talldanwp, tyxla, wildworks.
Fixes #64272.

#8 @wildworks
3 months ago

  • Keywords dev-feedback added
  • Resolution fixed deleted
  • Status changed from closed to reopened

I'd like to reopen this ticket according to the backporting process.

Dear @ramonopoly @andrewserong, could you confirm if it's OK to backport the patch to the 6.9 branch?

This ticket was mentioned in Slack in #core by wildworks. View the logs.


3 months ago

This ticket was mentioned in Slack in #core by welcher. View the logs.


3 months ago

#11 @desrosj
3 months ago

  • Keywords dev-reviewed commit added; dev-feedback removed
  • Owner changed from wildworks to desrosj
  • Status changed from reopened to assigned

[61285] looks good to backport.

#12 @desrosj
3 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 61288:

Editor: Rename block visibility support key to visibility.

Renames the support key to visibility to avoid conflicting with the Block Visibility plugin's existing blockVisibility key.

Follow-up to [61014].

Reviewed by desrosj.

Props andrewserong, annezazu, cbravobernal, dlh, jorbin, joen, johnjamesjacoby, palak678, ramonopoly, talldanwp, tyxla, wildworks.
Fixes #64272.

#13 @ramonopoly
3 months ago

could you confirm if it's OK to backport the patch to the 6.9 branch?

Sorry, just saw this. Looks like @desrosj was on the case. Thank you!

Note: See TracTickets for help on using tickets.