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

Use the classic editor with REST #223

Open
alexstandiford opened this issue Jul 15, 2021 · 2 comments
Open

Use the classic editor with REST #223

alexstandiford opened this issue Jul 15, 2021 · 2 comments

Comments

@alexstandiford
Copy link

alexstandiford commented Jul 15, 2021

It appears that the "editor" setting is the only way to enable Sugar Calendar events via REST, but it doesn't seem to be possible to use the classic editor and also use REST. It would be nice if it were possible to use the classic editor and REST.

I think this is happening because the block editor is being disabled by manipulating the show_in_rest parameter. This solves the problem, but it disables the Sugar Calendar in REST endpoint, as well.

Instead, I suggest that Sugar Calendar always leaves the show_in_rest as true, and instead uses the'use_block_editor_for_post_type' filter is used to disable/enable the block-based editor. This will make it possible to switch between editors and still keep the REST API intact.

To Replicate:

  1. Set the editor setting to the block-based editor
  2. Visit {your-site}/wp-json/wp/v2/sc_event
  3. Observe post data response
  4. Change the editor setting to the classic editor
  5. Visit {your-site}/wp-json/wp/v2/sc_event
  6. Note that the REST endpoint is not available
@JJJ
Copy link
Contributor

JJJ commented Jul 19, 2021

Hey @alexstandiford 👋

I see what you're saying. I used the show_in_rest parameter because the use_block_editor_for_post_type function returns true by default instead of false, and Sugar Calendar technically still requires the opposite to avoid the double-negative of having our false setting mean true in the filter.

WordPress never should have forced the default to true there. 😤

Also, I didn't want to publicly expose only the Post Type (Events) and Taxonomy (Calendars) data without offering something for the data currently covered by BerlinDB (Dates, Times, Recurring, etc...)

It seemed inevitable to me that exposing the easy stuff immediately reveals to API users that the hard stuff is not available. When we do it, I don't want us to rush to do it because we shipped something halfway.

Related: berlindb/core#26
Also related: https://github.com/sugarcalendar/sc-manager

@alexstandiford
Copy link
Author

Thanks @JJJ!

In the meantime, I shared another issue that talks a bit on how I work around this. Sharing it here just in-case someone stumbles on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants