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

Editor: support custom fields / meta #587

Closed
diddledan opened this Issue Nov 24, 2015 · 16 comments

Comments

Projects
None yet
@diddledan

diddledan commented Nov 24, 2015

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).

@lancewillett lancewillett changed the title from Posts: custom fields to Editor: support custom post fields Nov 24, 2015

@lancewillett lancewillett changed the title from Editor: support custom post fields to Posts: support custom fields Nov 24, 2015

@lancewillett lancewillett added the Posts label Nov 24, 2015

@jeherve

This comment has been minimized.

@jeherve

This comment has been minimized.

Member

jeherve commented Dec 1, 2015

@coccoinomane

This comment has been minimized.

coccoinomane commented May 3, 2016

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

This comment has been minimized.

Member

aduth commented Aug 16, 2016

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

This comment has been minimized.

Member

aduth commented Aug 16, 2016

Related: #588

@aidanlane

This comment has been minimized.

aidanlane commented Aug 16, 2016

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

This comment has been minimized.

Member

aduth commented Aug 16, 2016

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

This comment has been minimized.

alexclst commented Aug 22, 2016

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

This comment has been minimized.

aidanlane commented Sep 27, 2016

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

This comment has been minimized.

Member

timmyc commented Oct 5, 2016

Related #720

@timmyc timmyc changed the title from Posts: support custom fields to Editor: support custom fields Mar 16, 2017

@timmyc timmyc changed the title from Editor: support custom fields to Editor: support custom fields / meta Mar 16, 2017

@timmyc

This comment has been minimized.

Member

timmyc commented Mar 16, 2017

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

This comment has been minimized.

lance-anderson commented Apr 27, 2017

👍

@monecchi

This comment has been minimized.

monecchi commented Apr 29, 2017

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

This comment has been minimized.

pablogiralt commented Jul 24, 2017

+1

@lancewillett

This comment has been minimized.

Member

lancewillett commented Dec 10, 2017

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.

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