Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove ability to add a template part in the post editor #44397

Closed
annezazu opened this issue Sep 22, 2022 · 8 comments · Fixed by #44480
Closed

Remove ability to add a template part in the post editor #44397

annezazu opened this issue Sep 22, 2022 · 8 comments · Fixed by #44480
Assignees
Labels
[Block] Template Part Affects the Template Parts Block [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release

Comments

@annezazu
Copy link
Contributor

Description

Remove ability to add a template part in the post editor, including copy and pasting. This was previous in place #37157 but seems to now be allowed to add once more. I can replicate this with 6.1 beta 1.

Step-by-step reproduction instructions

  1. Use GB 14.1.1
  2. Open post editor
  3. Start to add a template part block however you'd like.
  4. Notice that you can.
  5. Deactivate Gutenberg
  6. Open post editor
  7. Try to add a template part block and notice you can't

Separately, notice that you can copy/paste a template part block from the template editor into a post editor, with or without Gutenberg installed, causing multi entity saving to appear in the post editor.

Screenshots, screen recording, code snippet

template.parts.mov

Environment info

  • WordPress 6.1 beta 1
  • Gutenberg 14.1.1 both activate and deactivated
  • TT2

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@annezazu annezazu added [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release [Block] Template Part Affects the Template Parts Block labels Sep 22, 2022
@annezazu annezazu moved this from Triage to Todo in WordPress 6.1 Editor Tasks Sep 22, 2022
@ramonjd
Copy link
Member

ramonjd commented Sep 26, 2022

I only got so far as to realize that rootClientId returns null at this point in the template part block init():

So the tests are failing and the filter will return true (allow the block to be inserted)

I can't see much that might have changed in the meantime since #37157 🤔 cc @adamziel who might know straight away

@Mamaduka
Copy link
Member

I think the filter stopped working after #42258 got merged.

Testing

  • ✅ The commit before merging the filter is working - 9620bae
  • ❌ The merge commit the filter stops working - 4f7c19e

It might be a good idea to audit other blocks that are using side-effects - navigation-link, query and post-terms.

@gziolo, any ideas why the filters might stop working?

@gziolo
Copy link
Member

gziolo commented Sep 26, 2022

@Mamaduka, I guess it means that the filter should get applied globally rather than only when the Template Part gets registered. It might be related to the order of execution, too.

@adamziel
Copy link
Contributor

I can't see much that might have changed in the meantime since #37157 🤔 cc @adamziel who might know straight away

Unfortunately I don't :( @Mamaduka and @gziolo seem to be on the right track, though. It sounds like canInsertBlockTypeUnmemoized receives null as rootClientId on some occasions. It would be nice to have some assertions in place, e.g. assert( rootClientId ) – that way we'd find such problems right away.

@Mamaduka
Copy link
Member

I guess it means that the filter should get applied globally rather than only when the Template Part gets registered. It might be related to the order of execution, too.

That might be the case for filter side effects. Would it be okay to add filters directly in the init.js file but outside the init method?

@gziolo
Copy link
Member

gziolo commented Sep 26, 2022

I guess it means that the filter should get applied globally rather than only when the Template Part gets registered. It might be related to the order of execution, too.

That might be the case for filter side effects. Would it be okay to add filters directly in the init.js file but outside the init method?

init.js exists only for 3-rd party usage when devs want to init individual blocks. In the case of WordPress core, we call init from `index.js.

I think I identified what has changed:

The filter from the block library got applied first, and then it would get overridden by the following version in post editor:

// Prevent adding template part in the post editor.
// Only add the filter when the post editor is initialized, not imported.
addFilter(
'blockEditor.__unstableCanInsertBlockType',
'removeTemplatePartsFromInserter',
( can, blockType ) => {
if (
! select( editPostStore ).isEditingTemplate() &&
blockType.name === 'core/template-part'
) {
return false;
}
return can;
}
);

Now, the filter registered with the block goes after. The fix should be as simple as moving the code above after registerCoreBlocks call in the file.

@Mamaduka
Copy link
Member

The filter from the block library got applied first, and then it would get overridden by the following version in post editor

@gziolo, I'm not sure if that's the case.

Even if I move the edit post filter after the registerCoreBlocks call or comment it out, I can still insert the Template Parts block.

@ramonjd
Copy link
Member

ramonjd commented Sep 27, 2022

The fix should be as simple as moving the code above after registerCoreBlocks call in the file.

Hmm, this appears to work for me, thanks everyone!

I've thrown up a PR just in case it works for everyone else too 🤣 #44480

@ramonjd ramonjd moved this from Todo to In Progress in WordPress 6.1 Editor Tasks Sep 27, 2022
@ramonjd ramonjd moved this from In Progress to Needs Review in WordPress 6.1 Editor Tasks Sep 27, 2022
Repository owner moved this from Needs Review to Done in WordPress 6.1 Editor Tasks Sep 27, 2022
@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label Nov 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Template Part Affects the Template Parts Block [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Projects
No open projects
6 participants