Editor: support custom fields / meta

[lucyllewy]

I believe that Calypso currently cannot handle fields added by a plugin to existing post types. Ideally the UI should be able to display and allow editing of fields defined by plugins or themes that are non-standard. This may require changes to Core to provide a standardised API for adding and saving fields to post types (both in-built and custom post types/CPTs).

[jeherve]

Also suggested here:
https://wordpress.org/support/topic/display-custom-fields-in-post-editor?replies=1&view=all

[jeherve]

Also suggested here:
http://wptavern.com/automattic-unveils-open-source-wordpress-desktop-application-for-the-mac/comment-page-1#comment-107928

[jeherve]

Also suggested here:
https://wordpress.org/support/topic/custom-fields-in-desktop-app

[coccoinomane]

Hi! I second the OP suggestion. The lack of support for custom fields (ex. from ACF, which is a crucial part in about 50 of our websites) is currently a deal breaker for our agency. Thank you anyway for what you are doing: Calypso is wonderful :-)

[aduth]

Generally speaking, post meta and meta boxes are difficult to support because their structure isn't predictable and meta is often not meant to be managed by the user. WordPress 4.6 will bring us closer to being able to programmatically generate fields from post meta via its register_meta enhancements, at which point we could potentially generate fields based on the supported meta types for a post. Technically we could do this now, but the input would need to be generic enough to cover all use-cases (think <input type="text" />), and there's no way to differentiate meta which should be exposed via the API (enhanced by show_in_rest meta registration option in WordPress 4.6).

For first-party custom post types, we also have the option to implement one-off custom components in Calypso to support editing its meta.

[aduth]

Related: #588

[aidanlane]

Thanks for the update @aduth.

For first-party custom post types, we also have the option to implement one-off custom components in Calypso to support editing its meta.

Can plugin authors do this? We've gone 'all in' with ReactJS now, even using it thoughgout wp-admin. Hence, we hopefully be able to reuse many of our existing React components if allowed to bring them in to Calypso in a offical manner.

[aduth]

Can plugin authors do this?

This is made difficult by a few factors:

• There are huge security implications of allowing arbitrary markup to be included in Calypso
• Even if we were to embed assets from a Jetpack site, we're subject to mixed content safeguards, so the site must serve its assets over HTTPS. Even with Let's Encrypt, this is still a big ask of site owners

The <Shortcode /> component was an interesting experiment in how we could display markup as rendered from a Jetpack site for editor gallery previews, and I've thought that this could potentially be extended to plugins for custom screens or meta fields. That said, without forcing plugin authors to target the Calypso environment specifically, it's difficult to accommodate all use-cases given the extreme flexibility of WordPress hooks (e.g. add_meta_box enables you to echo whatever you'd like). And, of course, we're still subject to the second complication detailed above, which is a no-go for a majority of sites.

There's been some experimental approaches with plugins in the past (#1299), but that one in particular assumes that the plugin code would live within Calypso itself. Perhaps for popular plugins this would be a sensible consideration, but it's not very scalable in the sense of opening Calypso to the broader ecosystem of plugins.

[alexclst]

I'd love to see this implemented. While simple CPT editing is great being in Calypso many of the CPTs I have on sites have custom fields, so true full editing support from Calypso would require that this be in place.

[aidanlane]

Hi @aduth, thanks for the reply and apologies for my much belated one!

There are huge security implications of allowing arbitrary markup to be included in Calypso

True, this would require much thought from a security point of view, but it shouldn't be a show stopper.

Even if we were to embed assets from a Jetpack site, we're subject to mixed content safeguards, so the site must serve its assets over HTTPS. Even with Let's Encrypt, this is still a big ask of site owners

I see this creating two opportunities:

1. An even greater incentive for sites to move to HTTPS. Google created a massive incentive by favouring it with search. WordPress has the power to follow suite.
2. For Automattic: host these static resources for site owners via a paid Jetpack subscription. HTTPS cloud storage is cheap!

That said, without forcing plugin authors to target the Calypso environment specifically

Why not require them to target it?? Plugin authors could charge for upgrades that add Calypso environment support, as Calypso arguably adds a lot of value to end clients.

Last question: going forward, do you see custom distributions of Calypso being created, or do you see Calypso always coming from Automattic, with all 'customisation' coming via APIs?

Thanks!

[timmyc]

Related #720

[timmyc]

A user of the Duet theme also noted that two of their theme options are not usable via the Calypso Editor: https://en.blog.wordpress.com/2017/03/13/a-distraction-free-writing-space-at-wordpress-com/#comment-232887

[lance-anderson]

👍

[monecchi]

Calypso is great!, no doubt. However, the lack of such a functionality in Calypso is a shame. If a theme or plugin enables me to create custom fields and allows me to expose those fields to the WP API, why not in the world to have a specific exposure method for Calypso when it comes to custom fields?

I've read about security implications, and a lot of other stuff regarding the feasibility of having such an implementation, but I simply can't buy any of these arguments at all.

I'm more of a WordPress implementor than a developer, and most themes I manage rely solely on custom fields, that's what makes WordPress extensible and even better.

I'd really appreciate if anyone could enlighten me regarding this issue.

[pablogiralt]

+1

[lancewillett]

We're going to spend time on supporting Gutenberg on WP.com (coming soon) -- rather than retrofitting the existing Calypso editor. Closing as "wontfix" in that context.