A lot of folks have been asking themselves why the outstanding Advanced Custom Fields plugin is still not baked into WP Core. Seeing the number of installs (1+ Mio) it certainly is not a wrong question to ask.
Out of backward compatiblity, and just easy of use, there should be an off-switch, at best supplied as a simple auto-load option (eg. ‘acf_in_core’ or ‘acf_base_integration’ or something like that). This would also ensure that future massive updates to the original ACF plugin may not collide with “our” core version, plus it’d still enable you to properly use ACF Pro
I’d also suggest keeping the ACF infrastructure (field groups CPT / taxonomies etc.) the very same, so in the case of eg. ACF 6 or maybe even a custom version for ClassicPress, one indeed just uses the “off” switch (or the plugin installation hook checks for the enabled option and just disables it automatically during plugin activation).
Suggested version to integrate is 5, not 4. I release its not released yet, only available in a preview relese from the ACF site, but its better to have up-to-date structures in place, than slightly outdated ones. Also, most people who use the pro version are already on 5.x.
My guess is that the official release of the base (“free”) version has been delayed thanks to a) the advend of Gutenborg and b) the overwhelmingly massive amount of reviews to be done by the Plugin Review Team (essentially it might just be stuck in the review pipeline).
Read-only archive : Issues · ClassicPress/ClassicPress · GitHub
Author : Fabian Wolf
Vote count : 19
Status : open
Tags :
difficulty-hard
request-add-feature
Comments
Adding custom post types, fields and taxonomies to WordPress core has long been discussed. And as far as I’m aware, WordPress core supports a lot of these functions, but just doesn’t have any interface for building them out, tying them together or easily displaying them.
I love the idea of making sure there is a way to build out custom post types in ClassicPress by default.
~ posted by Malcolm Alexander Peralty
The advantage of ACF is: Its code writing is up to par with the WP Core coding guidelines. I had to dig hard into it when trying to figure out why several translation plugins (including WPML) just didnt want to work 100% properly together with ACF. Turns out: ACF does everything right, so it was up to me writing helper plugin(s) and classes to handle the complex situation.
~ posted by Fabian Wolf
I vote to keep things as simple as possible. Leave functionality like ACF to dedicated plugins. I.e., leave ACF out of core. Return to WP original philosophy: “clean, lean, and mean”. Philosophy – WordPress.org
~ posted by Jeff Starr
I don’t agree with that for different reasons.
ACF is a plugin with a pro version, so integrate will show the project only a solution to promote ACF and upgrade it and pay for that
There is around a system of paid/pro support stuff that we cannot garantee
I don’t link ACF technically
Personally I am for solutions like CMB2 GitHub - CMB2/CMB2: CMB2 is a developer's toolkit for building metaboxes, custom fields, and forms for WordPress that will blow your mind. that is completelly open source and all the support happen on github and also addons are open source again.
In the past years that was a test to create an api internally in wordpress that this plugins/library/framework will be extended so I think that is best that way.
In that way we are not connected to a specific solution and we have a standard way that can be used without any plugins.
~ posted by Daniele Scasciafratte
I like ACF, but as mentioned it is a pro plugin so there would be a cost to use the full version - I think it would be great to have custom fields, post types, and taxonomies as a part of the core, but only if it is completely open source. Another thing about ACF is that it doesn’t integrate into some post types automatically, for example, using WooCommerce with ACF can be a real pain.
~ posted by Anji
I fully agree with @jeff starr
“And that is what plugins are for. Please keep core lightweight as possible. Anything that can be a plugin should be a plugin.”
ACF is great, and we use it for certain sites! But it belongs as a plugin and not core.
Why would we want third-party plugins to be core?
Would I’d really like to see is ClassicPress reach out to ACF and let them know the fork is in progress. I’d like to see ACF support ClassicPress.
~ posted by Avrom
Definitely agree with @jeff .
I am also a big time user of ACF Pro for many of my client websites, but core should be simple and lean.
It is not a big of a deal to install a plugin for extra functionallity.
+1 for letting Elliot from ACF know about ClassicPress
~ posted by Chris Chiotis
And what if we want to use a different one like CMB2? +1 for this is not core, it’s plugin territory
~ posted by Ashley Goodman
If anyone knows me then I’m sure you know that I am a fan of ACF. However, I would have to agree with keeping ACF, or any custom field plugin out of core. There are many different ways that people work and develop sites. ACF works for me but I also understand why it does not work for others.
My vote would be for improving the adding and updating of post/term/user meta to allow for these plugins to work better, but that’s another topic.
Yes, Eliot is already aware of ClassicPress.
~ posted by John A. Huebner II
I prefer Toolset, personally, but I’d really like an API that allows custom fields to be defined in code.
A “custom fields” plugin that is intended for core would probably look very different than existing solutions. It would mostly be an API that developers can build on top of, rather than a specific implementation of custom fields.
It could be used to implement a pretty huge variety of functionality, and it would be a great building block for the next 10 years of ClassicPress.
Here is an example of the sort of thing I’m talking about:
GitHub - sc0ttkclark/wordpress-fields-api: Fields API proposal for WordPress Core (2015-2017), starting up again in 2022/2023
~ posted by James Nylen
I don’t think we should include ACF or something other third party custom fields plugin, not even my own (https://wp-papi.github.io/ ).
Think it’s better to finish custom fields api so plugins can use it instead of reinventing the wheel over and over.
(What I like about my plugin is the “Page Type” idea that are a bit like Page templates but in another way but that’s another case)
~ posted by Fredrik Forsmo
Totally agree that this is a plugin and not a core feature - the whole point of this project is to avoid pushing things that are not needed. ACF is not needed, its a nice enhancement for those who want it.
Focus should go on improving the current meta data handlers and the custom fields api etc… stuff that is WordPress and not third party
~ posted by Simon Pollard
I’m against that.
I DO agree that there should be a core way for easier creation of metaboxes and fields, even a way to move these metaboxes/fields on the front-end in order to create complex user-flows that will interact with our data.
But please make it better than ACF. Even though ACF is good, its code could be cleaner and I really wish only a meta data was saved in the database, not its corresponding field setting.
~ posted by Pierre Saikali
uh, please don’t. By default the meta boxes are there, plus there are many other custom fields plugins, more performant and manageable.
~ posted by Pedro de Carvalho
Well this is a BUSINESS focused CMS so it MUST have Post type, post Fields, Taxonomy, taxonomy fields, user fields and capabilities UI Screens.
there are plenty of lightweight wp forks, but no other business oriented ones, so +1000
~ posted by Nodws
viktor
October 3, 2021, 7:40pm
3
This is basically a duplicate petition of the custom fields API petition. So I will go ahead and set it to close in a few days, in case someone disagrees.
james
October 3, 2021, 9:50pm
4
I’m not sure if it is a duplicate but we won’t be putting ACF into ClassicPress core. Leaving the topic to close in a few days.
1 Like
james
Closed
October 10, 2021, 9:51pm
7
This topic was automatically closed after 6 days. New replies are no longer allowed.