Support

Account

Register Login

Forum Replies Created

  • I’m trying to do something somewhat similar to this. I don’t want to allow invalid URLs, but I’d like to be able to allow internal links within the same page without having to include the full URL. In other words, I’d like the validation to pass if the URL begins with #.

    I’m trying to use add_filter('acf/validate_value/type=url') to apply the following logic:

    if ((!$valid || strlen($valid) > 1) && strpos($value,'#') === 0) { return true; }

    I find that if I do this, it changes the validation error message from “Value must be a valid URL” to “Enter a URL”… but it’s still failing to validate.

    I find the whole way this filter works a bit confusing, as $valid can be one of three values: false meaning the data is invalid; true meaning it’s valid; or an error message string (which would evaluate to true) if it’s invalid.

    Besides that… I would think I’m not alone in wanting/needing in-page anchor links to validate in a URL field. Yes, I could change this to a regular text field, but I want URL validation on the input… I just want to also be able to allow in-page anchor links to pass validation.

    What am I missing?

    (Edit: Strangely, I did a scan of the entire codebase of ACF PRO and I could not find a single instance of the phrase “Enter a URL” anywhere. So I really don’t have a clue where this extra validation step is coming from.)

  • Unfortunately this did not resolve the issue for me. I had already manually rolled back to 5.7.10, so I just ran the available 5.7.11 update, and the problem returned. (I have now rolled back to 5.7.10 again.)

  • UPDATE: I just rolled the site back to using ACF 5.7.10, and the preview works. So it appears to be the result of a change in version 5.7.11. I’m doing a diff between the two versions to try to figure out what changed that might be relevant, but I haven’t scrutinized the ACF source code before and I’m not sure what to look for.

  • I’ve been using ACF for many years on dozens of sites, and have never encountered this problem until now. I am running the latest version of ACF (5.7.11) with the latest version of WordPress (5.0.3). This is only affecting one particular site, that I’m aware of.

    The site has been having a few other issues recently, as it’s on a server that’s still running Ubuntu 14.04, and I just had to manually update PHP to 7.2 from 5.5 for some unrelated reasons. I think it’s possible I missed something in the update that is causing this issue, but it’s curious that it’s exactly what’s described here — if a post is in draft mode, the custom fields don’t show on preview, even though they do save on the back end, and if you schedule or publish the same post, they do appear on the front end. Then if you switch it back to draft, they go away again.

    I should note that I did set up a brand new VPS today running Ubuntu 18.04 with all available updates, migrated the site over to that server, and the problem persisted. (So it’s probably not directly about the PHP 7.2 patch I did on the old server — but perhaps related to some database cruft that came along for the ride.)

  • The issue appears to be fixed with this update. I’ve removed the workaround code I had added to address it, and my page is still working as expected.

  • Thanks… I may not have a chance to test this immediately but I’ll check it out as soon as I can.

  • The first item in the changelog for version 5.7.1 sounds like a fix for this bug. Do you know if that’s correct? (I’m not asking you to do any work to find out… just if you know for sure or not already.)

  • Thanks… my theme does make some modifications to search, specifically to add in custom fields since almost all page content is handled with ACF and not the post_content field. I’ll see if I can tweak these modifications not to run on AJAX calls.

  • None that I’m aware of.

  • Unfortunately I haven’t had a chance to revisit the issue. This was on a client’s live site, and I couldn’t really justify either tinkering with their live site now that it’s working, or being “on the clock” to set up a test copy of their site just for the sake of experimenting with it.

    Are you referring to the “Core: Fixed bug where updating value did not clear persistent cache” change in version 5.3.9? My client’s site was running the latest version of ACF when I posted my original reply on August 19, and 5.3.9 was released in June, so that wouldn’t have been a factor. That is the most recent note in the change log pertaining to caching.

  • I have a client who was running into this issue — they crop images in WP using the standard editing tools, but the cropping would revert to the original version in the Image field preview after saving, and would not show up on the page itself.

    I dumped the contents of the image array on the front end and confirmed that the $image['url'] value was the correct new image URL WordPress had generated, but the URLs in the $image['sizes'] subarray were for the old, uncropped version of the image.

    I was able to work around the problem in this client’s case by just using $image['url'] for the image URL in the page template and in WP admin by setting the Image field’s preview to “Full Size”… but this is an incomplete solution as it doesn’t allow for displaying smaller versions of the image.

  • I just want to chime in on this… I came here to report this as a bug and you’re already prepping a fix. Thanks for the great work, Elliot! ACF is an essential part of just about every project I do these days.

  • Thanks for this fix! It did the trick for me. I’ll second the note that in ACF Pro 5.2.9 the lines in question are 303 and 304.

    Hopefully this fix will get rolled into a 5.2.10 update shortly!

Viewing 13 posts - 26 through 38 (of 38 total)
1 2