Support

Account

Home Forums Bug Reports field type link doesn't update Reply To: field type link doesn't update

  • I don’t know if this will help you or make your dev process any easier. My goal when I build a site has to do with making things easy for the client and not necessarily making it easier for myself, so when I’m building the admin for the client I don’t even give much thought to how difficult it will be for me to code, I just make sure that it’s something that can be coded. However, I do my best to never code something more than once.

    I build in “modules” I have a field group that has all the settings I need for links, not only the ones you mention but others. I then clone this field group as the only sub field of a “Group Field”, this insures that all fields of my group are always “sub fields” With this in place I have a single template part file that is called to output links.

    
    // something like this goes into my template
    if (have_rows('group_field_name')) {
      // always true for a group field that exists
      while (have_rows('group_field_name')) {
        // always executes once for group fields that exist
        get_template_part('template-parts/components/link);
      }
    }
    

    So I have only coded this once. My group has become quite complicated, but if changes are made I only need to make them in a single file.

    The field group for links can also be cloned as the only sub field in a repeater and the template part file will still work but allow the client to add multiple CTA buttons.

    I actually use a true/false field the new window setting. The label on the true false field is
    – Same Window = false
    – New Window = true
    and the code in my template part for building this part of the link button is

     
    $target = '';
    if (get_sub_field('target')) {
      $target = ' target="_blank"';
    }
    

    and example of my link output

    
    <a href="<?php echo $url; ?>" class="<?php echo implode(' ', $cta_classes) ?>"<?php echo $title.$rel.$target.$onclick; ?>><?php echo $text; ?></a>
    

    Also, when it comes to a URL and the client entering a URL, I do not use a URL field because it is too limiting. For example lets say that you want to allow the client to enter anything other than a URL. My clients and the people I work with want to be able to enter anchor links as well as tel:, mailto:, sms: and ftp: links. So instead of using a URL field I use a text field with custom validation. Building separate fields would increase the code and complicate things for the client. Instead I have a text field that will accept anything that appears to be a valid href value and as part of the client’s instruction when handing over the site they are shown how to use this field and the field has very good instructions to help remind them.

    
    add_filter('acf/validate_value/key=field_XXXXXXXX', 'validate_text_as_href', 20, 4);
    function validate_text_as_href($valid, $value, $field, $input) {
      // this allows links starting with
      // / (site root relative), http://, https://, ftp://, # (anchor), mailto:, tel:, sms:
      if (!$valid) {
        return $valid;
      }
      if (!empty($value)) {
        if (!preg_match('%^(https?\://|ftp\://|/|#|mailto\:|sms\:|tel\:)%', $value)) {
          $valid = 'Enter a Valid HREF Value';
        }
      }
      return $valid;
    }
    

    As to automatically updating or redirection, I have not built anything that will automatically redirect if the slug of a page is changed. I will need to look into that, what I do know is that what is built into WP rarely works as expected.

    As far as automatically updating links when a slug or url changes, you would need to keep some type of history on the slug/url of the page when it is updated. You would need to add a pre_post_update action that somehow checks to see if the url of the page is being changed. If it is then you’d have to figure out how to lookup and changed all of the other posts and pages where there is a link to the page being updated and change them without this process timing out the admin page refresh. This would basically mean that you’d have to record somewhere/somehow all of the places where a link to the page is saved to allow a quicker lookup so that they can be found quickly and updated.

    This brings me back to the automatic redirection because the testing to see if the URL has changed for a page sparked an idea. You could as in the above add a pre_post_update action and if possible record a history of all of the URLs that were ever assigned to this post and then on a 404 you could do a search for posts that have had the missing URL. This isn’t actually a bad idea that I may look into.