php version?
also, can you let me see the site to i can check for any javascript errors?
v3 or v4?
btw, do you have any posts in wp_posts with the post_type = “acf”? if so, do you have any postmeta in wp_postmeta where the post_id = those “acf” posts?
that is how i’m used to seeing the data stored, anyway. i’m not sure how v3 differs.
change the opening if statement in your function (assuming your checkbox field has a key of field_asd856f4a8sdf
if( ( $_POST['post_status'] == 'publish' ) &&
( $_POST['original_post_status'] != 'publish' )
( !empty( $_POST['fields']['field_asd856f4a8sdf'] )
) {
check the source code after your page loads to determine the acf key. it will look like that one i’ve put there, even though i made that one up.
btw, what version of php are you running? not too long ago, objects weren’t passed by reference…so we could be up against that if you are back on php4.
two things to try:
- firstly, for fun, comment out the
$args = array('ppp'=>200); and see if you can just go through the filter with no changes. if not, find the errors, they are either in your javascript console or hiding in your error log (in local do you have wp_debug set to true?)
- next, and this may be what you try first if you are querying a particular field, try to be more specific by filtering only the field that you need to filter like this:
acf/fields/relationship/result/name={$field_name}
if you have multiple fields to query against, i wonder if you can dogpile them:
add_filter('acf/fields/relationship/name=title', 'tdr_carousel_query', 10, 3);
add_filter('acf/fields/relationship/name=keywords', 'tdr_carousel_query', 10, 3);
add_filter('acf/fields/relationship/name=description', 'tdr_carousel_query', 10, 3);
are you running any minification or other client side scripting performance enhancements? if you are, try disabling them to see if the client side error goes away.
are you seeing the error in the admin or on a page that the user might view? typically, i don’t use acf form fields to take input from clients. typically i will use my own form fields and then save them using the fields i’ve created using acf.
for instance, on an auction site that i have, acf is used to show the custom fields on my custom post type. one of the fields on my custom post type called “custom-post-auction-bid” is a field called “auction_cur_bid”. acf displays that current bid value when my admin access the “bid” post.
however, the data is actually written in this way, during form processing:
update_post_meta($post_id, 'auction_cur_bid', $bid);
perhaps rethinking the method of integration will allow you to avoid the conflict altogether, especially since the conflict appears to be related to client side scripting anyway.
are you doing this in a template or in a function outside of a template?
could you post your query?
also, the result which is indicate by your search being termed broken will help; for instance, do you receive any on screen errors?
is this a development environment or a live environment, do you have wp_debug turned on?
my last post got me wondering why there wasn’t an auto_incrementing field. that seemed highly unusual; in fact, according to this…wp_postmeta should not have any 0’s in the meta_id field since it is supposed to be an auto-incrementing field. i lost my indexes somewhere.
https://codex.wordpress.org/Database_Description#Table:_wp_postmeta
and, adding the indexes back fixes it! here are the queries i used if it helps anyone that somehow lost their indexes as well.
alter table wp_postmeta change column meta_id id integer unsigned, add column meta_id integer unsigned primary key auto_increment first;
update wp_postmeta set meta_id = meta_id + 9000; -- more than the number of rows in the table
update wp_postmeta set meta_id = id where id <> 0;
alter table wp_postmeta drop column id;
alter table wp_postmeta add index (meta_key), add index (post_id);
i have backed up all the tables from LIVE. in restoring them one-by-one to TEST, i found that the problem must exist in the table:
wp_postmeta
if i restore the TEST wp_postmeta, i cannot recreate the issue. if i restore the LIVE wp_postmeta, i CAN recreate the issue.
i did find (probably due to the ACF_LITE) that many postmeta records exist with meta_id of 0. i tried deleting all of these, but that is not the solution. that just causes data loss.
after restoring my backup, i’m again facing the problem neatly in a corner and completely out of my reach.
what in wp_postmeta could cause this duplication of meta_keys?
in narrowing it down, i can recreate using just this as my acf.php:
<?php
if(function_exists("register_field_group"))
{
register_field_group(array (
'id' => 'acf_experience-post-fields',
'title' => 'Experience Post Fields',
'fields' => array (
array (
'key' => 'field_52bc856a5d6b9',
'label' => 'Is Auction',
'name' => 'is_auction',
'type' => 'true_false',
'instructions' => '',
'message' => '',
'default_value' => 0,
)),
'location' => array (
array (
array (
'param' => 'post_type',
'operator' => '==',
'value' => 'experience',
'order_no' => 0,
'group_no' => 0,
),
),
),
'options' => array (
'position' => 'normal',
'layout' => 'no_box',
'hide_on_screen' => array (
),
),
'menu_order' => 0,
));
}
i’ve tried disabling the other plugins. the only fields that are duplicating meta_keys are those that are in the auction_ group. the other booleans and other field groups are working as expected.
i’m running out of things to try.
i’ve just experimented by placing TEST into ACF_LITE mode and have it include the acf.php. the issue cannot be duplicated that way.
then i tried pointing the database to LIVE and i WAS able to recreate the duplicate meta_key.
so it’s got something to do with the database. but where do i start?
interesting…i just updated the TEST env to 4.3.4, LIVE, where the problem is, still has 4.3.2. maybe i’ll just ignore it until the updates roll out. thanks for the comment, realph.
———————————
anyway, some users may find it interesting that i found that even in ACF LITE mode that one can raise the dashboard, the field groups list, by accessing
//WordPress/wp-admin/edit.php?post_type=acf
that isn’t my entire problem, i guess, since there are no fields listed in the field group.
here is a dump of the meta_keys and values for the post that i can replicate the duplicate key issue on:
meta_key meta_value
auction_min_bid 5000
auction_start_datetime 1389052800
is_auction 0
_auction_close_datetime field_52bca098b5d6a
_auction_estimated_value field_52ccb21266722
_auction_min_bid field_52bca121b5d6b
_auction_start_datetime field_52bca011b5d69
_is_auction field_52bc856a5d6b9
it seemed to have been only the auction fields that duplicated…also i’m reattaching the acf.php as a zip.
Aha, that makes perfect sense. I wondered how best to clear out the fields i had manually set. Can you point me to an example query that I can use to do that, please? Or are you sugggesting that I just delete them out from the ACF panel (I have it set to ACF LITE, so there isn’t one, but i could undo that).
ah, an attachment button! here is the entire acf.php.
acf.php_.zip.zip
.