Support

Account

Forum Replies Created

  • Sounds like a great idea using the PHP filters. I’ll check for the correct implementation and post the code.

    For the JS solution, I tried adding a condition from the browser inspector which doesn’t seem to work. So, I assume this needs to happen before the initialization.

  • Thanks for the quick reply. I just tried it. Seems like no methods work on the instance found by the acf.getField() function, even when using the field key.

    Notably, the getField method always finds the same field, no matter whether I’m using the name or key, but the methods on it always return undefined, though the prototypes are available.

    Might this be a bug or am I just doing something horribly wrong?

    However, I got it to work by using the acf.getField() method: acf.getFields({name: 'my_field_name'})[0].val() and acf.getFields({key: 'my_field_key'})[0].val().

  • It seems I’m also having trouble with other methods on the field not working, such as show() and hide().

  • Thanks for the quick reply, John. There is no dependancy on the ACF JS, just the IDs and classes are needed for some show/hide logic.

    I wish those changes were documented in the upgrade guide, as they break a lot of things. Ideally there would be another compatibility filter that – when enabled – outputs the old ID and class format. I liked the field names in the IDs as it made it obvious, what input field belongs to which custom field.

    But I’m happy I didn’t overlook any obvious setting and will start implementing the new IDs and classes now. 🙂

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