Closed wordpressfan closed 8 months ago
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).
@wordpressfan Let's try to fix this and also introduce the filter to disable this feature completely.
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-L58and 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 activeWhen
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#L524they have CF7 script as a dependency, so as u can see they have a function called
wpcf7cf_load_js
which applies the filterwpcf7cf_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:
we can updated our compatibility file here: https://github.com/wp-media/wp-rocket/blob/0484f529d64e11e9a6d2f7af13127f69bb76045c/inc/ThirdParty/Plugins/ContactForm7.php#L6
with every instance of
wpcf7_load_js
we need to do that same with the filterwpcf7cf_load_js
, for example here: https://github.com/wp-media/wp-rocket/blob/0484f529d64e11e9a6d2f7af13127f69bb76045c/inc/ThirdParty/Plugins/ContactForm7.php#L36-L37we need to add the following two lines:
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:
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 bewpcf7_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
andwpcf7_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