Hi, Bastian!
It sure is. The ACF dependencies are all loaded with wp_enqueue_script/style. You can dequeue these assets using wp_dequeue_script/style. The names of the ACF assets are acf-input and acf-pro-input.
Please be aware that you might have to add a few styles to make your forms look alright. For example, the honeypot field is enclosed in a div with class “ace-hidden”. This needs to be hidden through CSS otherwise the honeypot will be visible to users.
Let me know if this works!
Hi Fabian,
thanks for the support, unfortunately there are some more styles enqueued for some extra fields (e.g. codemirror styles and codeeditor input, acf-input-font-awesome, acf-input-font-awesome-library, etc.) So every field type I installed prints another css file..
For some reason I can’t get rid of them using wp_deregister_style() and wp_dequeue_style() neither by the wp_enqueue_scripts() function nor by wp_print_footer_scripts() which fires extremely late. I also tried different priorities.
So if i deregister acf-input the other styles complain about missing dependencies.
Are you using some other plugins which introduce new ACF field types? I don’t think those stylesheets come from ACF.
If the other plugins enqueue their styles correctly then it should be possible to use wp_deregister_style although it’s totally possible they don’t!
yeah thats what I said. The styles get enqueued with wp_enqueue_style() correctly like I see. But I can not deregister them.
Are you able to deregister them if Advanced Forms is not activated?
If AF isn’t activated the styles & scripts are not registered in Frontend.
Was thinking about deregistering them in the backend. Does that work as expected?
Sorry for the late response. It seems like the Update I got from ACF that fixed this issue https://wordpress.org/support/topic/doesnt-work-with-the-new-version-of-acf-581/ also fixed this one.
sorry.. me again.
I recognized the scripts and styles get included just on pages where a form is displayed.
So I am pretty sure it’s about the acf_enqueue_scripts(); function in /core/forms/form-rendering.php on line 76.
I found this function in /advanced-custom-fields(-pro)/includes/assets.php and it returns acf_get_instance('ACF_Assets')->enqueue_scripts( $args ). I don’t know where acf_get_instance() and enqueue_scripts() are defined so I don’t know which hook to use to dequeue these scripts..
Maybe it’s just about the args param in acf_enqueue_scripts() which is empty in your forms-rendering.php
ok so the enqueue_scripts() function uses the following actions to enqueue scripts:
add_action( 'wp_enqueue_scripts', ... );
add_action( 'wp_print_scripts', ... );
add_action( 'wp_head', ... );
add_action( 'wp_footer', ... );
add_action( 'wp_print_footer_scripts', ... );
if I use them to dequeue Query Monitor says all the scripts are gone now. But when I view source they are still in and some of them throw errors. Especially when a caching plugin like autoptimize is active.
Do you run into the same issues without any caching plugins at all?
yes it’s the same. But I had a conversation with the ACF support and they made things more clear.
ACF uses all these actions mentioned above but with a acf/input/ prefix.
With caching plugins active theres still one JS error about an unnecessary inline script which is no neckbraker imo.
Good to hear! Javascript and caching plugins can be a real pain to get right. Let me know if you learn something interesting you would like to share 🙂
