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

Supporting Metaboxes #952

Closed
jasmussen opened this Issue May 31, 2017 · 173 comments

Comments

@jasmussen
Contributor

jasmussen commented May 31, 2017

Gutenberg is written in JS, as are the metaboxes in the Settings sidebar.

There are many plugins that add metaboxes in PHP. To allow these to work in the new editor, we should consider adding a space for these to live. One example is an "Extended Settings" panel. Mockup:

post settings

Edit: This ticket has been rephrased to add a little clarity. Metaboxes are here to stay. See also #952 (comment)

@androb

This comment has been minimized.

Show comment
Hide comment
@androb

androb May 31, 2017

Contributor

FWIW when I talked to web developers they all use metaboxes for content so that they have maximum control. I am not sure metaboxes are going to be considered "legacy" for a lot of people but rather part of the future. It might be worth reaching out to the WordPress VIP folk to get their take.

Contributor

androb commented May 31, 2017

FWIW when I talked to web developers they all use metaboxes for content so that they have maximum control. I am not sure metaboxes are going to be considered "legacy" for a lot of people but rather part of the future. It might be worth reaching out to the WordPress VIP folk to get their take.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen May 31, 2017

Contributor

I am not sure metaboxes are going to be considered "legacy" for a lot of people but rather part of the future. It might be worth reaching out to the WordPress VIP folk to get their take.

My apologies, that phrasing was bad. Metaboxes are here to stay. That's why the metabox sidebar is getting an upgrade in the form of the new "Post Settings" sidebar.

What I meant to say was that new metaboxes should be written in JS, and will appear in the Post Settings sidebar alongside the stock ones. Metaboxes written in PHP should ideally be upgraded to be JS, but should continue to work in their PHP form also. That's what the "Extended Settings" panel is for, and it sits there at the bottom not because we don't want them to be part of the sidebar, but rather that it's very difficult to mix PHP and JS metaboxes in a sidebar.

Contributor

jasmussen commented May 31, 2017

I am not sure metaboxes are going to be considered "legacy" for a lot of people but rather part of the future. It might be worth reaching out to the WordPress VIP folk to get their take.

My apologies, that phrasing was bad. Metaboxes are here to stay. That's why the metabox sidebar is getting an upgrade in the form of the new "Post Settings" sidebar.

What I meant to say was that new metaboxes should be written in JS, and will appear in the Post Settings sidebar alongside the stock ones. Metaboxes written in PHP should ideally be upgraded to be JS, but should continue to work in their PHP form also. That's what the "Extended Settings" panel is for, and it sits there at the bottom not because we don't want them to be part of the sidebar, but rather that it's very difficult to mix PHP and JS metaboxes in a sidebar.

@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter May 31, 2017

Member

There are some big challenges with submitting PHP-managed metaboxes via JS and Ajax, particularly in how to handle updating the metabox render to reflect the newly-saved state: https://core.trac.wordpress.org/ticket/7756

I wonder if embedding a legacy metabox via an iframe could be a solution here, where the iframe src is something like /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings and only outputs that one metabox into the document.

Member

westonruter commented May 31, 2017

There are some big challenges with submitting PHP-managed metaboxes via JS and Ajax, particularly in how to handle updating the metabox render to reflect the newly-saved state: https://core.trac.wordpress.org/ticket/7756

I wonder if embedding a legacy metabox via an iframe could be a solution here, where the iframe src is something like /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings and only outputs that one metabox into the document.

@braders

This comment has been minimized.

Show comment
Hide comment
@braders

braders Jun 3, 2017

What I meant to say was that new metaboxes should be written in JS, and will appear in the Post Settings sidebar alongside the stock ones.

Does this mean JavaScript metaboxes can only go in the sidebar, and cannot be part of the "extended settings" section? Just of the top of my head I can think of lots of plugins where the sidebar won't really provide enough space & make the sidebar potentially cluttered. Just a few plugins which might have issues with this approach:

  • Yoast SEO: provides a large number of fields, which probably won't fit in the sidebar - could maybe have a sidebar metabox which opened a modal for more options, but this feels like working around an unnecessary limitation

  • Custom field plugins/ drag & drop page builders - these replace or partially replace the main content area & so need plenty of screen real estate. Full page builders potential warrant them building their own totally custom interface as a separate view, but in some cases a number of extra structured fields are required in addition to the main content area (and I appreciate Guttenburg​ should reduce the need for these types of plugin, but equally it can't cover every use-case)

  • WooCommerce - adds metaboxes for order & line item data, whilst removing the main editor (Woo plan to eventually build their own custom interface, but I suspect this is a long way off, and other plugins will be in a similar situation)

(I'm assuming Guttenburg is planned to eventually replace the current post-new/post-edit.php views, rather than simply being an alternative?)

braders commented Jun 3, 2017

What I meant to say was that new metaboxes should be written in JS, and will appear in the Post Settings sidebar alongside the stock ones.

Does this mean JavaScript metaboxes can only go in the sidebar, and cannot be part of the "extended settings" section? Just of the top of my head I can think of lots of plugins where the sidebar won't really provide enough space & make the sidebar potentially cluttered. Just a few plugins which might have issues with this approach:

  • Yoast SEO: provides a large number of fields, which probably won't fit in the sidebar - could maybe have a sidebar metabox which opened a modal for more options, but this feels like working around an unnecessary limitation

  • Custom field plugins/ drag & drop page builders - these replace or partially replace the main content area & so need plenty of screen real estate. Full page builders potential warrant them building their own totally custom interface as a separate view, but in some cases a number of extra structured fields are required in addition to the main content area (and I appreciate Guttenburg​ should reduce the need for these types of plugin, but equally it can't cover every use-case)

  • WooCommerce - adds metaboxes for order & line item data, whilst removing the main editor (Woo plan to eventually build their own custom interface, but I suspect this is a long way off, and other plugins will be in a similar situation)

(I'm assuming Guttenburg is planned to eventually replace the current post-new/post-edit.php views, rather than simply being an alternative?)

@jasmussen jasmussen added this to the Beta milestone Jun 5, 2017

@mtias mtias changed the title from Plugin: Provide UI for old editor plugins to Plugin: Add "advanced" drawer with server-rendered legacy settings Jun 6, 2017

@aduth aduth changed the title from Plugin: Add "advanced" drawer with server-rendered legacy settings to Plugin: Add "advanced" drawer with server-rendered legacy and metabox settings Jun 8, 2017

@hedgefield

This comment has been minimized.

Show comment
Hide comment
@hedgefield

hedgefield Jun 8, 2017

Ha thanks @braders - Yoast UX-er checking in here with the same question :)

Our metabox is indeed pretty big and wide right now, as it does a lot of things. We wouldn't mind working those features more into the different metaboxes in the sidebar to offer a tighter integration, but I was wondering if that will be possible? For instance, can we add SEO scores to the Publish box like we do currently? And if not, can we still hook into the extended settings box even if our metabox is coded in JS?

Ha thanks @braders - Yoast UX-er checking in here with the same question :)

Our metabox is indeed pretty big and wide right now, as it does a lot of things. We wouldn't mind working those features more into the different metaboxes in the sidebar to offer a tighter integration, but I was wondering if that will be possible? For instance, can we add SEO scores to the Publish box like we do currently? And if not, can we still hook into the extended settings box even if our metabox is coded in JS?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 8, 2017

Contributor

We should absolutely look at making the new Post Settings pluggable, so that you can add javascript metaboxes to the sidebar. Perhaps it's time to open a ticket for that. This ticket is mostly for metaboxes written in PHP, that need to work in a transitional way.

Contributor

jasmussen commented Jun 8, 2017

We should absolutely look at making the new Post Settings pluggable, so that you can add javascript metaboxes to the sidebar. Perhaps it's time to open a ticket for that. This ticket is mostly for metaboxes written in PHP, that need to work in a transitional way.

@brentjett

This comment has been minimized.

Show comment
Hide comment
@brentjett

brentjett Jun 8, 2017

Along the same lines as metaboxes in the extended section, has there been any discussion or mockups done for how a post type that does not support post content editing would be presented? In those cases, the metaboxes in the middle area are relied on for the primary editing experience. Should Gutenberg present a "Title-Only" mode? Or should the post title be handled differently in the absence of the editor.

brentjett commented Jun 8, 2017

Along the same lines as metaboxes in the extended section, has there been any discussion or mockups done for how a post type that does not support post content editing would be presented? In those cases, the metaboxes in the middle area are relied on for the primary editing experience. Should Gutenberg present a "Title-Only" mode? Or should the post title be handled differently in the absence of the editor.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 9, 2017

Contributor

Along the same lines as metaboxes in the extended section, has there been any discussion or mockups done for how a post type that does not support post content editing would be presented? In those cases, the metaboxes in the middle area are relied on for the primary editing experience. Should Gutenberg present a "Title-Only" mode? Or should the post title be handled differently in the absence of the editor.

This would be good to create a separate ticket for! With screenshots of the existing post type, if you have it!

Contributor

jasmussen commented Jun 9, 2017

Along the same lines as metaboxes in the extended section, has there been any discussion or mockups done for how a post type that does not support post content editing would be presented? In those cases, the metaboxes in the middle area are relied on for the primary editing experience. Should Gutenberg present a "Title-Only" mode? Or should the post title be handled differently in the absence of the editor.

This would be good to create a separate ticket for! With screenshots of the existing post type, if you have it!

@kevinwhoffman

This comment has been minimized.

Show comment
Hide comment
@kevinwhoffman

kevinwhoffman Jun 15, 2017

Contributor

I also want to emphasize that many plugins use custom post types that rely on meta boxes without a content editor at all. If the post type is registered without support for editor, there should be a title-only mode that opens up the full canvas for use by meta boxes.

Contributor

kevinwhoffman commented Jun 15, 2017

I also want to emphasize that many plugins use custom post types that rely on meta boxes without a content editor at all. If the post type is registered without support for editor, there should be a title-only mode that opens up the full canvas for use by meta boxes.

@mtias mtias modified the milestones: Beta 2, Beta Jun 15, 2017

@davisshaver

This comment has been minimized.

Show comment
Hide comment
@davisshaver

davisshaver Jun 19, 2017

Contributor

+1 to reaching out to WordPress VIP. This is also an issue on the Calypso thread: Automattic/wp-calypso#587

Really important feature for the top of market!

Contributor

davisshaver commented Jun 19, 2017

+1 to reaching out to WordPress VIP. This is also an issue on the Calypso thread: Automattic/wp-calypso#587

Really important feature for the top of market!

@nylen

This comment has been minimized.

Show comment
Hide comment
@nylen

nylen Jun 22, 2017

Member

I wonder if embedding a legacy metabox via an iframe could be a solution here, where the iframe src is something like /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings and only outputs that one metabox into the document.

I had this same idea too. It's also a good idea for sandboxing and session management reasons. Then we can identify common use cases of this feature and implement an API to handle them.

Member

nylen commented Jun 22, 2017

I wonder if embedding a legacy metabox via an iframe could be a solution here, where the iframe src is something like /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings and only outputs that one metabox into the document.

I had this same idea too. It's also a good idea for sandboxing and session management reasons. Then we can identify common use cases of this feature and implement an API to handle them.

@Shelob9

This comment has been minimized.

Show comment
Hide comment
@Shelob9

Shelob9 Jun 22, 2017

Contributor

I wanted to way in as a plugin developer and as someone who uses WordPress mainly as an eCommerce tool. Also beacuse @kevinwhoffman told me to.

I tired Gutenberg today and I literally can't process this as being WordPress without seeing how metaboxes and editor buttons (added via media_buttons hook) being a part of this.

I also am not a huge fan of the current state of the WordPress editor and the metabox-palooza. I just counted and in the download (Easy Digital Download's product post type) single post view I have 14 custom meta boxes added by Yoast, Easy Digital Downloads and my own custom code using CMB2. It's a lot, but I need those. WordPress is pretty pointless without that interface and what it exposes.

I'm concerned that this wasn't considered from the beginning as I've worked on so many sites where the custom fields interface added with ACF, Pods, CMB2 etc was the entire editing experience.

Here are my technical concerns:

  1. Buttons added via the media_buttons. In my plugin Caldera Forms (80K+ active installs), we use this action to add a form insert button that brings up a modal to insert the shortcode into the post editor. Maybe we would move to a custom block in Gutenberg.
  2. How does the save_post action remain backwards compatible? So many plugins, themes and custom code hooks in at save_action and accesses $_POST super global. That's not good design, but its a technical debt affecting millions of sites.
  3. There was a suggestion to render legacy metaboxes in an iFrame. This worries me as accessing an iFrame's content via JavaScript isn't possible.
Contributor

Shelob9 commented Jun 22, 2017

I wanted to way in as a plugin developer and as someone who uses WordPress mainly as an eCommerce tool. Also beacuse @kevinwhoffman told me to.

I tired Gutenberg today and I literally can't process this as being WordPress without seeing how metaboxes and editor buttons (added via media_buttons hook) being a part of this.

I also am not a huge fan of the current state of the WordPress editor and the metabox-palooza. I just counted and in the download (Easy Digital Download's product post type) single post view I have 14 custom meta boxes added by Yoast, Easy Digital Downloads and my own custom code using CMB2. It's a lot, but I need those. WordPress is pretty pointless without that interface and what it exposes.

I'm concerned that this wasn't considered from the beginning as I've worked on so many sites where the custom fields interface added with ACF, Pods, CMB2 etc was the entire editing experience.

Here are my technical concerns:

  1. Buttons added via the media_buttons. In my plugin Caldera Forms (80K+ active installs), we use this action to add a form insert button that brings up a modal to insert the shortcode into the post editor. Maybe we would move to a custom block in Gutenberg.
  2. How does the save_post action remain backwards compatible? So many plugins, themes and custom code hooks in at save_action and accesses $_POST super global. That's not good design, but its a technical debt affecting millions of sites.
  3. There was a suggestion to render legacy metaboxes in an iFrame. This worries me as accessing an iFrame's content via JavaScript isn't possible.
@westonruter

This comment has been minimized.

Show comment
Hide comment
@westonruter

westonruter Jun 23, 2017

Member

@Shelob9 hi!

There was a suggestion to render legacy metaboxes in an iFrame. This worries me as accessing an iFrame's content via JavaScript isn't possible.

Accessing an iframe's content via JavaScript is possible, as long as it is on the same domain, as they would be in this case.

How does the save_post action remain backwards compatible? So many plugins, themes and custom code hooks in at save_action and accesses $_POST super global. That's not good design, but its a technical debt affecting millions of sites.

There's only so much we can do to ease the transition of legacy metaboxes to Gutenberg. There's a fundamental difference in how data is modeled in Gutenberg vs the current post edit screen. That is to say, data is now actually modeled for the first time. With data modeling, we can finally use JavaScript interfaces for manipulating the state of posts and postmeta in ways that are impossible using $_POST and the save_post action, let alone being able to preview changes to postmeta. By routing postmeta changes through the model, this will allow for postmeta to be previewed for the first time. So even though Gutenberg can include legacy metaboxes whenever possible, they will always be inherently limited in how much they can take advantage of the new interface. I think that's as much of a reality as the reality that we have technical debt.

I think it's the intentional and conscious decision of Matt that the technical debt must be cancelled if WordPress is to evolve in the way that it will remain relevant in the future. The more that we can get ACF, Pods, and CMB2 updated to use the data model being introduced by Gutenberg, the easier this transition will be I think. There will no doubt be a lot of challenges and hard work ahead!

Member

westonruter commented Jun 23, 2017

@Shelob9 hi!

There was a suggestion to render legacy metaboxes in an iFrame. This worries me as accessing an iFrame's content via JavaScript isn't possible.

Accessing an iframe's content via JavaScript is possible, as long as it is on the same domain, as they would be in this case.

How does the save_post action remain backwards compatible? So many plugins, themes and custom code hooks in at save_action and accesses $_POST super global. That's not good design, but its a technical debt affecting millions of sites.

There's only so much we can do to ease the transition of legacy metaboxes to Gutenberg. There's a fundamental difference in how data is modeled in Gutenberg vs the current post edit screen. That is to say, data is now actually modeled for the first time. With data modeling, we can finally use JavaScript interfaces for manipulating the state of posts and postmeta in ways that are impossible using $_POST and the save_post action, let alone being able to preview changes to postmeta. By routing postmeta changes through the model, this will allow for postmeta to be previewed for the first time. So even though Gutenberg can include legacy metaboxes whenever possible, they will always be inherently limited in how much they can take advantage of the new interface. I think that's as much of a reality as the reality that we have technical debt.

I think it's the intentional and conscious decision of Matt that the technical debt must be cancelled if WordPress is to evolve in the way that it will remain relevant in the future. The more that we can get ACF, Pods, and CMB2 updated to use the data model being introduced by Gutenberg, the easier this transition will be I think. There will no doubt be a lot of challenges and hard work ahead!

@buzztone

This comment has been minimized.

Show comment
Hide comment
@buzztone

buzztone Jun 23, 2017

@westonruter thanks that makes the purpose of the Extended Settings area much clearer.

I suspect some of the discussion here is at also partly about available screen real estate.

It looks like Gutenberg JS metaboxes can get access to the toggle-able side bar (which is fine by me) while legacy PHP metaboxes get access to the much wider area available at the bottom of the screen (which is also fine by me).

Unfortunately I expect that this desire for available screen real estate may interfere with the intended discussion on how to effectively handle legacy PHP metaboxes.

@westonruter thanks that makes the purpose of the Extended Settings area much clearer.

I suspect some of the discussion here is at also partly about available screen real estate.

It looks like Gutenberg JS metaboxes can get access to the toggle-able side bar (which is fine by me) while legacy PHP metaboxes get access to the much wider area available at the bottom of the screen (which is also fine by me).

Unfortunately I expect that this desire for available screen real estate may interfere with the intended discussion on how to effectively handle legacy PHP metaboxes.

@hedgefield

This comment has been minimized.

Show comment
Hide comment
@hedgefield

hedgefield Jun 23, 2017

I agree that instead of supporting all the old ways, plugin makers should reconsider their metaboxes and how they can better integrate with the new layout. At the same time, I also agree that similar possibilities to integrate should also be offered in the new editor (and I trust that they will). I believe #1352 is the main place to discuss that currently. This issue is for discussing the way we'll provide backward compatibility for non-updated PHP metaboxes at launch.

I agree that instead of supporting all the old ways, plugin makers should reconsider their metaboxes and how they can better integrate with the new layout. At the same time, I also agree that similar possibilities to integrate should also be offered in the new editor (and I trust that they will). I believe #1352 is the main place to discuss that currently. This issue is for discussing the way we'll provide backward compatibility for non-updated PHP metaboxes at launch.

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Jun 23, 2017

Contributor

I wonder if embedding a legacy metabox via an iframe could be a solution here

Accessing iframes is not a super exciting experience for screen reader users. Any other options?

Contributor

afercia commented Jun 23, 2017

I wonder if embedding a legacy metabox via an iframe could be a solution here

Accessing iframes is not a super exciting experience for screen reader users. Any other options?

@kevinpmiller

This comment has been minimized.

Show comment
Hide comment
@kevinpmiller

kevinpmiller Jun 23, 2017

Just wanted to chime in here, the sidebar is simply not big enough for most meta boxes that we see in plugins and themes. Forcing us to cram things into this small space is a setback in my opinion. I think this new editor is great, however not if it means sacrificing how we use meta boxes today.

Just wanted to chime in here, the sidebar is simply not big enough for most meta boxes that we see in plugins and themes. Forcing us to cram things into this small space is a setback in my opinion. I think this new editor is great, however not if it means sacrificing how we use meta boxes today.

@Shelob9

This comment has been minimized.

Show comment
Hide comment
@Shelob9

Shelob9 Jun 23, 2017

Contributor

I agree with @kevinpmiller strongly. Metaboxes need a lot of real estate and can't be hidden into a sidebar. The current state of metaboxes is disjointed and bad design, but they also reflect what WordPress is -- a highly extensible CMS.

In reply to @westonruter thanks for clarifying about backwards compatibility. I think that needs to be made VERY clear that WordPress 5.0 or where ever this lands isn't backwards compatible since that's been the user expectation.

Contributor

Shelob9 commented Jun 23, 2017

I agree with @kevinpmiller strongly. Metaboxes need a lot of real estate and can't be hidden into a sidebar. The current state of metaboxes is disjointed and bad design, but they also reflect what WordPress is -- a highly extensible CMS.

In reply to @westonruter thanks for clarifying about backwards compatibility. I think that needs to be made VERY clear that WordPress 5.0 or where ever this lands isn't backwards compatible since that's been the user expectation.

@ScottDeLuzio

This comment has been minimized.

Show comment
Hide comment
@ScottDeLuzio

ScottDeLuzio Jun 23, 2017

I'm also concerned about how metaboxes will be handled, especially in certain Custom Post Types where the content editor may not be the primary focus of the CPT. I'm going to pick on WooCommerce here because it's a well-known plugin, but there are a lot of other plugins and themes that have similar issues.

For example, WooCommerce orders have no content editor - it simply isn't needed. Details about the order are what is important, not content editing, and rightfully should be the primary focus of that page.

Will CPTs like this have the ability to remove the editor if it isn't needed? The plugin doesn't seem to be fully integrated with custom metaboxes in CPTs so it's hard to tell if this has been considered or not.

WooCommerce products also bring up another issue where there are two content areas - one for the product's description and another for the product's short description. Will one need to take precedence over the other in the "main" editor area, while the other gets stuck in the sidebar? It seems like a less than optimal editing experience for the one that is in the sidebar.

Can there be an option to intentionally register these settings in the area below (or above?) the editor as opposed to cramming them all in the sidebar? This could be similar to the current add_meta_box context and priority parameters. Perhaps, even toggle between several content editors (or other metaboxes) that belong in the wider section of the page.

Maybe I'm missing something here (please correct me if I'm wrong), but it seems like a huge push is being made for a better editor when in reality, not all uses of WordPress require anything different than what's in use today.

I'm also concerned about how metaboxes will be handled, especially in certain Custom Post Types where the content editor may not be the primary focus of the CPT. I'm going to pick on WooCommerce here because it's a well-known plugin, but there are a lot of other plugins and themes that have similar issues.

For example, WooCommerce orders have no content editor - it simply isn't needed. Details about the order are what is important, not content editing, and rightfully should be the primary focus of that page.

Will CPTs like this have the ability to remove the editor if it isn't needed? The plugin doesn't seem to be fully integrated with custom metaboxes in CPTs so it's hard to tell if this has been considered or not.

WooCommerce products also bring up another issue where there are two content areas - one for the product's description and another for the product's short description. Will one need to take precedence over the other in the "main" editor area, while the other gets stuck in the sidebar? It seems like a less than optimal editing experience for the one that is in the sidebar.

Can there be an option to intentionally register these settings in the area below (or above?) the editor as opposed to cramming them all in the sidebar? This could be similar to the current add_meta_box context and priority parameters. Perhaps, even toggle between several content editors (or other metaboxes) that belong in the wider section of the page.

Maybe I'm missing something here (please correct me if I'm wrong), but it seems like a huge push is being made for a better editor when in reality, not all uses of WordPress require anything different than what's in use today.

@steveangstrom

This comment has been minimized.

Show comment
Hide comment
@steveangstrom

steveangstrom Jun 24, 2017

QUESTION how do we define a CPT to not use Gutenberg (equivalent of no editor), and ONLY show the full width metaboxes our businesses rely on.
I rely on metaboxes. Most often my CPTs looklike this
'supports' => array( 'title' )
And are extended from there. Please consider those of us who have built business tools for clients using CPTs with metaboxes as constrained and guided form data entry, rather than for article writing.
My work is mostly custom extensions to CMB2 which interface with client systems. EG real estate listings which call on 3rd party systems.

I don't want to sound dramatic, but I will be sticking on WP4.9 untill this is resolved and I am very concerned about the future. I understand that Gutenberg is "cancelling the debt to the past"! But the debt falls on people like me.

steveangstrom commented Jun 24, 2017

QUESTION how do we define a CPT to not use Gutenberg (equivalent of no editor), and ONLY show the full width metaboxes our businesses rely on.
I rely on metaboxes. Most often my CPTs looklike this
'supports' => array( 'title' )
And are extended from there. Please consider those of us who have built business tools for clients using CPTs with metaboxes as constrained and guided form data entry, rather than for article writing.
My work is mostly custom extensions to CMB2 which interface with client systems. EG real estate listings which call on 3rd party systems.

I don't want to sound dramatic, but I will be sticking on WP4.9 untill this is resolved and I am very concerned about the future. I understand that Gutenberg is "cancelling the debt to the past"! But the debt falls on people like me.

@braders

This comment has been minimized.

Show comment
Hide comment
@braders

braders Jun 24, 2017

The theme here seems to be that the issue is not with Guttenburg, but rather with the lack of backwards compatibility.

There are some actual Guttenburg issues, for which seperate tickets should possibly be raised (allow metaboxes to use full width, mock-up Guttenburg with no editor support), but Gutturnberg can't totally replicate the current screens and nor should it try IMHO.

However, I do wonder if more should be done to make Guttenburg opt-in/ opt-out. A few ideas:

  • I would guess most current CPTs make heavy use of metaboxes over the main editor. So maybe plugin authors should opt into Gutturnberg with 'supports' => array( 'gutenburg' ) or similar

  • For posts and pages, Guttenburg should maybe be optional as a site setting. It would even be possible to ask users if they wish to use Guttenburg after the 5.0 update and store this choice in the DB.

  • Or alternatively, themes could declare support via post_type_supports(), but this could seriously harm uptake - or themes could opt-out that would not help users of legacy, unmaintained themes which are no longer updated. (Maybe a remove-guttenburn plugin would be sufficient for users of legacy themes though?)

But, regardless of implementation, I do think that the current view should remain, even if it is increasingly hidden from the majority of users...

braders commented Jun 24, 2017

The theme here seems to be that the issue is not with Guttenburg, but rather with the lack of backwards compatibility.

There are some actual Guttenburg issues, for which seperate tickets should possibly be raised (allow metaboxes to use full width, mock-up Guttenburg with no editor support), but Gutturnberg can't totally replicate the current screens and nor should it try IMHO.

However, I do wonder if more should be done to make Guttenburg opt-in/ opt-out. A few ideas:

  • I would guess most current CPTs make heavy use of metaboxes over the main editor. So maybe plugin authors should opt into Gutturnberg with 'supports' => array( 'gutenburg' ) or similar

  • For posts and pages, Guttenburg should maybe be optional as a site setting. It would even be possible to ask users if they wish to use Guttenburg after the 5.0 update and store this choice in the DB.

  • Or alternatively, themes could declare support via post_type_supports(), but this could seriously harm uptake - or themes could opt-out that would not help users of legacy, unmaintained themes which are no longer updated. (Maybe a remove-guttenburn plugin would be sufficient for users of legacy themes though?)

But, regardless of implementation, I do think that the current view should remain, even if it is increasingly hidden from the majority of users...

@steveangstrom

This comment has been minimized.

Show comment
Hide comment
@steveangstrom

steveangstrom Jun 24, 2017

I like the theoretical idea of CPTs explicitly requesting 'supports' => array( 'gutenberg' ) to maintain existing functionality in the case that the 'gutenberg' support flag is not defined. It would save me a lot of work fixing old sites for angry clients who updated to WP5.

I note that the existing 'supports' => features (title, editor, author, ...) have very self-descriptive names, Gutenberg stands out as a project name here. I wonder if a more descriptive feature name would be considered for that use; perhaps "block-editor"? 'supports' => array( 'block-editor' )

Of course there would need to be a strategy to catch mistakes such as 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . I'd assume the 'block-editor' flag would simply over-ride the older 'editor' mode.

I like the theoretical idea of CPTs explicitly requesting 'supports' => array( 'gutenberg' ) to maintain existing functionality in the case that the 'gutenberg' support flag is not defined. It would save me a lot of work fixing old sites for angry clients who updated to WP5.

I note that the existing 'supports' => features (title, editor, author, ...) have very self-descriptive names, Gutenberg stands out as a project name here. I wonder if a more descriptive feature name would be considered for that use; perhaps "block-editor"? 'supports' => array( 'block-editor' )

Of course there would need to be a strategy to catch mistakes such as 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . I'd assume the 'block-editor' flag would simply over-ride the older 'editor' mode.

@davekiss

This comment has been minimized.

Show comment
Hide comment
@davekiss

davekiss Jun 25, 2017

Another plugin dev here with concerns.

If sidebar meta is only accessible via JS, what does this mean for PHP-registered metaboxes with a context of side? Moving those to the proposed Extended Settings section revokes the idea that those metaboxes are contextual.

As we're all aware, sidebars aren't only a good-looking design decision; they frequently hold relational content in a way that helps the user understand the priority of its contents and the relationship to the main content. Assigning a side metabox a different context due to a technical barrier seems a bit misguided.

Considering the progressive JS-ification of the admin area, these "legacy" metaboxes also provide plugin and theme developers a natural mounting point for self-contained React/Vue/other apps to provide additional functionality to the edit page.

The editor looks great, but please don't forget about the rest of the page.

Another plugin dev here with concerns.

If sidebar meta is only accessible via JS, what does this mean for PHP-registered metaboxes with a context of side? Moving those to the proposed Extended Settings section revokes the idea that those metaboxes are contextual.

As we're all aware, sidebars aren't only a good-looking design decision; they frequently hold relational content in a way that helps the user understand the priority of its contents and the relationship to the main content. Assigning a side metabox a different context due to a technical barrier seems a bit misguided.

Considering the progressive JS-ification of the admin area, these "legacy" metaboxes also provide plugin and theme developers a natural mounting point for self-contained React/Vue/other apps to provide additional functionality to the edit page.

The editor looks great, but please don't forget about the rest of the page.

@kevinpmiller

This comment has been minimized.

Show comment
Hide comment
@kevinpmiller

kevinpmiller Jun 26, 2017

I have had a chance to think about this a little more and with some context shared by others here I think there is yet another issue. This new editor is forcing us into a single layout and workflow; why are we removing customization? The ability to sculpt data entry on a per client basis is what makes WordPress and most other solutions really great. The more I play with this editor the more it feels like a bloated version of the Customizer where the preview area has been replaced with an editor and the sidebar just switched sides.

It's also been mentioned that we could use this for writing posts, but allow CPTs to add support for this. I don't think that will really work either. News organizations would love this type of editor but also have a requirement for custom workflows around additional content, scheduling, embeds, infographics, and other data needed.

What about making this editor behave like the full-screen/distraction-free editor? This way we could have the best of both worlds without sacrificing functionality and "legacy" code. (BTW - I think it's ridiculous that the way we currently build meta boxes is now being referred to as "legacy ..." in this project).

Thanks for your time guys, it's appreciated.

I have had a chance to think about this a little more and with some context shared by others here I think there is yet another issue. This new editor is forcing us into a single layout and workflow; why are we removing customization? The ability to sculpt data entry on a per client basis is what makes WordPress and most other solutions really great. The more I play with this editor the more it feels like a bloated version of the Customizer where the preview area has been replaced with an editor and the sidebar just switched sides.

It's also been mentioned that we could use this for writing posts, but allow CPTs to add support for this. I don't think that will really work either. News organizations would love this type of editor but also have a requirement for custom workflows around additional content, scheduling, embeds, infographics, and other data needed.

What about making this editor behave like the full-screen/distraction-free editor? This way we could have the best of both worlds without sacrificing functionality and "legacy" code. (BTW - I think it's ridiculous that the way we currently build meta boxes is now being referred to as "legacy ..." in this project).

Thanks for your time guys, it's appreciated.

@BE-Webdesign

This comment has been minimized.

Show comment
Hide comment
@BE-Webdesign

BE-Webdesign Aug 24, 2017

Contributor

What I want is a solution that remains this flexible in the long term. Whether the metaboxes need to be updated to a shiny new JS format, become proper blocks or some other change needs to happen to make this possible doesn't really bother me. I want the flexibility we currently enjoy to be included in Gutenberg regardless of the method used to get there.

That is the goal and what most people want.

Contributor

BE-Webdesign commented Aug 24, 2017

What I want is a solution that remains this flexible in the long term. Whether the metaboxes need to be updated to a shiny new JS format, become proper blocks or some other change needs to happen to make this possible doesn't really bother me. I want the flexibility we currently enjoy to be included in Gutenberg regardless of the method used to get there.

That is the goal and what most people want.

@wpmark

This comment has been minimized.

Show comment
Hide comment
@wpmark

wpmark Aug 31, 2017

I have listened to a lot of chatter about the meta box issue and what will happen to them with this new editor. My personal view is that Gutenberg should focus on just the editor and not the entire page edit screen. But it seems that decision has already been made.

wpmark commented Aug 31, 2017

I have listened to a lot of chatter about the meta box issue and what will happen to them with this new editor. My personal view is that Gutenberg should focus on just the editor and not the entire page edit screen. But it seems that decision has already been made.

@atanas-angelov-dev

This comment has been minimized.

Show comment
Hide comment
@atanas-angelov-dev

atanas-angelov-dev Sep 1, 2017

Hi guys,

I'm the lead developer for Carbon Fields and wanted to add the list of actions/filter we use that may be affected:

Filters:

  • postbox_classes_{$page}_{$id}

Actions:

  • init
  • admin_menu
  • admin_init
  • wp
  • admin_enqueue_scripts
  • in_admin_header
  • admin_notices
  • admin_print_footer_scripts
  • save_post
  • edit_comment
  • media_buttons
  • edit_form_after_title (positioning sugar - not critical)

My questions:

  • If we are going to keep legacy meta boxes how would they interact with data changes?
  • What type of events (jQuery? some exposed implementation of an emitter?) and what events exactly can we expect from the new editor (e.g. on submission success, failure etc.)?
  • Will these events be available to legacy meta boxes or only to React implementations?

PS:
I just want to thank the Gutenberg team for all the hard work and effort and it makes me excited that WordPress is moving towards modern tools and solutions (even if the journey seems scary)!

Hi guys,

I'm the lead developer for Carbon Fields and wanted to add the list of actions/filter we use that may be affected:

Filters:

  • postbox_classes_{$page}_{$id}

Actions:

  • init
  • admin_menu
  • admin_init
  • wp
  • admin_enqueue_scripts
  • in_admin_header
  • admin_notices
  • admin_print_footer_scripts
  • save_post
  • edit_comment
  • media_buttons
  • edit_form_after_title (positioning sugar - not critical)

My questions:

  • If we are going to keep legacy meta boxes how would they interact with data changes?
  • What type of events (jQuery? some exposed implementation of an emitter?) and what events exactly can we expect from the new editor (e.g. on submission success, failure etc.)?
  • Will these events be available to legacy meta boxes or only to React implementations?

PS:
I just want to thank the Gutenberg team for all the hard work and effort and it makes me excited that WordPress is moving towards modern tools and solutions (even if the journey seems scary)!

@CreativeDive

This comment has been minimized.

Show comment
Hide comment
@CreativeDive

CreativeDive Sep 2, 2017

Supporting meta boxes is very important ...

... for thousands of wordpress developers and users.

WordPress can't ignore the big plugin player ...

... like Advacend Custom Fields Pro (elliotcondon/acf#622), WooCommerce or Yoast SEO.

CreativeDive commented Sep 2, 2017

Supporting meta boxes is very important ...

... for thousands of wordpress developers and users.

WordPress can't ignore the big plugin player ...

... like Advacend Custom Fields Pro (elliotcondon/acf#622), WooCommerce or Yoast SEO.

@amirhelzer

This comment has been minimized.

Show comment
Hide comment
@amirhelzer

amirhelzer Sep 3, 2017

I'm responsible for Toolset project, which uses custom types, fields and taxonomy heavily.

We want to make our plugins compatible with Gutenberg.

This is what I understand:

  • We will need to use a new API to display the custom fields and taxonomy on pages and posts, when they use Gutenberg.
  • We don't need to do anything about Gutenberg for CPTs, because they will use the normal WordPress editor and not Gutenberg.

Is this correct? If so, could you kindly refer me to the documentation for the API for displaying custom boxes on Gutenberg?

I'm responsible for Toolset project, which uses custom types, fields and taxonomy heavily.

We want to make our plugins compatible with Gutenberg.

This is what I understand:

  • We will need to use a new API to display the custom fields and taxonomy on pages and posts, when they use Gutenberg.
  • We don't need to do anything about Gutenberg for CPTs, because they will use the normal WordPress editor and not Gutenberg.

Is this correct? If so, could you kindly refer me to the documentation for the API for displaying custom boxes on Gutenberg?

@dmccan

This comment has been minimized.

Show comment
Hide comment

dmccan commented Sep 3, 2017

I think the docs are still evolving. There are some docs at https://github.com/WordPress/gutenberg/tree/master/docs -- http://gutenberg-devdoc.surge.sh/

@konamac

This comment has been minimized.

Show comment
Hide comment
@konamac

konamac Sep 4, 2017

I'm hearing what @BE-Webdesign and others are saying about the intent to minimise disruption - thanks, that's reassuring - but just wanted to add my 5p's worth (ok, ok, my usual 105p's worth.)

Anyone who's been developing for a while will remember the pain of manually creating web interfaces for bespoke databases - boring, time-consuming, error-prone and very expensive in terms of developer time.

WordPress plus Advanced Custom Fields (Pro) is a great tool for efficiently creating bespoke database-driven websites (and even intranet data management tools) with attractive front ends, rigorous data-entry checking, intuitive and consistent user interfaces etc. These systems may not be scalable for enormous volumes of relational data, but in very many cases they don't need to be; these are simple systems that can be created in a cost-effective way for clients. This is what makes WordPress a really useful CMS (and, in effect, a lightweight RDBMS), not just a blogging platform.

I (and I'm sure many other) small businesses use WP+ACF (or similar custom data plugins) to create bespoke sites and systems for client organisations and individuals who don't have big IT budgets. If the introduction of Gutenberg is done without due consideration for supporting existing editing/data-entry flows, metaboxes etc, I have two "non-technical" but nonetheless significant problems:

1/ My end users will require re-training (it's easy for us, as techies, to forget how massively confused non-technical users can get by interface changes - I wrote the Clarify Password Reset plugin because I was losing so much time sorting out users who were totally stymied by the new password reset process introduced in 4.3).

2/ As well as upgrading my own plugins for a different metabox approach, I will have to spend time upgrading and testing all my client sites with a professional level of diligence, making sure that any and all of the third-party plugins I'm using have also managed to update their codebase correctly. (And this in a situation where I have no control over how rapidly the third-party plugins are updated, either in advance of or (even worse) sometime after the 5.0 release - so workload-planning becomes really difficult.)

In neither of the above cases would I feel it was right to charge my clients further fees for that additional work; after all, I chose the platform on which to build their sites and systems, and it's not like they've requested any changes or improvements. Maybe I'm "too nice" or naive on that front, but as people have mentioned above, it's a trust issue; we trust WordPress not to drop us in the poo by breaking backwards compatibility, so that our clients can trust us not to sting them for unexpected extra fees. The net result is that I suddenly have a huge amount of extra unpaid work to somehow fit in - possibly urgently, if sites are actively broken by the upgrade right away - while continuing to do enough paid work to stay afloat.

I really like using WordPress, and have invested much time learning the ropes, developing my own handy project frameworks etc - to the point where I now make most of my living (and feed my family etc) via WordPress-based development projects. I've also tried to give something back by taking the time to formally release useful little plugins I've developed onto WordPress.com, because I value OSS, community-based development etc. I guess this is mostly a plea to take the issues mentioned in this issue thread to heart as much as possible; otherwise I agree that there's a real danger that the codebase might get forked. As a WordPress fan and plugin contributor, I would think this a REALLY bad outcome; however, as a solo developer relying on WP to make my living, I might have to go with the forked (i.e. properly backwards-compatible) version out of economic necessity. Please don't let this happen!

konamac commented Sep 4, 2017

I'm hearing what @BE-Webdesign and others are saying about the intent to minimise disruption - thanks, that's reassuring - but just wanted to add my 5p's worth (ok, ok, my usual 105p's worth.)

Anyone who's been developing for a while will remember the pain of manually creating web interfaces for bespoke databases - boring, time-consuming, error-prone and very expensive in terms of developer time.

WordPress plus Advanced Custom Fields (Pro) is a great tool for efficiently creating bespoke database-driven websites (and even intranet data management tools) with attractive front ends, rigorous data-entry checking, intuitive and consistent user interfaces etc. These systems may not be scalable for enormous volumes of relational data, but in very many cases they don't need to be; these are simple systems that can be created in a cost-effective way for clients. This is what makes WordPress a really useful CMS (and, in effect, a lightweight RDBMS), not just a blogging platform.

I (and I'm sure many other) small businesses use WP+ACF (or similar custom data plugins) to create bespoke sites and systems for client organisations and individuals who don't have big IT budgets. If the introduction of Gutenberg is done without due consideration for supporting existing editing/data-entry flows, metaboxes etc, I have two "non-technical" but nonetheless significant problems:

1/ My end users will require re-training (it's easy for us, as techies, to forget how massively confused non-technical users can get by interface changes - I wrote the Clarify Password Reset plugin because I was losing so much time sorting out users who were totally stymied by the new password reset process introduced in 4.3).

2/ As well as upgrading my own plugins for a different metabox approach, I will have to spend time upgrading and testing all my client sites with a professional level of diligence, making sure that any and all of the third-party plugins I'm using have also managed to update their codebase correctly. (And this in a situation where I have no control over how rapidly the third-party plugins are updated, either in advance of or (even worse) sometime after the 5.0 release - so workload-planning becomes really difficult.)

In neither of the above cases would I feel it was right to charge my clients further fees for that additional work; after all, I chose the platform on which to build their sites and systems, and it's not like they've requested any changes or improvements. Maybe I'm "too nice" or naive on that front, but as people have mentioned above, it's a trust issue; we trust WordPress not to drop us in the poo by breaking backwards compatibility, so that our clients can trust us not to sting them for unexpected extra fees. The net result is that I suddenly have a huge amount of extra unpaid work to somehow fit in - possibly urgently, if sites are actively broken by the upgrade right away - while continuing to do enough paid work to stay afloat.

I really like using WordPress, and have invested much time learning the ropes, developing my own handy project frameworks etc - to the point where I now make most of my living (and feed my family etc) via WordPress-based development projects. I've also tried to give something back by taking the time to formally release useful little plugins I've developed onto WordPress.com, because I value OSS, community-based development etc. I guess this is mostly a plea to take the issues mentioned in this issue thread to heart as much as possible; otherwise I agree that there's a real danger that the codebase might get forked. As a WordPress fan and plugin contributor, I would think this a REALLY bad outcome; however, as a solo developer relying on WP to make my living, I might have to go with the forked (i.e. properly backwards-compatible) version out of economic necessity. Please don't let this happen!

@brograhamer

This comment has been minimized.

Show comment
Hide comment
@brograhamer

brograhamer Sep 6, 2017

@konamac makes some great points, some of which I've posted about in another thread.

To piggyback off of this, it is entirely unacceptable to not give us a reassuring answer on the future of metaboxes.

  1. There is no straightforward answer to the future support of existing metaboxes. This is an extremely frustrating and heavy handed move against development agencies and theme / plugin authors. "Gutenberg is open source, so figure it out yourselves" is irresponsible.

  2. Gutenberg is awesome. I love the interface, the visual design, and I do think this is the way of the future in terms of editing content. But it is far behind where it needs to be in order to consider it for a 4.9 or 5.0 release.

  3. Everything I should be able to do in legacy is everything I should be able to do in Gutenberg.

  • Screen options
  • Meta Boxes (ACF, Yoast, etc)
  • Permalinks?! I can't even begin to understand why this isn't editable in 1.0 yet
  • Classic content block does NOT load properly in localhost environments
  • Documentation MUST be key in order to create different style blocks. Give several examples, several use cases. Not every theme developer is backend, so don't assume. Be crystal clear
  • Block settings need work. It is very difficult to tell what settings are available per block. Seems random. When do I need to edit block settings vs when do I not?
  • The whole comment tags around Gutenberg text editor is ... sad to see.

Some of us are getting extremely frustrated with this process. It should be a dead simple answer.

Will Gutenberg protect the current use of metaboxes / ACF, and are there plans in place to ensure such support indefinitely?

We don't need to know what the solution is right now - we know you're figuring it out. But we still don't have a CLEAR answer on this. ACF in particular needs to work the same exact way it always has to support older clients that will NOT agree to being charged to update - especially when discussing removing legacy editor at some point (how can you even begin to have that conversation right now?!)

Love Gutenberg. But I have to join the choir - this is getting ridiculous. The way the project team has communicated this expectation has not been simple. Yes or no is all we are looking for.

brograhamer commented Sep 6, 2017

@konamac makes some great points, some of which I've posted about in another thread.

To piggyback off of this, it is entirely unacceptable to not give us a reassuring answer on the future of metaboxes.

  1. There is no straightforward answer to the future support of existing metaboxes. This is an extremely frustrating and heavy handed move against development agencies and theme / plugin authors. "Gutenberg is open source, so figure it out yourselves" is irresponsible.

  2. Gutenberg is awesome. I love the interface, the visual design, and I do think this is the way of the future in terms of editing content. But it is far behind where it needs to be in order to consider it for a 4.9 or 5.0 release.

  3. Everything I should be able to do in legacy is everything I should be able to do in Gutenberg.

  • Screen options
  • Meta Boxes (ACF, Yoast, etc)
  • Permalinks?! I can't even begin to understand why this isn't editable in 1.0 yet
  • Classic content block does NOT load properly in localhost environments
  • Documentation MUST be key in order to create different style blocks. Give several examples, several use cases. Not every theme developer is backend, so don't assume. Be crystal clear
  • Block settings need work. It is very difficult to tell what settings are available per block. Seems random. When do I need to edit block settings vs when do I not?
  • The whole comment tags around Gutenberg text editor is ... sad to see.

Some of us are getting extremely frustrated with this process. It should be a dead simple answer.

Will Gutenberg protect the current use of metaboxes / ACF, and are there plans in place to ensure such support indefinitely?

We don't need to know what the solution is right now - we know you're figuring it out. But we still don't have a CLEAR answer on this. ACF in particular needs to work the same exact way it always has to support older clients that will NOT agree to being charged to update - especially when discussing removing legacy editor at some point (how can you even begin to have that conversation right now?!)

Love Gutenberg. But I have to join the choir - this is getting ridiculous. The way the project team has communicated this expectation has not been simple. Yes or no is all we are looking for.

@wpmark

This comment has been minimized.

Show comment
Hide comment
@wpmark

wpmark Sep 6, 2017

@BE-Webdesign

when it is complete, will introduce the almighty meta boxes back in

Can I therefore suggest that you write an entire post on this very issue, that you HAVE in fact indicated, that meta boxes, as they are now, are going to stay please. This would prevent a lot of worried developers in the community who are worried about their businesses.

Additionally I would encourage the team to make this a priority to add these in now. This would prevent a lot of the negativity around the project I am sure.

wpmark commented Sep 6, 2017

@BE-Webdesign

when it is complete, will introduce the almighty meta boxes back in

Can I therefore suggest that you write an entire post on this very issue, that you HAVE in fact indicated, that meta boxes, as they are now, are going to stay please. This would prevent a lot of worried developers in the community who are worried about their businesses.

Additionally I would encourage the team to make this a priority to add these in now. This would prevent a lot of the negativity around the project I am sure.

@connerbw connerbw referenced this issue Sep 7, 2017

Closed

Gutenberg compatibility #924

4 of 4 tasks complete
@rilwis

This comment has been minimized.

Show comment
Hide comment
@rilwis

rilwis Sep 8, 2017

As stated in #2308, I copied the hooks that Meta Box plugin uses when creating/saving custom fields:

  • Scripts, styles are enqueued using admin_enqueue_scripts. We do check for the current screen (via get_current_screen) to make sure scripts and styles are enqueued only for that pages. For the core plugin, it checks by post types. For extensions (term meta, user meta, settings page), it checks more for taxonomies, user profile page or settings pages.
  • We also use print_media_templates to print Underscore templates.
  • Scripts we use in the plugin includes: color picker, underscore, backbone, media scripts, tinymce (for the editor field)
  • We use init to initialize all the hooks for the plugin.
  • Meta boxes are registered using add_meta_boxes hooks.
  • Hidden meta boxes use default_hidden_meta_boxes.
  • We also hook to post_edit_form_tag to allow upload files.
  • We use save_post_{$post_type} and edit_attachment, add_attachment to save meta values for posts and attachments.

rilwis commented Sep 8, 2017

As stated in #2308, I copied the hooks that Meta Box plugin uses when creating/saving custom fields:

  • Scripts, styles are enqueued using admin_enqueue_scripts. We do check for the current screen (via get_current_screen) to make sure scripts and styles are enqueued only for that pages. For the core plugin, it checks by post types. For extensions (term meta, user meta, settings page), it checks more for taxonomies, user profile page or settings pages.
  • We also use print_media_templates to print Underscore templates.
  • Scripts we use in the plugin includes: color picker, underscore, backbone, media scripts, tinymce (for the editor field)
  • We use init to initialize all the hooks for the plugin.
  • Meta boxes are registered using add_meta_boxes hooks.
  • Hidden meta boxes use default_hidden_meta_boxes.
  • We also hook to post_edit_form_tag to allow upload files.
  • We use save_post_{$post_type} and edit_attachment, add_attachment to save meta values for posts and attachments.
@jacksellwood

This comment has been minimized.

Show comment
Hide comment
@jacksellwood

jacksellwood Sep 8, 2017

What's wrong with building out hooks to display metaboxes above/below/sidebar of Gutenberg?

What's wrong with building out hooks to display metaboxes above/below/sidebar of Gutenberg?

@gschoppe

This comment has been minimized.

Show comment
Hide comment
@gschoppe

gschoppe Sep 9, 2017

Figured I might as well do what third-party developers do best, and throw another massive wrench in the works.

Mattias tells us that metaboxes can be reimagined as blocks that store to post_meta. If that is a goal for merge, then there are some issues to iron out:

Many metaboxes register the_editor($custom_id); for this to be supported in the context of Gutenberg, either an interface and api for creating nested blocks is necessary from day one, or we are saying that metaboxes can only have the second-class editor interface, without any of the benefits of blocks. This will be particularly problematic for the large number of agencies that currently design using ACF Flexible Layouts, as they will need a way to create separate Gutenberg blocks for various contexts and areas. Even "thinking in blocks" I don't see a good way to solve the "content-area followed by template part followed by content area" issue without supporting nesting in "metablocks" from day one.

Stemming from that, is the technical concern of nesting with regard to blocks that are not stored in post_content. Mattias says blocks will be able to store to postmeta, but if a block can define where it is stored, how will nesting work, when a parent block stores to postmeta, and the user adds a child that stores to a different post_meta... (Or in the pathological case, a nested block Tha stores to postmeta contains a block that stores to the same postmeta field.

This leads to a third metabox concern. If Gutenberg is a full edit page replacement, rather than a replacement for the_editor(), how will people be able to enqueue and use blocks on other pages and in other contexts, such as metaboxes or custom admin panels that use the_editor(). It appears at first glance that the answer will be "they can't". Which leads to some serious concerns as to whether Gutenberg adds flexibility to custom CMS implementations, or takes it away.

If users are given the option of Gutenberg, and it is as revolutionary for them as claimed, not being able to provide that new interface in these instances could prove disastrous for agencies.

gschoppe commented Sep 9, 2017

Figured I might as well do what third-party developers do best, and throw another massive wrench in the works.

Mattias tells us that metaboxes can be reimagined as blocks that store to post_meta. If that is a goal for merge, then there are some issues to iron out:

Many metaboxes register the_editor($custom_id); for this to be supported in the context of Gutenberg, either an interface and api for creating nested blocks is necessary from day one, or we are saying that metaboxes can only have the second-class editor interface, without any of the benefits of blocks. This will be particularly problematic for the large number of agencies that currently design using ACF Flexible Layouts, as they will need a way to create separate Gutenberg blocks for various contexts and areas. Even "thinking in blocks" I don't see a good way to solve the "content-area followed by template part followed by content area" issue without supporting nesting in "metablocks" from day one.

Stemming from that, is the technical concern of nesting with regard to blocks that are not stored in post_content. Mattias says blocks will be able to store to postmeta, but if a block can define where it is stored, how will nesting work, when a parent block stores to postmeta, and the user adds a child that stores to a different post_meta... (Or in the pathological case, a nested block Tha stores to postmeta contains a block that stores to the same postmeta field.

This leads to a third metabox concern. If Gutenberg is a full edit page replacement, rather than a replacement for the_editor(), how will people be able to enqueue and use blocks on other pages and in other contexts, such as metaboxes or custom admin panels that use the_editor(). It appears at first glance that the answer will be "they can't". Which leads to some serious concerns as to whether Gutenberg adds flexibility to custom CMS implementations, or takes it away.

If users are given the option of Gutenberg, and it is as revolutionary for them as claimed, not being able to provide that new interface in these instances could prove disastrous for agencies.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Sep 14, 2017

Contributor

There is no straightforward answer to the future support of existing metaboxes.

I've said repeatedly we are going to account for meta-boxes. The only uncertainty is what is technically viable and how it will be displayed in the new UI.

We are not attempting to break anything—shortcodes, custom fields, etc—all should still work. The UI to interact with them might change (unless you disable Gutenberg completely), and certain use cases for meta-boxes are going to be a better fit for blocks going forwards.

Gutenberg is awesome. I love the interface, the visual design, and I do think this is the way of the future in terms of editing content.

I'm glad to hear!

Permalinks?! I can't even begin to understand why this isn't editable in 1.0 yet

Because the REST API doesn't support this yet. Any help is welcome: #1285

Contributor

mtias commented Sep 14, 2017

There is no straightforward answer to the future support of existing metaboxes.

I've said repeatedly we are going to account for meta-boxes. The only uncertainty is what is technically viable and how it will be displayed in the new UI.

We are not attempting to break anything—shortcodes, custom fields, etc—all should still work. The UI to interact with them might change (unless you disable Gutenberg completely), and certain use cases for meta-boxes are going to be a better fit for blocks going forwards.

Gutenberg is awesome. I love the interface, the visual design, and I do think this is the way of the future in terms of editing content.

I'm glad to hear!

Permalinks?! I can't even begin to understand why this isn't editable in 1.0 yet

Because the REST API doesn't support this yet. Any help is welcome: #1285

@kevinwhoffman

This comment has been minimized.

Show comment
Hide comment
@kevinwhoffman

kevinwhoffman Sep 14, 2017

Contributor

I've said repeatedly we are going to account for meta-boxes.

@mtias I think the confusion regarding support of meta boxes results from @m suggesting that a legacy plugin will be available to restore existing functionality. It would be helpful to clarify what aspects of the existing interface (meta boxes, meta box positions, hooks, etc.) will continue to work with Gutenberg versus which aspects require the legacy plugin to continue working.

Contributor

kevinwhoffman commented Sep 14, 2017

I've said repeatedly we are going to account for meta-boxes.

@mtias I think the confusion regarding support of meta boxes results from @m suggesting that a legacy plugin will be available to restore existing functionality. It would be helpful to clarify what aspects of the existing interface (meta boxes, meta box positions, hooks, etc.) will continue to work with Gutenberg versus which aspects require the legacy plugin to continue working.

@brograhamer

This comment has been minimized.

Show comment
Hide comment
@brograhamer

brograhamer Sep 14, 2017

I've said repeatedly we are going to account for meta-boxes.

@mtias my apologies, I must have missed your clarification elsewhere. Glad to hear! Make the current iteration visually more appealing and purposeful and it'll be a huge success.

I understand what you're saying about REST API support, I will watch the thread for updates.

Thank you for clarifying. Now that I have this insight I am full speed ahead for Gutenberg - all my fears are set aside.

I've said repeatedly we are going to account for meta-boxes.

@mtias my apologies, I must have missed your clarification elsewhere. Glad to hear! Make the current iteration visually more appealing and purposeful and it'll be a huge success.

I understand what you're saying about REST API support, I will watch the thread for updates.

Thank you for clarifying. Now that I have this insight I am full speed ahead for Gutenberg - all my fears are set aside.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Sep 14, 2017

Contributor

@kevinwhoffman right, I think the heart of the issue is that "existing functionality" includes the presentation as well—and since Gutenberg significantly changes the UI getting back to the previous one would require the plugin to disable. How meta-boxes fit in the new UI and how old meta-boxes can be supported without developer intervention are the things being worked on. I don't know exactly how that will work out, so I haven't been able to promise a specific outcome. I also think this could end up in a clearer presentation of meta-boxes features.

@brograhamer no apology needed, it's a large thread! We don't want to rush anything, and this is a pretty big project with many moving parts. At times some things may seem neglected, but that doesn't mean we are not planning on solving them.

Contributor

mtias commented Sep 14, 2017

@kevinwhoffman right, I think the heart of the issue is that "existing functionality" includes the presentation as well—and since Gutenberg significantly changes the UI getting back to the previous one would require the plugin to disable. How meta-boxes fit in the new UI and how old meta-boxes can be supported without developer intervention are the things being worked on. I don't know exactly how that will work out, so I haven't been able to promise a specific outcome. I also think this could end up in a clearer presentation of meta-boxes features.

@brograhamer no apology needed, it's a large thread! We don't want to rush anything, and this is a pretty big project with many moving parts. At times some things may seem neglected, but that doesn't mean we are not planning on solving them.

@cr101

This comment has been minimized.

Show comment
Hide comment
@cr101

cr101 Sep 27, 2017

I'm currently building a web app using ACF with 10 custom post types which don't use the tinymce editor. I'm using the Title feature and about 15 ACF fields on average for each CPT.
Currently you can declare which features (i.e editor, thumbnail, excerpt, etc) a CPT supports.
Will it be possible to hide/remove the "Write your story" paragraph block as well as the "Insert block" icon from the edit screen?

cr101 commented Sep 27, 2017

I'm currently building a web app using ACF with 10 custom post types which don't use the tinymce editor. I'm using the Title feature and about 15 ACF fields on average for each CPT.
Currently you can declare which features (i.e editor, thumbnail, excerpt, etc) a CPT supports.
Will it be possible to hide/remove the "Write your story" paragraph block as well as the "Insert block" icon from the edit screen?

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Sep 28, 2017

Contributor

@cr101 I think we if you drop the "editor" from your CPT supports, we should probably drop the block inserter and the blocks from Gutenberg, seems logical to me.

On the other hand, with the v1 of metaboxes, the metaboxes panes can be expanded from the bottom, if we keep this, we should ensure that it's always "open" for CPTs without "editor" supports. It might not be necessary if the metaboxes are always shown under the editor (like some of the design suggestions above)

Contributor

youknowriad commented Sep 28, 2017

@cr101 I think we if you drop the "editor" from your CPT supports, we should probably drop the block inserter and the blocks from Gutenberg, seems logical to me.

On the other hand, with the v1 of metaboxes, the metaboxes panes can be expanded from the bottom, if we keep this, we should ensure that it's always "open" for CPTs without "editor" supports. It might not be necessary if the metaboxes are always shown under the editor (like some of the design suggestions above)

@jawittdesigns

This comment has been minimized.

Show comment
Hide comment
@jawittdesigns

jawittdesigns Sep 29, 2017

I'm not sure if this is the right place for this, but what about the core custom meta fields? There's been a lot of talk about third-party plugins but what about the core custom meta fields. I know it those aren't really that popular but I can think of a few sites I've worked on that use them.

Is there any plan in place for integrating the core custom meta fields into Gutenberg?

I'm not sure if this is the right place for this, but what about the core custom meta fields? There's been a lot of talk about third-party plugins but what about the core custom meta fields. I know it those aren't really that popular but I can think of a few sites I've worked on that use them.

Is there any plan in place for integrating the core custom meta fields into Gutenberg?

@BE-Webdesign

This comment has been minimized.

Show comment
Hide comment
@BE-Webdesign

BE-Webdesign Sep 29, 2017

Contributor

Hi @jawittdesigns,

I am pretty sure the core metaboxes ( at least most of them ) have been re-implemented already in Gutenberg! They feature some nicer work flows around handling taxonomies etc.

Contributor

BE-Webdesign commented Sep 29, 2017

Hi @jawittdesigns,

I am pretty sure the core metaboxes ( at least most of them ) have been re-implemented already in Gutenberg! They feature some nicer work flows around handling taxonomies etc.

@cr101

This comment has been minimized.

Show comment
Hide comment
@cr101

cr101 Oct 12, 2017

Not everyone uses WordPress for blogging. A lot of us use WordPress as a CMS. We are currently building a web app using the WordPress REST API and ACF. We have 10 custom post types and each CPT has 20 custom fields and all the CPTs are linked to each other via bidirectional relationships using ACF Relationship and Post Object fields and the ACF Post-2-Post plugin.

Gutenberg is of no use to us in its current form since we don't even use the current editor. We are only using the Title textbox for our CPTs and the rest is custom fields which get stored in post_meta table.

cr101 commented Oct 12, 2017

Not everyone uses WordPress for blogging. A lot of us use WordPress as a CMS. We are currently building a web app using the WordPress REST API and ACF. We have 10 custom post types and each CPT has 20 custom fields and all the CPTs are linked to each other via bidirectional relationships using ACF Relationship and Post Object fields and the ACF Post-2-Post plugin.

Gutenberg is of no use to us in its current form since we don't even use the current editor. We are only using the Title textbox for our CPTs and the rest is custom fields which get stored in post_meta table.

@plasterdog

This comment has been minimized.

Show comment
Hide comment
@plasterdog

plasterdog Nov 21, 2017

I strongly believe that the Gutenberg editor should not become part of core in its' current state. I recognize that WordPress as a project needs to play somewhat to those site builders who do not work with their own custom themes … however the Gutenberg editor seems to be a direct attack on those of us who use Advanced Custom Fields to make complex entry of content fairly “idiot proof” for site owners by giving them a very specific way to enter their content. The Gutenberg editor in its' current state seems to be a direct attack on those of us who use ACF.
With the Gutenberg plugin the edit link in the header sends the user directly into the Gutenberg interface which does not show ANY of the ACF meta-boxes, and has no screen options tab at the top of the screen to activate them. Yes the user can go back to the page/post array and choose the “classic editor” option and then see the meta-boxes but this means that an extra step needs to be taken by the site editor to get to the ACF fields. Not exactly optimal considering that the goal of using ACF in many cases was to make editing of complex layouts more fluid and straight-forward for a non-technical editor.

I strongly believe that the Gutenberg editor should not become part of core in its' current state. I recognize that WordPress as a project needs to play somewhat to those site builders who do not work with their own custom themes … however the Gutenberg editor seems to be a direct attack on those of us who use Advanced Custom Fields to make complex entry of content fairly “idiot proof” for site owners by giving them a very specific way to enter their content. The Gutenberg editor in its' current state seems to be a direct attack on those of us who use ACF.
With the Gutenberg plugin the edit link in the header sends the user directly into the Gutenberg interface which does not show ANY of the ACF meta-boxes, and has no screen options tab at the top of the screen to activate them. Yes the user can go back to the page/post array and choose the “classic editor” option and then see the meta-boxes but this means that an extra step needs to be taken by the site editor to get to the ACF fields. Not exactly optimal considering that the goal of using ACF in many cases was to make editing of complex layouts more fluid and straight-forward for a non-technical editor.

@pento

This comment has been minimized.

Show comment
Hide comment
@pento

pento Nov 29, 2017

Member

What a long running issue this has been!

With the merge of #3345 and #3554, meta box support is at a state we're happy to call feature complete. Note that this is different from complete, as there's obviously still work to be done on polishing the meta box experience, particularly around styling, more complex JavaScript handling, and determining rules for falling back to the classic editor.

Thank you to every who has constructively participated in this issue, I do understand it's been a difficult, and occasionally controversial process. For a documentation on how Gutenberg handles meta boxes, and how you (if you prefer) can mark meta boxes as being incompatible with Gutenberg, please see the handbook.

If you run into bugs associated with particular plugins or meta boxes, please open a new issue, so it can be tracked correctly, and fixed.

Member

pento commented Nov 29, 2017

What a long running issue this has been!

With the merge of #3345 and #3554, meta box support is at a state we're happy to call feature complete. Note that this is different from complete, as there's obviously still work to be done on polishing the meta box experience, particularly around styling, more complex JavaScript handling, and determining rules for falling back to the classic editor.

Thank you to every who has constructively participated in this issue, I do understand it's been a difficult, and occasionally controversial process. For a documentation on how Gutenberg handles meta boxes, and how you (if you prefer) can mark meta boxes as being incompatible with Gutenberg, please see the handbook.

If you run into bugs associated with particular plugins or meta boxes, please open a new issue, so it can be tracked correctly, and fixed.

@coffeeneed

This comment has been minimized.

Show comment
Hide comment
@coffeeneed

coffeeneed Feb 1, 2018

With respect, this should be far from feature complete.

With respect, this should be far from feature complete.

@WordPress WordPress locked as too heated and limited conversation to collaborators Feb 1, 2018

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Feb 1, 2018

Member

@coffeeneed If you'd like to be constructive, please open a new issue with sufficient detail for us to assist. Thanks

Member

danielbachhuber commented Feb 1, 2018

@coffeeneed If you'd like to be constructive, please open a new issue with sufficient detail for us to assist. Thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.