Support

Account

Register Login

Forum Replies Created

  • Hi John,

    Okay, thanks for further explaining. Maybe it’d be better to close this section and show a notice that requests should be sent in via mail.

    But that’s something that ACF will know best.

    As previously said; I’ve sent in the feature request and I hope it will find its way to the developers in time. It would be a great addition for usability, in my opinion.

  • Hello John,

    I will send them a message.
    But I expected that a forum section named “feature requests” was meant for this. 😅

  • Maybe this might help someone, I’m attaching my configuration for a link-button. It offers variations for internal, external and on-page (anchor) links.

    Also, this is a function to output a link:

    function nij_output_link($atts, $class = '') {
	if (!empty($atts)) {
		return;
	}

	$type = $atts['link_type'] ?? 'internal';

	$url = '';
	switch ($type) {
		case 'internal' :
			if (is_numeric($atts['link_' . $type])) {
				// this is a post id and should be converted to a link
				$url = get_permalink($atts['link_' . $type]);
			} else {
				// this is an archive link (and it should be left untouched)
				$url = $atts['link_' . $type];
			}
			break;

		case 'external' :
			$url = $atts['link_' . $type];
			break;

		case 'onpage' :
			$url = '#' . $atts['link_' . $type];
			break;
	}

	$target = $atts['link_target'] ?? '_self';

	$text = $atts['link_text'] ?: (($type == 'internal') ? get_the_title($atts['link_internal']) : '');
	$class = $class ?: '';

	if (is_admin() && !empty($text)) {
		$text = __('Knoptekst niet ingevuld', 'nijstartertheme');
		$class .= ' disabled';
	}

	return "<a href='{$url}' class='{$class}' target='{$target}'>{$text}</a>";
}
    acf-export-2....json

  • There’s still a downside, though:
    When multiple developers are working on the same installation, they will have to sync the fields manually.

    It would be very good to have a hook to disable the database fields completely, so we would just work with acf-json files.

  • Hi John,

    That might work, but I think I will use the solution from this post because in our case we’ll always use the value of the link field combined with a function that will apply it’s own formatting. So it’s OK to just always remove the formatting.

    Though I think that it would be a good thing if ACF would think about introducing an option to enable/disable formatting for this field type, just like various other fields support this.

  • Hi John,

    I might be understanding you incorrectly. But when I use the code below, the var_dump is returning null.

    function acf_reformat_page_link( $value, $post_id, $field ) {
		var_dump($field['value']);

		return $value;
	}
	add_filter('acf/format_value/type=page_link', 'acf_reformat_page_link', 15, 3);

  • I guess I solved my problem with the following:

    add_action('acf/init', function () {
	remove_filter('acf/format_value/type=page_link', array(acf_get_field_type('page_link'), 'format_value'), 10);
});

    Later on I will use get_permalink() on numeric values and leave string values (archive links) untouched.

  • Hi John,

    Thanks, this does work.

    However, unfortunately it doesn’t really solve my problem. I will elaborate a bit why.

    We usually build sites where a global variable ($post_sets) is being assigned with all ACF metadata from a post, on single pages and in ‘the loop’. This is done with the function below function.

    function get_post_options($post_id = null) {
	if (function_exists('get_fields')) :
		global $post_sets, $post;

		$post_sets = '';

		if (!is_numeric($post_id) && exists($post)):
			$post_id = $post->ID;
		endif;

		<strong>$post_sets = get_fields($post_id);</strong>

		// if $post_sets is 'false', we're assigning an empty array to it
		// that's more handy for error handling.
		if ($post_sets == false) {
			$post_sets = array();
		}

		return $post_sets;

	endif;
}
add_action( 'wp', 'get_post_options');
add_action( 'the_post', 'get_post_options');

    If I would add false to the $post_sets = get_fields($post_id); line, I will lose all (very useful) formatting that’s being done by ACF. I even lose the field names of subfields.

    I really only need to get rid of the formatting that’s being done by the page_link field. Am I wrong that various fields have a way of altering the formatting with a filter? Shouldn’t the page_link field offer such a thing as well?

  • This works. The big catch is that the content of blocks doesn’t update dynamically when changing values of a field. Only after a full page reload the value will be changed.

  • Let’s not forget that using the problem is not there when using option types like ‘post-object’ and ‘page-link’ because they don’t ‘hardcode’ the url to the database, but (probably?) use a filter to process the post ID when retrieving the value. The ‘url’ and ‘link’ fields hardcode the value to the database.

    I understand that there’s the possibility to create my own option type. I don’t have any experience with that for Advanced Custom Fields, but it’s a possibility. I can just be honest: I don’t have the knowledge to build something like that.

    But if you mention that this problem has been around for a long time and keeps coming back from time to time.. shouldn’t that be considered as a sign that it’d be a good idea for ACF to look into it more? Maybe a complete solution is possible?

    But well.. maybe WordPress will implement a solution on their own. The only real change that should be made is that internal links get saved with their ID instead of the plain url, and then process it when retrieving it.

  • Hi John,

    Thanks for the extensive explanation. I can see that you really put a lot of thought into it.

    My first thought when you say that you’re using a module/template-part for something as small as a link, is that it seems like overkill. But it probably has pros and cons, I guess.

    We never went this far with components/template-parts and clone-able ACF option groups in our projects. It sure is an interesting approach and in the end it will probably save time, but it will take preparation to adopt it completely. We will consider it for future projects.

    Although this is a nice insight, I still feel like ACF has a plethora of possibilities to make the user input a link, and none of them is ideal. The ‘link’ type comes very close, but has a problem that ACF probably can’t solve because it’s WordPress core.

    Of course you can work around the problem by combining the 5 fields in a group and duplicating them wherever you want, but ACF is meant to make things simpler, right? This is a problem that every developer who works with ACF will need to tackle sooner or later. This feels like everyone has “to reinvent the wheel” while ACF could come up with a simpler solution.

    In my opinion it would probably be best if this problem would be addressed at the root, instead of somewhere along the line.

  • Hi John,

    Yes, you are right in stating that this is the default behaviour of WordPress.

    Not to be rude, but of course employees of an SEO company know that a slug shouldn’t be changed without thinking about it. The point is that the average client does not know this. Installing a redirection plugin and teaching the client how to use it could be a solution, but I think it doesn’t make things easier for anyone.

    For me the real problem is as described above: it’s a pity that we need to add 5 (!!!) fields to have a fool proof solution for having just a button with:
    – an internal/external link
    – label text
    – option to open in a new browser tab

    And as said, the code to implement such a button on the front end is way more complex then it would be when using the ‘link’ field since all the information is in one place and no switches are involved.

    The link option combines all these abilities, which is absolutely great. But it misses out in the case a slug is changed, while other fields like the ‘page link’ and ‘post object’ keep working because they use a post ID. I understand that this is the default WordPress implementation, but if that’s not good enough, ACF could consider building it’s own version. But if no one makes notice of the problem, it won’t happen. So that’s why I added my comment here.

    On a side note:
    I knew that WordPress sometimes redirects old slugs to the new ones, but I didn’t know how it exactly worked. You probably know this, but it might be interesting for other people. Apparently it’s being done by saving old slugs in the post-meta of posts, but only for posts that are non-hierarchical. (see: https://developer.wordpress.org/reference/functions/wp_old_slug_redirect/)

  • I forgot to mention that we’ll also need extra fields for a label and activating “target=’blank'”.

    So for places where internal and external links can be used, we are forced to use:
    – a switch to choose between inserting an internal/external link;
    – a post object or page link field for internal links;
    – a url field for external links;
    – a switch to activate “target=’blank'”;
    – a text field for the label/text on a button/link.

    All of these could be replaced by using the link field, if only it’d update the actual url when a slug changes.

  • I experienced this problem today as well. A client updated the slug of some pages and now the links in some buttons weren’t working any more.

    The problem with the ‘post object’ and ‘page link’-fields is that they can’t be used for external links. I thought the ‘link’ field was ideal because it supports every thing, until this problem popped up..

    So for places where internal and external links can be used, we are forced to use:
    – a switch to choose between inserting an internal/external link
    – a post object or page link field for internal links
    – a url field for external links

    Is this really the best way? That’s a bit frustrating to set up and to code for.

  • I think the option to just save the timestamp should be added.

  • Let’s all just agree that having the option to just save the value as a timestamp would be very handy.

  • Hi @lgladdy,

    When I add your code to a Javascript file that loads on the admin pages, I get the following error: ‘ReferenceError: Can’t find variable: acf’, which probably means that it’s running too early.

    When I wrap is with jQuery(function () { ...your code... }, I’m seeing different colors but not the ones that I added to the theme.json file.

    Also: I need this for a colorpicker field on a term page. Should that code work there as well? I suspect it’s only working for pages where the block editor is being loaded.

  • @dominikkucharski:
    The initial setting for the size of the block is fine when both ‘align’ and ‘supports[align]’ have been configured. But the align-toolbar still shows, which results in the user being able to toggle between the ‘wanted’ and ‘unwanted’ align setting, although there should be only one option.

  • I thought it through a bit and came up with the code below. It works for my block, only on the back-end because we’re just using PHP on the front-end.

    if (is_admin()) { ?>
 <script>
  document.querySelector('.editor-post-title__input').addEventListener('input', (e) => {
   var title = e.target.value;
   document.querySelector('.SELECTOR-OF-ELEMENT-YOU-WANT-TO-CHANGE').innerHTML = title;
  });
 </script>
<?php }

  • Wondering this as well. So far I can only get the title of the block (same as title of the post) to update when I refresh the page.

  • For future reference, as I hope that this question has been resolved in the mean time:

    acf_register_block_type(array(
 ...
 'mode'	=> 'edit',
 'supports' => array('mode' => false),
));

    When using these settings for a block, it will start in edit mode and the user won’t be able to switch.

  • Great!

  • Wow, thanks for the tip @chrisdark! 😄

  • In the end I settled with only using the acf-json files (https://www.advancedcustomfields.com/resources/local-json/). In the hierarchy of ways that fields can be added, ACF prefers the acf-json files above the fields in the database.

    I don’t do any synchronisation between environments at all anymore. The JSON files are being distributed to testing and live environments through git.

    The whole ACF admin area is hidden on environments other then the local development environments. This way fields can only be added or edited on development environments, if this could also be done on other environments, the changes would be overwritten upon a git update.

  • +1

    It would be very nice to predefine values for blocks in templates.

Viewing 25 posts - 1 through 25 (of 35 total)
1 2