I am also experiencing this issue. If there isn’t an easy solution, I would rather have to use something like get_field('size', $block_id) to get block data than have to use get_field('post_field', get_the_ID()) for a post field.
Or, if possible for ACF to hook into the setup_postdata() to switch contexts back and forth. I don’t know how feasible that would be.
@alexeysv How did you solve this? Running into same issue here.
Edit: Nevermind, I replied to soon. I had registered via PHP and set mime_types as an array instead of a comma separated string.
@badlydrawnben I think it would be possible to hook into the ACF field save and load events to convert the hex to slug on save to database, and then convert slug back to hex when showing admin field.
@enaldi that only works if you’re editing a post. Won’t work for options/users/terms.
Also having the second issue, FC fields not displaying at all. Again only on some of our sites, even though the code base’s are basically the same.
Just for future reference, this has been added in v5.3.6.
At bottom of page here:
https://www.advancedcustomfields.com/resources/adding-custom-javascript-fields/
acf.add_filter('color_picker_args', function( args, $field ){
// do something to args
args.palettes = ['#5ee8bf', '#2f353e', '#f55e4f']
// return
return args;
});
@djahr Yes I am using English. The update did not help. Thank you.
@hube2 No there is nothing in our termmeta table. I don’t think the data was deleted, as I said the frontend of our site still showed up normal. But ACF was not showing the data in the backend, so saving the options page would then delete all values.
I did not find any topics about options being deleted in 5.5.
Hi @jonathan
Thanks for the response, but that’s not what I’m talking about. I’m talking about creating something like Shortcake but with ACF as the backend for the fields. Instead of saving values to a database, it would be generating a shortcode that then gets inserted into the editor (as a TinyMCE view).
Hello, I have created a plugin just for this purpose.
http://wordpress.org/plugins/acf-link/
Thank you, I understand the reasons behind it. But I’m wondering if maybe location options should be handled differently, maybe only using the JSON as a default unless a database value is present or something.
I guess right now I would have to create an options page, with a Post Object field that would allow a user to select a post/page, and then create a custom location filter that checks against that option value. That way the selected page could be different on development vs production.
Hi @acf-support
Here is a paste of the JSON field group: http://pastebin.com/WVBPJMGs
And I have attached a screenshot with the section of code that tries to set the column and row classes, and then one with the final result once ACF JavaScript does run (there is a flash of the form looking *almost* correct, and then it turns into the single column).
Thank you!
@acf-support
To answer your question about it being impossible to use $_GET to get the IDs, it is not hard to do for some things like posts and terms, but for widgets it is hard, because there is no $_GET variable available (when JavaScript is enabled). You would basically have to add a filter to every widget that sets a global variable or something similar. But since ACF is already doing all the work, why not share it?
@acf-support
Who says that they don’t need it to do their job?
Here’s a very basic use case: a Markdown field. After saving the field, the converted value is saved to the database in a separate field (using acf_update_metadata($post_id, $name, $value, $hidden)). That’s done so we’re not saving the original value as an array, allowing easy querying via WP_Query or the like.
When rendering the input field next time, we show a preview of the converted markdown field, but we need the $post_id to get the correct field from the database (acf_get_metadata($post_id, $name, $hidden)).
I will open a support ticket, thank you.
@acf-support
Sorry, this isn’t solved anymore.
I noticed that $post_id is passed to acf_render_fields method, but then it doesn’t get passed to acf_render_field_wrap or acf_render_field. It really should be passed along, so that metadata can be loaded when displaying the input field.
@acf-support Thanks James, I think the semi-recent addition of the “Description” field took care of this. Thanks though!
@hube2 all of the icons used throughout ACF.
It looks like it has been fixed, but the CSS class names have changed from acf-icon-pencil to just -pencil, so a plugin that used the old css classes was not displaying correctly. This can be closed now.
Well right now if you change a field name, you already have to resave everything in the database. So changing the key would be just the same. And, if you just required the field name to be globally unique then you wouldn’t need both a key and a name. That seems to make more sense to me anyways, as it can get confusing have two fields with the same name, but for different posts/post types, etc.
Hello @acf-support
I’m using Advanced Custom Fields Pro 5.2.5
I’ve always noticed this behavior though.
For example, if you have a repeater field name ‘list’.
$list = get_field('list');
should return an array of sub fields. but if a post hasn’t been saved since that custom field has been added (or it has been saved but doesn’t have any rows in the repeater), it will not have any database field for that ‘list’ value, and ACF thus returns a null or 0 value. But it should return an empty array, as that is what you would get if the post had been saved with rows of values.
You should be able to foreach (get_field('list') as $item), but right now that can result in PHP warnings because get_field('list') isn’t always an array.
Thanks.
@sukcesstrony yes, but then the metabox title displays that, which isn’t nice or necessary for users to see.
See my thread here: http://support.advancedcustomfields.com/forums/topic/separate-metabox-title-field/
before.png.png
after.png.png
