Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editor: support custom fields / meta #587

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

Editor: support custom fields / meta #587

diddledan opened this issue Nov 24, 2015 · 16 comments

Comments

@diddledan
Copy link

@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 Posts: custom fields Editor: support custom post fields Nov 24, 2015
@lancewillett lancewillett changed the title Editor: support custom post fields Posts: support custom fields Nov 24, 2015
@lancewillett lancewillett added the Posts label Nov 24, 2015
@coccoinomane
Copy link

@coccoinomane 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
Copy link
Contributor

@aduth 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
Copy link
Contributor

@aduth aduth commented Aug 16, 2016

Related: #588

@aidanlane
Copy link

@aidanlane 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
Copy link
Contributor

@aduth 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
Copy link

@alexclst 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
Copy link

@aidanlane 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
Copy link
Member

@timmyc timmyc commented Oct 5, 2016

Related #720

@timmyc timmyc changed the title Posts: support custom fields Editor: support custom fields Mar 16, 2017
@timmyc timmyc changed the title Editor: support custom fields Editor: support custom fields / meta Mar 16, 2017
@timmyc
Copy link
Member

@timmyc 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
Copy link

@lance-anderson lance-anderson commented Apr 27, 2017

👍

@monecchi
Copy link

@monecchi 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
Copy link

@pablogiralt pablogiralt commented Jul 24, 2017

+1

@lancewillett
Copy link
Member

@lancewillett 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet