I like to keep my ACF fields under version control using the code exports so I’d like a feature where if you have:
define('ACF_DISABLE_DATABASE_DEFINITIONS', TRUE);
or
define('ACF_DISABLE_CODE_DEFINITIONS', TRUE);
in wp-config.php, ACF will only read fields generated through the PHP code export from your functions.php or only read fields from the WP database.
This would help in the case where I am creating fields locally (using the DB on localhost) and exporting them to PHP code for my production servers.
Hi @davidosomething
I like the idea, but can you post the issue that you currently experience?
Thanks
E
The current issue is that in the Custom Fields admin page, I am seeing both the database created fields and the PHP exported fields. So I would have something like:
Homepage
Homepage
instead of just one Homepage entry.
Hi Elliot,
I’d like to second this request. It would allow me to continue working on the auto-export plugin I mentioned here:
http://old.support.advancedcustomfields.com/discussion/5495/exported-php-settings-override-database-based-settings
I’d say that rather than use a global override that it would work better as a checkbox inside of an ACF field group which would allow that one field group to choose to either use the database or the php version.
Regardless, this would be an excellent feature for large-scale sites with multiple environments.
thanks,
Scott
Yay for this!
So how does everyone work around this issue? Any workflow suggestions? This is a serious problem for our deployment setup.
Yeah, this is a bit of a pain point for us as well.
We have local / test / production environments, version control with multiple developers, and managing ACF custom fields is a bit of a pain.
– Using the PHP export is ok, but means that other developers can’t easily add fields without changing the export file directly. We can get round this by using the XML export, but then we have to take steps to not include the PHP field definition file.
– If the local development instance where we used the UI to create the custom fields is lost, then we lose the ability to change the fields in the UI without working through the PHP export file and recreating the fields in the UI.
– We get weird issues when we have UI defined fields and the same PHP defined fields: sometimes fields get doubled up, sometimes they don’t.
It would be fantastic to fix some of these issues, we’d certainly pay for an add-on that sorted out these issues and made ACF even more developer friendly.
Any way to move the functionality for this in the to-do list from “Future” and into the next iteration?
The threads in the “Future” list:
Add constant for auto export – …http://support.advancedcustomfields.com/discussion/5453/add-support-for-auto-exporting-fields
Load and save to PHP – …http://support.advancedcustomfields.com/discussion/5495/exported-php-settings-override-database-based-settings
(and of course this thread)
I would personally prefer it to be a per-fields-set option rather than a global option. But will take what I can get!
If it helps – you could even make this another paid-for add-on as it’s certainly often going to be corporate/large-scale level users who need a feature like this. What’s another $25 to the cost of doing business?
thanks,
Scott
I agree, we would gladly pay for this functionality.
Hi Elliot,
Love your work. I’ve been using your plugin since v1 and in the meanwhile I’ve been refreshing your Todo list for several months now to see this request go up and down on the priority list :). As like the people here I would burst if you sorted this out. Are you still planning to incorporate this feature in your plugin? I’d also love to pay some money for it in the form of a premium add-on for example.
Let us know.
Best, Koen
Hi @dotred
Thanks for the comment, I can gladly tell you that functionality for disabling DB calls, and ‘auto’ export / save data to file will be part of ACF v5!
Thanks
E
You are the man! I’ll be waiting 😉
