Skip to content

Decouple PostLockedModal from Editor component #70537

@ashfame

Description

@ashfame
Member

What problem does this address?

Right now, PostLockedModal is considered a crucial component of the editor and hence its tightly coupled. But with upcoming collaborating editing work in Gutenberg, this would change and since initially this work would be done outside in a plugin, we need the ability to cleanly unhook PostLockedModal.

What is your proposed solution?

Decouple it and make it use Gutenberg's API to register itself registerPlugin(), so that externally, we can cleanly remove the component.

Activity

added
[Status] In discussionUsed to indicate that an issue is in the process of being discussed
and removed
[Status] In discussionUsed to indicate that an issue is in the process of being discussed
on Jun 27, 2025
t-hamano

t-hamano commented on Jun 27, 2025

@t-hamano
Contributor

Thanks for the suggestion.

initially this work would be done outside in a plugin

From what I understand, collaborative editing will be developed as an experimental feature within the Gutenberg plugin.

See https://github.com/WordPress/gutenberg/pull/68483/files#diff-f08775783077295e710976c98cf7c33a043dac17978aedd634ee0eb7021e80ce.

Additionally, this discussion may be helpful: #65012

ashfame

ashfame commented on Jun 27, 2025

@ashfame
MemberAuthor

Hi, I am aware of the context. There are two parallel efforts in exploration currently which would require this. Hence, created this issue.

Mamaduka

Mamaduka commented on Jun 30, 2025

@Mamaduka
Member

Since the initial work will be done by a separate plugin that needs to replace the component, it may be better to use a filter. Something similar to editor.PostFeaturedImage.

Pros

  • It's easier to replace the component, and consumers can ensure that their replacement is used by using a higher hook priority.
  • Easy to prevent multiple locked modal handlers.

Cons.

  • Filter is less semantic compared to register/unregister APIs.
  • Consumers can sometimes abuse open APIs, such as hooks, and render something unrelated to the intended purpose.

P.S. I'm less worried about the cons; worst-case scenario, we can deprecate the PostLockedModal and filter when a better API becomes available.

cc @WordPress/gutenberg-core

youknowriad

youknowriad commented on Jul 1, 2025

@youknowriad
Contributor

I'm ok with filters but I think it needs to be limited to the Gutenberg plugin (using the variable) to avoid shipping the filter to Core at the moment.

Mamaduka

Mamaduka commented on Jul 1, 2025

@Mamaduka
Member

I'm ok with filters but I think it needs to be limited to the Gutenberg plugin (using the variable) to avoid shipping the filter to Core at the moment.

That makes sense 👍. I'll put the PR together.

self-assigned this
on Jul 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

[Feature] ExtensibilityThe ability to extend blocks or the editing experience[Package] Editor/packages/editor[Status] In ProgressTracking issues with work in progress[Status] In discussionUsed to indicate that an issue is in the process of being discussed[Type] EnhancementA suggestion for improvement.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    Participants

    @Mamaduka@youknowriad@ashfame@t-hamano

    Issue actions

      Decouple `PostLockedModal` from `Editor` component · Issue #70537 · WordPress/gutenberg