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

Gutenberg support #2

Open
hacknug opened this issue Nov 7, 2018 · 8 comments · May be fixed by #5
Open

Gutenberg support #2

hacknug opened this issue Nov 7, 2018 · 8 comments · May be fixed by #5

Comments

@hacknug
Copy link

hacknug commented Nov 7, 2018

Hey there!

Gutenberg is soon to be released (oh my…) and I've been playing around with the latest ACF betas on a couple of sites. Since the post-edit markup changes, acf-native-fields doesn't work anymore.

Here's the two lines that need to change in order to support it:
https://github.com/winteragency/acf-native-fields/blob/4b4a1412af0a8d436a6280648f7135ee952ed2c1/js/acf-native-fields.js#L10&L11

And here's the dirty/quick fix that doesn't account for non-Gutenberg websites (although maybe it does, haven't tested it):

ACF_Native_Fields.editor_container = $('#post-body, #metaboxes');
ACF_Native_Fields.native_fields = $('.acf-native-field');

Let me know if you'd like me to open a PR with the changes after testing this out.

@marcusforsberg
Copy link
Member

marcusforsberg commented Feb 11, 2019

Hi @hacknug,

Sorry for the delayed response 😊

Thanks for testing this and looking into the fix! Unfortunately we still haven't moved over to Gutenberg for our sites, reverting instead to using Classic Editor for the time being. Thus, we haven't been able to ensure support for ACF Native Fields yet.

If you have the time, a PR would be more than welcome if you can ensure backwards compatibility with non-Gutenberg enabled sites!

@hacknug
Copy link
Author

hacknug commented Feb 11, 2019

@marcusforsberg perfect! Will take a look at this asap.

@marcusforsberg
Copy link
Member

@hacknug You're a hero, thanks! 🎉

@hacknug
Copy link
Author

hacknug commented Feb 19, 2019

@marcusforsberg any idea on how to get the installed WordPress version without using wp_localize_script? Was trying to avoid enqueuing anything else but I can't seem to find any other way.

@marcusforsberg
Copy link
Member

Hey @hacknug. I don't think there's a good way, no. I think the tag in wp-admin include a class name that mentions the version somehow, but that's probably not the cleanest way to go about it. That said, if you want to know the version to figure out if Gutenberg exists or not, please keep in mind to also see if the Classic Editor plugin is active even if it's WP 5.x+. :)

@hacknug
Copy link
Author

hacknug commented Mar 22, 2019

I think the tag in wp-admin include a class name that mentions the version somehow, but that's probably not the cleanest way to go about it.

Yeah, this wasn't even something I was considering since I get rid of it on my boilerplate theme haha

That said, if you want to know the version to figure out if Gutenberg exists or not, please keep in mind to also see if the Classic Editor plugin is active even if it's WP 5.x+.

Users can also set a different editor for every page/post.

@hacknug hacknug linked a pull request Mar 22, 2019 that will close this issue
@hacknug
Copy link
Author

hacknug commented Mar 22, 2019

Turns out there's a class on the body element when the editor's active, so it was pretty easy to solve 😄

@hacknug
Copy link
Author

hacknug commented Mar 22, 2019

Also worth noting that it's impossible to move most native fields around when using Gutenberg given that everything is managed by React and most things aren't actually in the DOM most of the time.

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

Successfully merging a pull request may close this issue.

2 participants