Support

Account

Register Login

Home › Forums › Search › Search Results for 'q'

Search Results for 'q'

reply

  • Thanks for your reply John. You’re right, my code was a bit light on content but I added everything I could think of that was relevant. As mentioned I was using the front-page.php template, and my code was not contained within any loops or queries.

    I did, however find the solution. I think it was a combination of misunderstanding on my part, and some ambiguity on the part of ACF + not having super clear documentation.

    There are two things that are used in ACF that sound kind of the same, field group and field (type) group . So I created a field group with the assumption I could just then grab that by referencing the field group name, and have all the data contained therein as a variable. My other field worked fine because I had a field group called ‘gallery’, and within that a field (type) group also called ‘gallery’. So when I called get_field(‘gallery’) it was working because it was grabbing the field type group and not the parent field group itself. I could not find any documentation on accessing the field group directly, so not sure if that’s even possible, so just used this as the solution instead.

  • I already tried with get_queried_object() but it returned an “array to string conversion” error.

    However, I found a better solution on the following link as I needed to display multiple values : https://www.advancedcustomfields.com/resources/taxonomy/

    Thanks for your help, though.

  • this is backwards and does not contain the correct ID

    
<?php echo get_field( get_queried_object_id(), 'sports' ); ?>

    You need

    
$get_field($field_name, $post_id);

    $post_id can actually be an object or a string. When using a string you need to use "term_{$term_id}", but this really isn’t necessary. You could do

    
<?php echo get_field('sports', get_queried_object()); ?>

  • There isn’t any such thing as a “run once ever” mechanism in WP.

    In addition to this, if you have many posts then looping over all of them to delete the field will more then likely time out.

    This is the way I deal with this.

    
add_action('init', 'MY_FUNCTION_NAME');
function MY_FUNCTION_NAME() {
  if (!is_user_logged_in() || get_current_user_id() != XX) {
    // replace XX with your user ID
    // only run this for me when I am logged in
    return;
  }
  // query all posts
  // use your field name in meta query
  // only get posts where the meta_key "EXISTS"
  // loop over results and delete_field() on each
}

    If you have a lot of posts then this will time out the page load. If this happens reload the page until it not longer does so. This will indicate that the field has been deleted from all posts.

  • Is your front page a static page or your blog page?

    Need more information about the code where you are attempting to get the fields. Any loops? Any queries? Just a single line of code is not enough, there are many things that can be affecting ACF’s ability to get the value.

  • This is not really an ACF question, it is a performance question. Any way you build blocks, as I understand it, will run into the same issue when you are including many small CSS and/or JS files.

    It is better for performance if small chunks of code are inline rather than in lots of external files.

    Either that or all of your CSS should be put into one file and loaded event when it is not used. This is not good for performance either, but it’s still better than loading many small files.

    I can’t give guidance on how to do this with blocks specifically.

  • The Elementor option will only detect fields that are saved as part of the post that you are editing. For options pages or when you are getting ACF fields from anywhere other than the current post requires the use of shortcodes and supplying the post ID (in this case “options”). ACF has a shortcode that works for simple fields. You have to build your own shortcodes for complex fields.

  • Per far above, I have already tried;

    update_sub_field(field_64c782fc4c55d, 84, 1074);

    and it does not work even if the value changes.

    I found update_sub_field(); in /plugins/advanced-custom-fields-pro/includes/api/api-templated. I added some debugging code to it, too.

    function update_sub_field( $selector, $value, $post_id = false ) {

	// vars
	$sub_field = false;

	// get sub field
	if ( is_array( $selector ) ) {

		$post_id   = acf_get_valid_post_id( $post_id );
		$sub_field = acf_maybe_get_sub_field( $selector, $post_id, false );
	
	} else {
		echo 'The $selector is '.$selector.', the $value is '.$value.' and the $post_id is '.$post_id;
		echo ' Also, this is not an array</br>';
		$post_id   = acf_get_loop( 'active', 'post_id' );
		echo 'post_id: '.$post_id.'</br>';
		$sub_field = get_row_sub_field( $selector );
		echo 'sub_field: '.$sub_field.'</br>';
		echo $post_id;
	}

	// bail early if no sub field
	if ( ! $sub_field ) {
		echo "not a sub_field</br>";
		return false;
	}

	// update
	echo "hello".$value.'//'.$post_id.'//'.$sub_field.'</br>';
	
	return acf_update_value( $value, $post_id, $sub_field );

}

    The output of the above is;

    The $selector is field_64c782fc4c55d, the $value is 84 and the $post_id is 1074 Also, this is not an array
post_is:
sub_field:
not a sub_field

    post_id is not returned, sub_field is not return and it bails early as it is not a sub_field.

  • Per far above, I have actually tried:

    
update_sub_field(field_64c782fc4c55d, 84, 1074);

    And it does not update even if the value is different from the current value.

    According to the man page, $selector can be a string, too,

    $selector (string|array) (Required) The sub field name or key, or an array of ancestors and row numbers.
    $value (mixed) (Required) The new value.
    $post_id (mixed) (Optional) The post ID where the value is saved. Defaults to the current post.

  • Yes, the field you are attempting to update is a sub field, which I’ve gone over already.

    You can’t use update_field() to update a sub field of a group field. At a minimum you should be using update_sub_field(). This function requires passing an array of the field hierarchy as the selector/field_name

    
update_sub_field(array('field_64b38c4e3ec56', 'field_64c782fc4c55d'), $value, $post_id);

  • under FIELD GROUPS I have:

    Name: FRESH SNOW SKI RESORTS”
    Key: group_647d9f906d00a

    In the above group I have FIELDS:

    Name: FS SKI RESORT DATA (and it is defined as a group
    Key: field_64b38c4e3ec56

    In above, I have many sub fields but the one that is not working is;

    Field Name: qgis_aa_zoom
    Key: field_64c782fc4c55d
    Numeric

  • Per the first post, I have echoed out the values being applied to the update_field() function and they are correct.

    I have tried this, too:

                if (update_field('field_64c782fc4c55d', 2, '1074')){
                
                echo "Success - ";
                echo 'field_64c782fc4c55d: '.get_field(field_64c782fc4c55d, 1074);
                echo '</br>';
            }

    As expected, it will not update is I keep 2 in there more than once. If I change 2 to another number, update_field is executed and the value of field_64c782fc4c55d is updated and get_field returns the updated value.

    I then go to the view of my custom post type and the value is never update. For instance, if I update the via the view of field field_64c782fc4c55d and I enter 7, the number never changes despite executing the above code.

    So then it means the view is not right. I inspected the html and it shows;

    <div class="acf-input-wrap"><input type="number" id="acf-field_64b38c4e3ec56-field_64c782fc4c55d" name="acf[field_64b38c4e3ec56][field_64c782fc4c55d]" value="7" step="any"/></div></div>
</div>

    The id is acf-field_64b38c4e3ec56-field_64c782fc4c55d which is myFieldGroupName-FieldKey

    Is that the way it should be working? There is not a description in the man pages and I would hate to start digging through the ACF code.

  • MySQL vs MariaDB should have no affect.

    The reason I recommended what I did was your second post

    Oh I forgot to add, when deactivating and deleting the plugin to try to reinstall, the plugin menu for ACF is still on the sidebar! Just the “Updates” options is removed for it, but I’m still able to go into the plugin. I checked the plugins folder too, it really has been removed.

    This tells me that ACF is still installed somewhere that you don’t see it. This happens when ACF is installed as part of the theme or included on another plugin. If updates are not available this would also indicate that the free version of ACF is what is included, wherever it is included.

    I do not think it is in the theme though because plugin are loaded first which should prevent the plugin in the theme from running.

    In any case, for this to happen the ACF files have to exist and be loaded, so they are there somewhere, you just need to locate them.

    The only other explanation could be that it’s installed as a mu-plugin, which I find highly unlikely, but not impossible.

  • @hube2

    I’ve already tried doing that with customer support in the beginning. They gave me a plugin to troubleshoot it with a safe mode which deactivates all plugins except for the ACF Pro. I did manually deactivate each one apart from the plugin as well, but no change. The same issue persists. I’ve also tried manually reinstalling the proper version from a new zip file from the ACF account (v. 6.2.1.1), but it only seems to show the version on the plugin list itself while also still prompting me to update to the latest version. Even though it says I’ve already updated it. However, if I go to ACF > Updates to check the version it still says 5.9.5 and the UI doesn’t update to the new interface. I can keep pressing update too, it just won’t. It says it has been, but again no change apart from the plugin list, but the prompt still loops.

    I’ve also tried deactivating, and uninstalling ACF Pro to just try to reinstall it, but for some reason even if I check cPanel and the plugins folder to make sure that the plugin doesn’t exist, I can still see it on the WP dashboard sidebar. I can still access it and everything, but the Updates option is now not available unless I reinstall and reactivate it. Which still doesn’t change the version no matter which version I upload. I was using 6.1.7 originally. I’ve tried re-entering the license key too. No dice.

    I am using Divi if that matters. It’s just confusing because if it was a plugin that was causing this issue, wouldn’t the same issue be replicated on my staging sites? I’ve already tried migrating the same file to a brand new WP installation on a new staging site and I can’t replicate the issue. It only happens on the live site which uses a different host provider and MariaDB. My host provider uses MySQL. They should be compatible for the most part, but I haven’t been able to find anything that works.

    My inclination is to believe that it has something to do with the database, but as I’m more a front-end developer than a back-end one, messing too deeply with those files without knowing full-well what I’m doing seems too risky. Any other ideas on what I could try to figure out why this might be happening?

    The only thing I can think of to try is removing everything from the public_html folder getting a brand new install of WP again and trying the migration one more time.

  • $queried_object = get_queried_object(); 
$taxonomy = $queried_object->taxonomy;
$term_id = $queried_object->term_id;  
 
// load desc for this taxonomy term (term object)
$thumbnail = get_field('category_description', $queried_object);
 
// load desc for this taxonomy term (term string)
$thumbnail = get_field('category_description', $taxonomy . '_' . $term_id);

echo '<p class="dop_widget_p">' . get_field( 'category_description', $queried_object ) . '</p>';

    Wrap the text in a tag and add style

  • This is getting weirder and weirder and beginning to think there is a bug somewhere.

    Here are two field I have:

    Key: field_64c782fc4c55d
    Name: qgis_aa_zoom
    Group: fs_ski_resort_data

    Key: field_64a54023795f5
    Name: fs_aa_zoom
    Group: fs_ski_resort_data

    I have tried the most basic code as follows to update;

    update_field('field_64c782fc4c55d', 12, 1074);

    If I go to my custom posts and look at the field, it is empty, however, if I do this;

    echo 'field_64c782fc4c55d: '.get_field(field_64c782fc4c55d, 1074);

    I get 12, as updated above. Bizzare.

    I have an API that calls the field by name, rather than key as follows;

    `$fs_ski_resorts_data[$i][‘fs_ski_resort_aa_zoom’] =
    get_field(‘fs_ski_resort_data_fs_aa_zoom’) ?:
    get_field(‘fs_ski_resort_data_qgis_aa_zoom’); `

    Above produces: "fs_ski_resort_aa_zoom": "", // empty string

    If I manually insert data via the view of my custom post type, say, 7, I get this;

    "fs_ski_resort_aa_zoom": "7",

    So there seems to be something going on in the database and things are not matching correctly.

    Any help appreciated.

  • Commenting here just in case there are others who may need this solution. The function that is most helpful here is wp_style_engine_get_styles. When used in your block rendering script, you can call this function to produce the inline styles needed to render your block correctly.

    I made a little utility function for doing so and generally include it in all of the ACF blocks we’re building. Hope it helps. =) 

    
/**
 * Given an $block object from an ACF block for gutenberg:
 * This will return a string of CSS inline values suitable for
 * inclusion in the block output in PHP.
 *
 * @param  mixed $block
 * @return $style as string
 */
function acf_blocks_calculate_inline_styles( $block ) {

	if ( ! empty( $block['style'] ) ) {
		$style_engine = wp_style_engine_get_styles( $block['style'] );
		$style        = $style_engine['css'];
	} else {
		$style = '';
	}

	return $style;
	// echo '<div style="' . $style . '">Block content</div>';
}

  • I had the same problem of my block JS file not loading when adding it this way. If you have wp_debug enabled you’ll probably see this notice which will show the name of the .asset.php file it’s expecting:

    “Function register_block_script_handle was called incorrectly…”.

    However, using this ACF forum post to start, I found how to load scripts via file name in blocks.json. I understand this is the better way to do it (now that it’s possible) instead of what Bill Erickson’s tutorial shows (enqueing the script manually via PHP).

    So since you are loading a JS file named custom.js you’d need to add in the same folder a file named custom.asset.php. In this file you can include the handle name, dependencies, and version number. Or you can leave them to be default generated. My js-file-name.asset.php looks like this:

    
<?php
  return array(
    'dependencies' => array(
        'wp-blocks',
        'wp-element',
        'wp-i18n',
    ),
    'version'      => '1.0',
  );

    To read more about this, check out the WPDefinedAsset section in the WP Block Editor Handbook.

  • There isn’t a way to do the search that you are looking for, at least not easily.

    Normally when searching by post title and a meta query this is “AND” meaning that both the title AND the meta value must contain what you are searching for.

    There isn’t an easy way to do a search where the “post_title” OR the “meta_key” matches. Honestly, I haven’t a clue how to do this.

    What I would do is I would be to copy the post title to a meta value using an acf/save_post action. Then you can that meta key for searching. As far as breaking down the search string into words, I don’t know how to do that.

  • Do you have an ACF field named “post_title”, if not and this is referring to the WP post_title then this is not a meta value and it cannot be searched with a meta query.

    When WP does a search is breaks the search string down into individual words and adds multiple “LIKE” clauses, 1 for each word.

    
search string = "this is a search"
LIKE "%this%"
LIKE "%is%"
LIKE "%a%"
LIKE "%search%"

    Like queries require enclosing in % characters.

  • EDIT:
    Code I posted is bad, this is my code:

    function custom_acf_post_object_query( $args, $field, $post_id ) {
    // Get the search text
    $the_search = $args['s'];

    // Remove it so ACF won't search the posts based on title
    unset($args['s']);

    // Search based on custom fields only
    $meta_query_args = array(
        'relation' => 'AND', 
        array(
            'relation' => 'OR', 
            array(
                'key'     => 'post_title', 
                'value'   => $the_search,
                'compare' => 'LIKE'
            ),
            array(
                'key'     => 'content_shop_api_key',
                'value'   => $the_search,
                'compare' => 'LIKE'
            )
            
        ),
       array(
                'key'     => 'free_content_check',
                'compare' => 'LIKE',
                'value'   => $the_search,
            )
    );

    $args['meta_query'] = $meta_query_args;

    return $args;
}

add_filter('acf/fields/post_object/query/name=assign_user_product', 'custom_acf_post_object_query', 10, 3);

  • btw, all the fields are part of a group. Does that make a difference? I know using field names the field group must be pre-concantonated with the field name. I assume using the key, this is not required as the key is guaranteed to be unique.

  • Can I have this question deleted? The problem was I wasn’t sending the ID I thought I was. My mistake.

  • Actually, yes, when using update_field() is is best to assume that the field has no value and always use the field key.

    The documentation should actually say that in my opinion, but not much I can do about that.

    Any value in the database, even an empty string. What matters is that ACF creates two entries in the database, one has a meta_key of your field name and the other has a meta_key of your field name prepended with an underscore _{$field_name}. If both of these exist then you can use the field name. ACF actually uses the field key for everything because they are unique. Field names are only provided for our convenience. If you look at an admin page with fields and inspect you will find that all of the inputs use the field key for the field name.

    The only time this is not the case is when using an acf/save_post with a priority of > 10 and you can be sure that ACF has already created a DB entry for the field and you intend to change it for some reason.

  • You can use a post object field and you can adjust the query parameters used to find the posts, including the author, using an acf/fields/post_object/query filter

Viewing 25 results - 3,151 through 3,175 (of 21,345 total)
1 2 3 … 126 127 128 … 852 853 854