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

Provide a way to manage wp_navigation posts from wp-admin #36126

Merged
merged 16 commits into from
Nov 5, 2021

Conversation

anton-vlasenko
Copy link
Contributor

@anton-vlasenko anton-vlasenko commented Nov 1, 2021

Description

The goal of this PR is to disable block editor for wp_navigation type posts (because it doesn't work with wp_navigation posts) and provide a way to mange wp_navigation posts from wp-admin.
Fixes #36036 (?).

How has this been tested?

  1. Create a new post using the block editor.
  2. Add a new navigation block.
  3. Create a new menu in your navigation block, add some menu items to it.
  4. Save the post.
  5. Go to Appearance -> Navigation Menus page.
  6. Click on the post to edit it.
  7. Make sure that you cannot edit the post's content (i.e., your menu). Content editor should not be visible.

Screenshots

Screenshot 2021-11-03 at 15 37 31

Types of changes

New feature

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • I've tested my changes with keyboard and screen readers.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

@anton-vlasenko anton-vlasenko changed the title [WIP] Disable block editor for wp_navigation CPT (it doesn't work yet) so i… [WIP] Provide a way to manage wp_navigation posts from wp-admin Nov 1, 2021
@draganescu
Copy link
Contributor

I think we want to hide any ability to edit the content of the navigation CPT, as manually changing navigation block markup is prone to breaking it. Also, I like the simplicity of this approach if it works, no need for new API just a Gutenberg specific fix.

@anton-vlasenko anton-vlasenko changed the title [WIP] Provide a way to manage wp_navigation posts from wp-admin Provide a way to manage wp_navigation posts from wp-admin Nov 3, 2021
@anton-vlasenko anton-vlasenko added [Block] Navigation Affects the Navigation Block [Type] Enhancement A suggestion for improvement. labels Nov 3, 2021
@anton-vlasenko anton-vlasenko self-assigned this Nov 3, 2021
@anton-vlasenko
Copy link
Contributor Author

@draganescu

I think we want to hide any ability to edit the content of the navigation CPT, as manually changing navigation block markup is prone to breaking it. Also, I like the simplicity of this approach if it works, no need for new API just a Gutenberg specific fix.

Thank you for the review.
The issues you mentioned should be fixed now. Now we cannot edit the content of a post (but we still can edit some other relevant data using the "Quick Edit" row action).
I'd appreciate it if you could review it.
cc @talldan

@talldan
Copy link
Contributor

talldan commented Nov 3, 2021

This looks great to me, thanks @anton-vlasenko!

The only remaining bit that would be great to tidy up is the bit of text here:
Screenshot 2021-11-03 at 5 20 55 pm

It'd be cool if it just said 'Navigation Menus'. I think this would just be a simple change to the strings defined in the custom post type definition:

'all_items' => __( 'All Navigation Menus', 'gutenberg' ),

The only part that confused me is that the Template Parts section has 'All Template Parts' defined for this all_items string, but as you can see the interface displays 'Template Parts':

'all_items' => __( 'All Template Parts', 'gutenberg' ),

So perhaps there's a different way to control this text that doesn't involve changing all_items.

@anton-vlasenko anton-vlasenko force-pushed the add/add-a-way-to-manage-wp_navigation-type-posts branch from b3438b3 to 566c159 Compare November 3, 2021 09:48
@talldan
Copy link
Contributor

talldan commented Nov 3, 2021

Oh, if there's a way to get rid of the 'Add new' button as well, that'd be great. It looks like that also opens the editor.

@anton-vlasenko
Copy link
Contributor Author

anton-vlasenko commented Nov 3, 2021

Oh, if there's a way to get rid of the 'Add new' button as well, that'd be great. It looks like that also opens the editor.

Great catch. I've noticed it too.

@draganescu
Copy link
Contributor

Great work @anton-vlasenko 👏🏻

@talldan this is what we get with this approach:

Screen Shot 2021-11-03 at 15 14 18

Aside from renaming, not much use for everything else there:

  • publish date
  • status
  • password protecting or making private

Unless updating those changes the behavior of the block, I think this exploration will not lead us to far.

It feels to me like the whole idea of the #36036 is bound to be around using a block editor to properly edit a menu, while this approach using the "post edit screen" brings only one benefit and a lot of useless baggage.

Content editor cannot correctly edit them.
2. Add unit tests.
Rename it to "Navigation Menus".
@anton-vlasenko
Copy link
Contributor Author

@draganescu @talldan
It was not possible to remove the Add New button without modifying the core.
So I decided to remove the content editor.
I've updated the How has this been tested? section to reflect the latest changes.

@anton-vlasenko
Copy link
Contributor Author

anton-vlasenko commented Nov 3, 2021

@draganescu

It feels to me like the whole idea of the #36036 is bound to be around using a block editor to properly edit a menu, while this approach using the "post edit screen" brings only one benefit and a lot of useless baggage.

I see value in this PR (considering the changes I've just made).
It prevents users from editing content of wp_navigation posts using the post edit screen.
We can remove the Quick Edit row action if needed.

@anton-vlasenko
Copy link
Contributor Author

anton-vlasenko commented Nov 3, 2021

So perhaps there's a different way to control this text that doesn't involve changing all_items.

Yes, there is a way.
We have to change global $submenu variable to achieve this.
At least this is how Template Parts CPT does it.
https://github.com/WordPress/gutenberg/blob/trunk/lib/full-site-editing/template-parts.php#L109

Fixed in 39e9570

@talldan
Copy link
Contributor

talldan commented Nov 4, 2021

It feels to me like the whole idea of the #36036 is bound to be around using a block editor to properly edit a menu, while this approach using the "post edit screen" brings only one benefit and a lot of useless baggage.

I think bulk deleting is valuable right now, given we know the flow for creating menus isn't perfect.

And it'll be a good idea to iterate on providing a way to edit these menus via the Gutenberg plugin after 5.9.

The direction should ultimately be guided by #29630 and future related issues to that. Right now it looks like that's moving towards using wp-admin for listing menus for 5.9.

'show_in_menu' => 'themes.php',
'show_in_admin_bar' => false,
'show_in_rest' => true,
'map_meta_cap' => true,
'rest_base' => 'navigation',
'rest_controller_class' => 'WP_REST_Posts_Controller',
'rest_controller_class' => WP_REST_Posts_Controller::class,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change this?

Copy link
Contributor Author

@anton-vlasenko anton-vlasenko Nov 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IDEs like PHPStorm can understand what class is meant here if we use the ::class keyword. This could be useful during refactoring or if we decide to use namespaces in the far future :). And it's just convenient to click on a class name to go to its definition.
I'm not aware of any modern PHP application that uses plain strings to specify class names. It just looks a little bit archaic to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good but, just thinking, ::class returns the fully qualified class name resolution, it is not "the same" as the class name as a string, and if rest_controller_class does not expect a fully qualified class name we may get into trouble.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does return a FQCN, but since we don't use PHP namespaces in WordPress it equals to 'WP_REST_Posts_Controller'. I've checked it.
And it's fail safe. Even If the WP_REST_Posts_Controller class is not loaded or defined, it will still return 'WP_REST_Posts_Controller'.
I'm not insisting that we have to use ::class, I just see no reasons not to use it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if we do introduce Namespaces? Well ... I assume that too many things will change for this to be a big problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do introduce namespaces, the FQCN will change to include the namespace.
E.g. instead of 'WP_REST_Posts_Controller' it will return 'WordPress\REST\Controllers\Posts' or something similar.
But if we introduce namespaces, we will need to know FQCN to load the correct class anyway because there could be several classes with the same name, i.e., multiple Posts classes in different namespaces.
This change shouldn't introduce any problems.

We need to enable it back because we disable it to hide the content editor windows. This is required to avoid the incorrect state of wp_navigation CPT.
return;
}

remove_post_type_support( $post_type, 'editor' );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this has to hapen b/c if the post type definition itself does not support editor we get into the rest problem not allowing saving at all. That would be good to be added to the docblock of the function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch.
Fixed in 3bee078

add_action( 'edit_form_after_editor', 'gutenberg_enable_content_editor_for_navigation_post_type', 10, 1 );

/**
* Fixes the label of the 'wp_navigation' admin menu entry.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unclear what exactly this fixes from the comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the review!
I've renamed the method and updated the comment.
Fixed in baccf37

return;
}
foreach ( $submenu['themes.php'] as $key => $submenu_entry ) {
if ( $post_type->labels->all_items === $submenu['themes.php'][ $key ][0] ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think assigning $submenu['themes.php'][ $key ][0] to a variable that tells the reader what is at index 0 would be nice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've renamed the variables.
Please let me know if you think it's fine.
a6abfca

@@ -0,0 +1,94 @@
<?php
/**
* This class is supposed to test the functionality of the navigation.php
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is supposed to test -> tests,
of the navigation.php -> of block navigation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 38dbd8e

Copy link
Contributor

@talldan talldan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff, LGTM.

Thanks for this, appreciate you finding all those niché core APIs for disabling features.

@talldan talldan merged commit 6b6c4d8 into trunk Nov 5, 2021
@talldan talldan deleted the add/add-a-way-to-manage-wp_navigation-type-posts branch November 5, 2021 06:33
@github-actions github-actions bot added this to the Gutenberg 11.9 milestone Nov 5, 2021
@anton-vlasenko
Copy link
Contributor Author

Thanks for this, appreciate you finding all those niché core APIs for disabling features.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide a way to manage wp_navigation posts from wp-admin
4 participants