Should be easy enough for them to change tho, right? A bit of layout PHP and CSS that already exists.
Is there a downside to having presentation settings work on the Block editor too?
Alright I got it working! I can get behind your choices, and this hook even feels like a future proof method, compared to modifying the DOM with JS.
For future readers: I’m still curious if there’s a (solid) method of adding a std metabox around the editor, and/or making native std metabox fields seamless.
@howdy_mcgee I got that undefined index when I foolishly did do_action() instead of add_action(). Maybe you did the same.
Hey @hube2 . That sounds like a variation on C. I like it.
-edit-
I had the same request as OP. I do also hide the menu sometimes, but I want to hide this in a different situation.
I checked the source code and it looks like this button is added by a big chunk of JS. So there’s no hook to disable this particular feature.
In this thread @PandS and @Jonathan found the alternative solution of using CSS to hide the cog. So that’s what I’m using now.
<?php
/**
* Hide the ACF "Edit field group" cog in metaboxes.
*/
add_action( 'acf/input/admin_head', function () {
?>
<style>
.acf-postbox > .hndle .acf-hndle-cog { display: none !important; }
</style>
<?php
});
Giving this a shot in the dark: Do you have date_default_timezone_set() somewhere in an active plugin/theme? Since not so long ago this is a problem. Remove it and set the timezone in the backend settings only.
@dominikkucharski I’ve reuploaded it. I removed it because it was buggy, and I fixed those bugs in my ACF Agency Workflow repo. Though that also has an added sync function. If you search that source code for the hooks and other essential parts of the snippets people previously posted in this thread you’ll find my latest implementation of them.
Removing date_default_timezone_set() fixed it!
double clicking selects also the type column
Aw. Must differ per browser. I’m on Firefox.
Tank you!
No problem! It was a good idea. I’m going to use it too.
Try adding this:
'order' => 'DESC',
'orderby' => 'meta_value',
Or if you don’t plan on adding more meta_query params, this format may work too:
$replaceme = get_posts([
'posts_per_page' => -1,
'post_type' => 'custom_post_type',
'meta_key' => 'custom_field_name',
'meta_compare' => '>=', // optional
'meta_value' => 'custom_field_value',
]);
I also don’t know the exact syntax but just play with it until it works. 🙂
That’s field type Select, grouped under Choice.
This kind of error is very common but not specific to ACF. You’re trying to echo $term->name, and the error says it can’t find name. So take a step back and see what WordPress has actually put into your $term by dumping it. You can’t echo every type of var, but you can print_r() it. Do a print_r( $term ); and go from there. It may be empty, it may be a string, array, object. Lots of possibilities.
I’ve un-OO’ed my gist, merged it into my Auto Sync plugin, and found a way around the bugs I mentioned. Feel free to copy if you’re not looking to adopt auto syncing: https://github.com/Brugman/acf-agency-workflow
I’ve still got to polish the repo into a clean plugin, but I think it should work at this stage. Here’s my goal for this plugin: https://support.advancedcustomfields.com/forums/topic/workflow-hassle-for-multiple-developers-making-a-theme-and-plugins/
Fixed the multiple save points bugs! Discovered a new one, but not as bad. I think I’m going to try the plugin in a client project now and see what happens. I’ll probably still want to OO-ify it and write a readme and stuff, but it feels like I crossed the finish line! 🙂 New bugs are welcome on Github ofc.
Added hooked function to delete the JSON if you delete it in the FGE.
I’m going back to the multiple save points “bugs”, the final frontier!
I’ve posted my “multiple save points” code over on the other topic: https://support.advancedcustomfields.com/forums/topic/multiple-save-locations-for-json/
And here: https://gist.github.com/toscani/635a0ef618fd199d069550f124fe68e6
I’ve also been looking at sync plugins/code made my own for that, because I don’t trust old code from the internet, and I want to create a complete package specific to my workflow. If anyone else wants to hop aboard that’s fine by me.
I’ve already put the sync code in the package plugin: https://github.com/Brugman/acf-agency-workflow
That one’s got one bug atm: You can’t delete any FG because it will get synced back soon after. So I’m going to have to add a hook to delete the JSON when a FG gets deleted.
……………..
@infinimbal I’ve added a select box for paths to your code. Filled with load_json points.
https://gist.github.com/toscani/635a0ef618fd199d069550f124fe68e6
It works the same. Two bugs I’ve found so far, in both our versions:
1. If you edit a FG and change the JSON Save Path the FG does get saved there, but the one in the old path remains. We need to write or use a function that deletes the old.
2. The path selected/entered is also saved in the DB and the JSON under the json_save_path key. We’re hooking into acf/update_field_group which happens at line 551 in acf-field-group-functions.php. If you scroll up a bit there we have $save being built with $_field_group in it, and then being saved before our code runs. So even if we remove it before returning $field_group it won’t help. We can instead use the hook acf/validate_field_group, which runs much earlier, but I haven’t tested this yet, or another hook.
Test? My replies seem to go missing if I edit them twice.
@infinimbal I’ve added a select box for paths to your code. Filled with load_json points.
https://gist.github.com/toscani/635a0ef618fd199d069550f124fe68e6
It works the same. Two bugs I’ve found so far, in both our versions:
1. If you edit a FG and change the JSON Save Path the FG does get saved there, but the one in the old path remains. We need to write or use a function that deletes the old.
2. The path selected/entered is also saved in the DB and the JSON under the json_save_path key. We’re hooking into acf/update_field_group which happens at line 551 in acf-field-group-functions.php. If you scroll up a bit there we have $save being built with $_field_group in it, and then being saved before our code runs. So even if we remove it before returning $field_group it won’t help. We can instead use the hook acf/validate_field_group, which runs much earlier, but I haven’t tested this yet, or another hook.
@infinimbal I’ve added a select box for paths to your code. Filled with load_json points.
https://gist.github.com/toscani/635a0ef618fd199d069550f124fe68e6
It works the same. Two bugs I’ve found so far, in both our versions:
1. If you edit a FG and change the JSON Save Path the FG does get saved there, but the one in the old path remains. We need to write or use a function that deletes the old.
2. The path selected/entered is also saved in the DB and the JSON under the json_save_path key. We’re hooking into acf/update_field_group which happens at line 551 in acf-field-group-functions.php. If you scroll up a bit there we have $save being built with $_field_group in it, and then being saved before our code runs. So even if we remove it before returning $field_group it won’t help. We could instead use the hook acf/validate_field_group, which runs much earlier, but I haven’t tested this yet.
I’ve played around with that plugin and some snippets, yours included. 😉 Most are quite old, but @infinimbal ‘s is quite new, and the UI is nicely integrated into the FGE. I’ve played with his code a bit and made myself this:
It works, but its got a few bugs, will post the code later.
Regarding my rant yesterday. I’ve done some testing and drawn some nice to know conclusions. Probably amateur hour, but it was useful for me.
(FG: Field Group. FGE: Field Group Editor.)
- When you save a FG in the FGE, it gets a DB entry, and optionally a JSON. (obvious)
- Syncing is making a DB entry from a JSON FG. (obvious?)
- The FGE only loads from the DB. You cannot make it edit JSON files.
- Both private and public JSON FG are active right away, if in a load_json dir.
- Public JSON FG can be synced. Private can not.
- Private JSON FG do not sync automatically either.
Sooooooo.. DB entries cannot be abandoned if I want to use the FGE. To get the JSON in the DB we need to sync. To sync (manually) we need public JSON FGs, so private is of no benefit.
The solution I’m going for right now is to still distribute via JSON files over git. Then automate syncing so the DB gets the changes (Todo). Then use dir selection shown in the screenshot to always have a JSON file made for every new DB entry. And allow us to move the existing JSON FGs to any of the load_json dirs. Lastly, if the WP_ENV is not local I just remove the ‘Custom fields’ menu item. Easy! I hope.
I’ve played around with that plugin and some snippets, yours included. 😉 Most are quite old, but @infinimbal ‘s is quite new, and the UI is nicely integrated into the FGE. I’ve played with his code a bit and made myself this:
It works, but its got a few bugs, will post the code later.
Regarding my rant yesterday. I’ve done some testing and drawn some nice to know conclusions. Probably amateur hour, but it was useful for me.
(FG: Field Group. FGE: Field Group Editor.)
- When you save a FG in the FGE, it gets a DB entry, and optionally a JSON. (obvious)
- Syncing is making a DB entry from a JSON FG. (obvious?)
- The FGE only loads from the DB. You cannot make it edit JSON files.
- Both private and public JSON FG are active right away, if in a load_json dir.
- Public JSON FG can be synced. Private can not.
- Private JSON FG do not sync automatically either.
Sooooooo.. DB entries cannot be abandoned if I want to use the FGE. To get the JSON in the DB we need to sync. To sync (manually) we need public JSON FGs, so private is of no benefit.
The solution I’m going for right now is to still distribute via JSON files. Then automate syncing so the DB gets the new changes (Todo). Then use dir selection shown in the screenshot to always have a JSON file made for every new DB entry. And allow us to move the existing JSON FGs to any of the load_json dirs. Lastly, if the WP_ENV is not local I just remove the ‘Custom fields’ menu item. Easy! I hope.
A button/link to copy all could be nice. After you’ve just made 5+ fields you could paste a list of them into your PHP as a little cheat sheet. Especially when they’re sub-fields.
Regarding a copy one field button: How would you like to see that implemented? Double clicking the text in the name column seems to be almost as easy. (https://i.imgur.com/MCOt8HL.jpg)
The source code has a bunch of bbpress-* classes so it almost must be https://bbpress.org/.
