Some issues with our compatibility file for Contact Form 7

[wordpressfan]

I checked two escalated cases and found out some issues with Contact Form 7 so I'll add the full details here so we can take a decision with the team if we want/need to do any enhancement here or have a documentation for the following points but I need to give you a small intro that most of those points are depending on, which is:

When you register a script without enqueuing it and then enqueue another script that has the first script as a dependency, this will force enqueuing the first one, let's check the code of CF7 to see this in action:

Start here, they register the script contact-form-7
https://github.com/rocklobster-in/contact-form-7/blob/v5.8.6/includes/controller.php#L49-L58

and only enqueue it inside the following function:
https://github.com/rocklobster-in/contact-form-7/blob/v5.8.6/includes/controller.php#L110

and this function is called when the filter wpcf7_load_js is applied here:

https://github.com/rocklobster-in/contact-form-7/blob/v5.8.6/includes/controller.php#L68-L70

So the issue happens when a script is enqueued but has the contact-form-7 script ID as a dependency, this means that CF7 script will be enqueued directly without checking this filter so this may cause some errors with our compatibility file as below:

Console error in pages that don't have forms when having Conditional Fields for Contact Form 7 plugin active

When Conditional Fields for Contact Form 7 is active we see a console error as below:

and this is happening only for the pages that don't have contact forms.

and after checking their code I found that they start enqueuing their scripts here:
https://plugins.trac.wordpress.org/browser/cf7-conditional-fields/tags/2.4.6/cf7cf.php#L510

then calling their function wpcf7cf_enqueue_scripts then here:
https://plugins.trac.wordpress.org/browser/cf7-conditional-fields/tags/2.4.6/cf7cf.php#L524

they have CF7 script as a dependency, so as u can see they have a function called wpcf7cf_load_js which applies the filter wpcf7cf_load_js

So we need to use the following filters to control the loading of their scripts that causes CF7 scripts to be enqueued too:

wpcf7cf_load_js
wpcf7cf_load_css

we can updated our compatibility file here:

wp-rocket/inc/ThirdParty/Plugins/ContactForm7.php

Line 6 in 0484f52

class ContactForm7 implements Subscriber_Interface {

with every instance of wpcf7_load_js we need to do that same with the filter wpcf7cf_load_js, for example here:

wp-rocket/inc/ThirdParty/Plugins/ContactForm7.php

Lines 36 to 37 in 0484f52

	add_filter( 'wpcf7_load_js', '__return_false' );
	add_filter( 'wpcf7_load_css', '__return_false' );

we need to add the following two lines:

add_filter( 'wpcf7cf_load_js', '__return_false' );
add_filter( 'wpcf7cf_load_css', '__return_false' );

and the same needs to be done below in the same file, or we can create another compatibility for that.

Conflict when custom themes that is adding custom scripts that works with CF7

I found a customer that has the following code in his custom theme:

add_action( 'wp_enqueue_scripts', 'XXX_scripts', 100 );
function XXX_scripts() {
	wp_enqueue_script(
		'XXX-contact-form-7',
		get_stylesheet_directory_uri() . '/assets/js/contact-form-7.js',
		[ 'contact-form-7', 'jquery' ],
		XXX_VERSION,
		[ 'in_footer' => true ]
	);
}

this code will also force enqueuing CF7 script even when not needed (without checking if CF7 should be enqueued or not)

This can be fixed by replacing the action from wp_enqueue_scripts to be wpcf7_enqueue_scripts which only fires when CF7 scripts are being loaded.

Enqueuing CF7 directly is a problem because it will load the script only without adding the localized script wpcf7 which is a requirement for the CF7 script.

So the question is, why this is happening only with our compatibility file?
That's a good question, the answer is that by default the filters wpcf7_load_js and wpcf7_load_css return true so the script will always be enqueued along with the localized script.

But our compatibility file is changing their return based on if the current page contain a contact form or not, and if case of Not the localized script won't be added even if a third party enqueued CF7 script which causes console errors and corrupted functionality.

So I believe we are not wrong, the wrong comes from the third parties that need to add some condition before loading their scripts.

We need a product decision here on what should we do next.
@wp-media/productrocket

[joejoe04]

I have an issue that seems likely related to this issue (They use CF7 and I've confirmed it only happens for version 3.15.6 or later):

Ticket:
https://secure.helpscout.net/conversation/2474926120/467933

In this case, if you add an item to cart from a page like this:
https://traiteurwille.de/shop/handgefertigte-kartoffelpuffer/

Then go to the cart page with the item added and WP Rocket optimizations not applied (as should be the case) and no signs of an extra cache layer:
https://traiteurwille.de/warenkorb/

The datepicker functions are not available:
https://i.imgur.com/7cLEjoE.png

This is how it works while on WP Rocket version 3.15.5 or earlier:
https://i.imgur.com/zqhA4co.png

I'm definitely confused why this is happening even for uncached pages, but I compared the scripts that are loaded while on WP Rocket version 3.15.5 to 3.15.6, and each of the following are loaded on the page while using 3.15.5, but not 3.15.6:

/wp-content/plugins/contact-form-7/includes/swv/js/index.js?ver=5.8.5
/wp-content/plugins/contact-form-7/includes/js/index.js?ver=5.8.5
/wp-includes/js/jquery/ui/core.min.js?ver=1.13.2
/wp-includes/js/jquery/ui/mouse.min.js?ver=1.13.2
/wp-includes/js/jquery/ui/slider.min.js?ver=1.13.2
/wp-includes/js/jquery/ui/controlgroup.min.js?ver=1.13.2
/wp-includes/js/jquery/ui/checkboxradio.min.js?ver=1.13.2
/wp-includes/js/jquery/ui/button.min.js?ver=1.13.2
/wp-includes/js/jquery/ui/draggable.min.js?ver=1.13.2
/wp-includes/js/jquery/ui/droppable.min.js?ver=1.13.2
/wp-includes/js/jquery/jquery.ui.touch-punch.js?ver=0.2.2
/wp-content/themes/rosa-child/assets/js/contact-form.js?ver=1698982492
https://ajax.googleapis.com/ajax/libs/jqueryui/1.11.4/i18n/datepicker-de.min.js?ver=1.11.4
/wp-includes/js/jquery/ui/datepicker.min.js?ver=1.13.2
/wp-content/plugins/contact-form-7-datepicker/js/jquery-ui-timepicker/jquery-ui-timepicker-addon.min.js?ver=6.4.2
/wp-content/plugins/contact-form-7-datepicker/js/jquery-ui-timepicker/i18n/jquery-ui-timepicker-de.js?ver=6.4.2
/wp-content/plugins/contact-form-7-datepicker/js/jquery-ui-sliderAccess.js?ver=6.4.2
/wp-content/themes/rosa-child/assets/js/bw-shipping-date.js?ver=1695033652

These ones specifically reference date0 or datepicker:

https://ajax.googleapis.com/ajax/libs/jqueryui/1.11.4/i18n/datepicker-de.min.js?ver=1.11.4
/wp-includes/js/jquery/ui/datepicker.min.js?ver=1.13.2
/wp-content/plugins/contact-form-7-datepicker/js/jquery-ui-timepicker/jquery-ui-timepicker-addon.min.js?ver=6.4.2
/wp-content/plugins/contact-form-7-datepicker/js/jquery-ui-timepicker/i18n/jquery-ui-timepicker-de.js?ver=6.4.2
/wp-content/plugins/contact-form-7-datepicker/js/jquery-ui-sliderAccess.js?ver=6.4.2
/wp-content/themes/rosa-child/assets/js/bw-shipping-date.js?ver=1695033652

The issue seems related specifically to this file:
https://traiteurwille.de/wp-includes/js/jquery/ui/datepicker.min.js?ver=1.13.2

Because the call stack includes only it and jQuery and jQuery-Migrate when I break on related attribute modifications (when I click the calendar icon to show the datepicker while on version 3.15.5).

[piotrbak]

@wordpressfan Let's try to fix this and also introduce the filter to disable this feature completely.