Hi @ncl
So to be clear, this is field groups you’ve created in wp admin or with php?
The ones you export that is.
Hi @timothy_h
Are you using the enhanced UI for the post object field? By that I mean is it loading in posts as you scroll or showing you all at once?
No problem!
Glad I could help you on your way. Just post here if you need more help or feedback!
Hi @charis
I’m not quite following you. You have a CPT in which you’ve created a single image field? And when saving that you want it to become the featured image?
If so, why not just use the featured image meta box provided by WordPress.
It seems your DB has gone bonkers..
Just to be clear, the image you posted in your second post, is that values saved to a term or post?
If it’s for a term there’s some issues as it should look something like tax_termid_fieldname.
I assume you don’t have any fields with the same field names? That’d mess things up for sure.
What’s interesting about your image is that both the _* value and the regular one contains a string. The _* should have a value of the field key as shown in my image.
Hi @hazard
You beat me to it 😉 After reading your topic again I realised this was the reason you wanted the field name as a class.
I don’t see why it couldn’t be added and it is probably a pretty simple thing to do. I know you mean the name and not the label but believe me.. people go changing those too afterwards and give me grey hairs in the process.
I’ll make an improvement ticket for this and maybe it’ll turn up in a future update 🙂
Hi @mastafu
I think you could just do a check for the title value in your save_post hook and ignore the changes if it’s empty.
add_action( 'acf/save_post', 'my_update_existing_post_data', 10 );
function my_update_existing_post_data( $post_id ) {
if(!isset($_POST['acf']['field_5464a2a2d9a50']) || $_POST['acf']['field_5464a2a2d9a50'] == '')
return;
// Update existing post
$post = array(
'ID' => $post_id,
'post_status' => 'publish',
'post_title' => wp_strip_all_tags($_POST['acf']['field_5464a2a2d9a50']), // Post Title ACF field key
);
// Update the post
$post_id = wp_update_post( $post );
}
Let me know how that works!
Hi @ashkas
First off nice use of gazumped 🙂
It’s a strange issue you have. I have some questions for you:
1. Does this only happen on terms? Not posts/pages?
2. Do you have any other field or maybe post/page with the same “slug” (plate)?
3. Did you create these fields directly from within wp-admin? (Not php or json).
4. If you actually check your database wp_options table for this value, does it say “something”?
Hi @acha5066
Unfortunately no. Not in the sense that you could grab an entire flexible field layout and make it into it’s own.
However with ACF5 you can drag the single fields out from the flexible field as regular single fields. Just click and drag a field from within your flexible field layout outside the entire flexible field. However keep in mind that this will also change the way values are saved so any previous information you’ve put in these fields will no longer be usable.
Hi @netfreak
I understand why you have issues! loading a hundred maps on a single page is going to be slow and really not something one want to encounter..
I think that rather than this being an issue with ACF it’s an issue of architecture. Do you really need all of these at an options page? It would seem a better solution is to create a custom post type and place a single map for each post. Then you will only load one map for each post in admin. There’s also the advantages of being able to utilize wp_query for either simple queries or to fetch only specific maps easily. You’ll also get a much more approachable admin interface with search capabilities, ability to sort by date etc. etc.
My suggestion is thus to not try to patch up a leaky ship but change it completely instead.
Hi @hazard,
Maybe I’m misunderstanding you but there are field specific classes you can use which are the same whenever. They’re not as human-readable tho as they use the field keys like: acf-field-552bcd23a2381. I think the reason for this is so that even if a user at some point changes the field name in the GUI the CSS will remain as the field key is never changed for a field (Also the reason why it’s recommended to use the field keys for filtering etc.).
Hi @moettinger
That’s a tough one.Sub field values are saved to wp_postmeta etc. in this way: repeater_field_name_0_sub_field_name with 0 ticking upwards with each row.
With an repeater inside another repeater I think it’ll be:
repeater_field_name_0_sub_repeater_field_name_0_sub_field_name
Since you now initially want to put your repeater in another repeater I’m assuming the whole current repeater should go as the first row (I.E. 0).
You’d probably have to do some clever SQL queries to change the values of each repeater_field_name_0_sub_field_name into repeater_field_name_0_sub_repeater_field_name_0_sub_field_name
but you’ll also first have to make sure atleast 1 row has been previously created in the root repeater. If you check the DB you’ll see that the repeater fields only contain a count (starting at 1) of how many rows they contain so just running an SQL for the above will not cause the values to show up.
Hope I got you started! It’s not an easy topic to tackle 🙂
Hi Hazard,
Thanks for noticing! I think the reason for the message field type using a label like all the other field types is because there’s some styling to the label element.
I’ll be sure to make an improvement request for this for future updates!
Okay I see..
I think this would be a feature pretty much noone uses tho. And you can easily achieve a reverse order yourself with just:
$repeater = get_field('fieldname');
if( $repeater ){
$reversed = array_reverse($repeater);
foreach( $reversed as $imagerow ){
}
}
Hi @davelee
I think the reason this happens is because when you change the user role on the profile page, before saving, the users role hasn’t actually changed.
I understand your issue and I can see how it’d be troublesome in combination with required fields. I think it’s just about it being a scenario not previously anticipated and thus not taken into account for in the code.
I’ll talk to Elliot about this and we’ll see how to best approach it.
No problem!
Please mark the reply as an answer to your question to make it easier for future answer-searching folks 🙂
Hi @andrea_stand
This is absolutely possible to do and it’s really just a basic relationship querying and reverse querying.
These two different queries should get you going! If you need further extensive help you can contact me directly at [email protected] for help through our web agency.
//This should be in the loop
//Fetch an author post based on the current post authors (users) ID
$author_ID = get_the_author_meta('ID');
$args = array(
'post_type' => 'authors',
'meta_query' => array(
array(
'key' => 'userfieldname',
'value' => $author_ID,
'compare' => 'LIKE'
)
)
);
$author_query = new WP_Query($args);
//fetch all posts for the user. I'm not 100% sure the user field type returns an user object but I think so.
//It's also possible that $author is an array with user objects inside. if so change $author->ID to $author[0]->ID.
$author = get_field('userfieldname');
$args = array(
'post_type' => 'authors',
'author' => $author->ID
);
$usersposts_query = new WP_Query($args);
Hi @davenportgm
You can safely delete all instances of ACF from the plugins page (it wont delete any of your field data or meta values). But take a backup first just for good measure.
Then reinstall the latest version of ACF and you should be good to go.
To me it would seem that someone has made manual changes to the ACF core files and changed the version number to avoid getting new updates. A very bad practice which I admit I’ve been guilty of myself earlier in my WP usage.
Hi @cliffordp
Thank you for the feedback! ACF is almost entirely maintained by Elliot Condon alone and as such he has quite a lot to do!
I can imagine that the date picker could be extended to also include time and timezones but I don’t think it can be given a high priority. There’s also the possibility to create your own field type for this like in the link you sent.
I will create a feature request for this but I can’t say when or if it’ll be implemented. Perhaps I give it a go myself at some point as I do think it’s a good extension if done right!
Hi,
It seems the dependencies (js) isn’t loading properly.
Can you check your sourcecode to make sure acf_form_head() is loading in properly?
Also, do you have any fields using ajax in the form?
Hi @vegasmaster
How do you import/export the fields? With the provided tools?
If you’re using ACF Pro (5.x) you can make use of the ACF JSON feature to duplicate the fields for each of your separate installations. That way you can also easily just create new fields on one of the sites designated as the “main site” and copy the acf-json folder to each other installation by FTP, quick and easy 🙂
http://www.advancedcustomfields.com/resources/local-json/
Hi @frescova
May I suggest using the true/false field instead for this. That way you literally only have to do
if( get_field('display_wtr') ){ //It's been checked }
Hi @moabi
You say that the fields and values still exist in admin while not appearing in your theme. Could you do a check right after you encounter this to see wether the values actually exist in the wp_postmeta table for the posts affected.
Hi @jutu83
It would seem that you’ve come across a good olé fashion bug.
I will make a bug report out of this.
To be clear, what’s happening is that a loaded edit screen (or reloaded after an update or save) does not respect the conditional logic when the triggering field is in a different tab within the same field group?
Hi @panic175
Have you looked at the values of a page_link element created from the GUI to make sure you’re not missing any parameters or values in your own?
