Support

Account

Home Forums Backend Issues (wp-admin) Backend validation prevents saving options

Solving

Backend validation prevents saving options

  • In the backend I have a custom post type and we are using ACF to add/validate some fields. For some reason though, it appears ACF is doing validation on submitting options changes (for example, change number of items in view).

    Best illustrated by a screenshot:

    saving settings

  • Bump!

    • fotaras

    • February 14, 2019 at 2:10 am

    Same here.

  • I have looked at this and I’m seeing the same thing. I cannot figure out any way to work around this issue. Please submit a bug report on this https://www.advancedcustomfields.com/contact/

    Actually, I do have a solution, however it may not be for everyone. My solution is that I remove the field groups from this page and I never make anything required and substitute some default for every field. This requires adding a custom value acf/location/rule_values/taxonomy and match acf/location/rule_match/taxonomy rules for taxonomy, unfortunately, I cannot find the relevant code on any of my sites right now. https://www.advancedcustomfields.com/resources/custom-location-rules/

  • What I don’t get here is that both buttons do have unique IDs. I’m not following how whatever js events are fired are tied to both buttons?

  • I’m not sure either, so I’m just as confused. There are 3 completely separate forms on this page, the advanced setting at the top, the search form and the new category form. This is not triggered when doing a search, but it is triggered when changing the number of terms to show.

  • I’m glad this is fixed, but having poked at the issue myself for a good hour or so, I’m incredibly curious about two things:

    – Being a javascript noob, I find debugging is the hardest part, what tool/tools do you use to poke at an issue like this? For example, I was looking at “event listeners” on the options button and didn’t see anything amiss…

    – What was the fix?

  • I don’t know what the fix was, I think I saw a note about it in the changelog. I’m not a dev working on the site, just another user.

    Debugging JS can be difficult and it get’s more complex if AJAX is involved.

    When I’m working on straight JS I usually add a console.log(SOMETHING); to see what values are. Same as using echo or print_r in PHP. Sometimes I throw in alert(SOMETHING); for simple values.

    When dealing with AJAX you have 2 things to contend with, the JS and the server side PHP code. It’s impossible to see what’s happening on the server side in the browser. When I’m dealing with the PHP side I use errro_log() http://php.net/manual/en/function.error-log.php to write stuff to the error log.

    Debugging someone else’s JS/AJAX can be infinitely more complex than debugging your own, especially when AJAX is involved. While I’m doing dev on my own stuff and I’m dealing with AJAX, I am usually returning JSON and I have a console.log(json); so that I can see what’s being returned. Then I can simple do something like echo json_encode($_POST); exit; on the PHP side to see what was submitted, or to see whatever I want to see from the server in the AJAX response. Tracking down where to do these things in someone else’s code can be done but it’s a lot more difficult.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.