wp-config.php already contains your database credentials, so I hope people aren’t checking that into public repos, but I guess you never know. ¯\_(ツ)_/¯
In my other (non-WP) applications, I use a .env file for sensitive info that doesn’t get checked into version control. I wish WP supported it natively, but here’s a quick tutorial on how to use it: https://m.dotdev.co/secure-your-wordpress-config-with-dotenv-d939fcb06e24
Easy enough if you control the server and can use Composer, otherwise probably not an option.
@anchordev Cool, I’ve never used ManageWP, that feature is new to me.
By the way, if this is being triggered by a WP Migrate DB Pro migration (as is the case for me), the following should prevent the key from being overwritten during a migration: https://gist.github.com/daltonrooney/470619cca87a6c29cb84f92d856b9ec1
@anchordev Is that hooked into a filter somewhere so it isn’t run every time a page loads?
I’m going back to several old threads to report the fix for this problem. As of ACF Pro 5.5.8, flexible fields clean up after themselves when they’re deleted and no longer leave orphan data in the postmeta table.
I’m going back to several old threads to report the fix for this problem. As of ACF Pro 5.5.8, flexible fields clean up after themselves when they’re deleted and no longer leave orphan data in the postmeta table.
As of ACF Pro 5.5.8, the flexible fields clean up after themselves when they are deleted, so no more ghost data in the postmeta table!
I was having this problem as well and reported it to the ACF support team. It looks like it has been fixed in ACF Pro 5.5.8.
That gist actually doesn’t solve the problem for me. For example, ACF is already licensed on my staging site, but when I do a database pull from the production site, the URL no longer matches and the license is invalidated.
A simple DEFINE in wp-config would be a better option in my case, I think!
Adding my +1 here, this comes back every time I migrate a database from dev to staging to production or back again. It seems I’m re-entering my license information 5 – 10 times a day.
Is there another field also being saved on the same post with the same name?
I just had a similar problem – I have a group of flexible fields called “image_blocks” that I was cloning into a field called “image_blocks” in another group. I didn’t realize that every time I saved the post, my flexible fields were being overwritten by the parent Clone field.
I would recommend naming the Clone field something like url_clone to avoid collisions, if that’s your problem. It would be great if the plugin could automatically detect confusion like that.
That was the trick! Thanks so much, I had no idea this filter existed and it was exactly what I needed. Cheers.
Hi Daniel,
If I’m understanding you correctly, someone has implemented a plugin that does what you’re asking for. It’s called ACF Reusable Field Group: https://github.com/mvpdesign/acf-reusable-field-group
Let’s say you have 2 field groups you want to choose from: FG1 and FG2
Create a 3rd field group (let’s call it Repeater Group) that’s a repeater with a Reusable Field Group field in it. Add the Repeater Group to your pages.
Then, when filling out the page, you would add a row to the Repeater Group Field, select FG1 and fill it out. Add a new row, select FG2, and fill it out. Just watch out for ACF Inception, I think it might be possible to select the Repeater Group itself and create a field within a field within a field. 🙂
Make sure you report this directly to the ACF team via email, this is a community forum and not monitored closely as far as I know. I usually get an email response pretty quickly on support issues.
There’s a bug in the current version of ACF that hides the fields on some pages. You need to revert to 5.1.8 or use the “Screen Options” tab to show the fields.
I generally prefer using custom code rather than plugins when trying to accomplish these sorts of things, but I wonder if you’ve heard of Admin Columns Pro? It is insanely cool for doing these sorts of things and has direct ACF integration. I can’t even tell you how much time it has saved me. I have no affiliation with them at all, just passing on some useful info!
Every field has a “class” attribute which can be used to control the styling. (This is in the Pro version of the plugin, I don’t know if this feature has been added to the free version yet.) I have standard classes like “left_half”, “right_half”, and “clear” that I can then style in the admin or on the front end to control the layout.
Here’s a screenshot of the class attribute field, hope that helps.
I did this recently by splitting them up into multiple field groups. The first group is a taxonomy radio field. Then I have several other field groups which are conditional based on the taxonomy of the pgae. Here’s a quick video of what I mean. http://cl.ly/1s302Z3k2p1i
I’ve contacted ACF support about this issue and they’ve confirmed it’s a known bug and a fix is on the way.
I got in touch with ACF support, they’re aware of the problem and should be releasing an update soon.
This is definitely a bug! I’ve reported it to the ACF team, I’m still waiting to hear back.
You can call a field with a specific page ID like this:
<?php the_field('my_option',22);?>
Where 22 is the ID of your homepage.
@tuskotrush I think this is a bug, not a normal feature. Usually the fields show up right away and there’s no reason to perform this action.
I’ll open a ticket with ACF as soon as I can reproduce on a fresh install.
Did you look on the “Screen Options” tab on the edit page? I’ve noticed lately that some of my fields are hidden by default and need to be added there as well.
Interesting, I am having the same problem. All of my fields disappeared on the edit page! I had to look in “Screen Options” to find them and add them to the page again. Fortunately when I add them back, the setting is saved. I wonder if this is an ACF thing or if something else might be causing this.
Edit_Page_�....png
Edit_Field_G....png
Edit_Page_�....png
