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

wp_block Editor #13291

Closed
apermo opened this issue Jan 11, 2019 · 7 comments
Closed

wp_block Editor #13291

apermo opened this issue Jan 11, 2019 · 7 comments
Labels
Needs Technical Feedback Needs testing from a developer perspective. [Type] Help Request Help with setup, implementation, or "How do I?" questions.

Comments

@apermo
Copy link

apermo commented Jan 11, 2019

hey there,

I created a plugin that allows me to edit wp_blocks on their own I basically uses this gist code. https://gist.github.com/apermo/1693f580b9e833bb30fe8ac70020b769

I works fine with the Gutenberg Plugin, but since wp_block is defined as _builtin = true, the menu will no longer render the submenu in the adminbar.

The code in wp-admin/menu.php Line 94, will filter all builtin out, and only add post and page.

$types   = (array) get_post_types(
	array(
		'show_ui'      => true,
		'_builtin'     => false,
		'show_in_menu' => true,
	)
);
$builtin = array( 'post', 'page' );
foreach ( array_merge( $builtin, $types ) as $ptype ) {

As soon as I alter my gist code, to unset the _builtin argument, the wp_block submenu shows again.

I'd love to see a standalone wp_block editor, that does not require any hacks as part of the core, since it already works fine. Maybe as an advanced option that can be turned on and off.

Sidenote: Are there any side effects to be expected when I unset the _builtin argument for my editors?

@swissspidy swissspidy added the [Type] Help Request Help with setup, implementation, or "How do I?" questions. label Jan 11, 2019
@swissspidy
Copy link
Member

There's a reason _builtin exists for internal post types in WordPress. They're often treated in a special way and messing with that flag could have unintended side effects.

Isn't there a way to (manually) add the menu items to the toolbar or wherever without changing that flag?

@apermo
Copy link
Author

apermo commented Jan 11, 2019

Of course I could manually add everything to the menu, but in the end that would be hacky too.

Best way in the End would probably be if the feature itself would be provided by gutenberg/WordPress. Since the possibility to edit reusable blocks, provides more options.

In the classical way, you can only have a single block. When using the standalone editor, you can have multiple blocks (headline, image, paragraph for example). And as I mentioned, it worked before with WP 4.9.x and Plugin.

Since it's not a published plugin right now, I could live with the _builtin hack. What would actually help as well would be something like this:

$types   = (array) get_post_types(
	array(
		'show_ui'      => true,
		'_builtin'     => false,
		'show_in_menu' => true,
	)
);
$builtin = array( 'post', 'page' );

$types = apply_filter( 'new_post_type_admin_menu_filter_name', array_merge( $builtin, $types ) );

foreach ( $types as $ptype ) {

With this addition I could insert the "missing" post_type, without needing to hack there.

@designsimply designsimply added the Needs Technical Feedback Needs testing from a developer perspective. label Jan 11, 2019
@apermo
Copy link
Author

apermo commented Jan 14, 2019

@designsimply You mean needs feedback from me? Or from other sources?

@swissspidy
Copy link
Member

@apermo That means feedback from Gutenberg/WordPress devs

@designsimply
Copy link
Member

Yes! (and thanks for clarifying @swissspidy 🙂) the Needs Technical Feedback label means something needs testing or advisement from a developer perspective.

I noticed there is a large discussion happening in a recent PR about loading the block editor in several contexts without a dependency to a post object and it sounded similar to when you said "I'd love to see a standalone wp_block editor that does not require any hacks as part of the core." @apermo does #13088 look like it addresses what you are asking? Note that it is an open discussion happening as part of Phase 2 for Gutenberg which has a main objective of porting widgets to blocks.

@apermo
Copy link
Author

apermo commented Feb 8, 2019

@designsimply I think yes.

To sum up again what I want to do (or told my editors that I will do)

I want to be able to edit/create reusable blocks just as any other custom post type directly from the menu.

@aduth
Copy link
Member

aduth commented Apr 22, 2019

I'd love to see a standalone wp_block editor, that does not require any hacks as part of the core, since it already works fine. Maybe as an advanced option that can be turned on and off.

Best way in the End would probably be if the feature itself would be provided by gutenberg/WordPress. Since the possibility to edit reusable blocks, provides more options.

In the classical way, you can only have a single block. When using the standalone editor, you can have multiple blocks (headline, image, paragraph for example). And as I mentioned, it worked before with WP 4.9.x and Plugin.

From my reading of the issue, it is already available to edit reusable blocks in a standalone editor with the following:

  1. From the post editor, click "More Options" in the top-right
  2. Click "Manage All Reusable Blocks"
  3. Click on a reusable block

Furthermore, while not always the case, more recently it was enhanced that multiple blocks can be edited within a reusable block. For example, you can select multiple blocks, then "Add to Reusable Blocks" from the block options menu.

It can be reopened if tasks remain here, but as best I can tell there is no action item here.

@aduth aduth closed this as completed Apr 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Technical Feedback Needs testing from a developer perspective. [Type] Help Request Help with setup, implementation, or "How do I?" questions.
Projects
None yet
Development

No branches or pull requests

4 participants