This repository has been archived by the owner on Feb 23, 2024. It is now read-only.
Version 7.3 uses relative URLs to load scripts from wp-includes #6186
Labels
block: cart
Issues related to the cart block.
priority: high
The issue/PR is high priority—it affects lots of customers substantially, but not critically.
type: bug
The issue/PR concerns a confirmed bug.
Comments
|
We are not responsible for enqueueing core scripts, are you sure this issue is limited to WooCommerce Blocks 7.3.0 and not something coming from WordPress/Gutenberg. We also had some recent updates to our script loading system, can you check 7.4.2 and confirm if this still persist? |
|
I'm still seeing this in 7.4.2. If only WooCommerce is active, they load correctly. With Blocks active, they are not. Here's a screenshot of the source code on the cart page. I've included the system report from another site showing this too.
System Status Report |
|
This is still a problem with the current version 7.5.0. The above /wp-includes/js/dist URLS are added by WooCommerce Blocks when the plugin is enabled. You don't need to add "WooCommerce Checkout" or "WooCommerce Cart" blocks on your checkout or cart page. This results in dozens of 404 not found errors when a user visits the cart or checkout page on the website. The 404 errors can trigger security software to block a user, preventing a successful checkout. |
|
I can confirm this is still happening in version |
Aljullu
added
type: cooldown
|
|
|
LOTS of problems with WooCommerce Blocks. Does it work with wordpress installed in a sub-folder???? WooCommerce Blocks is disabled, yet this continues to load when "logged in". Assume problem has been migrated into WooCommerce itself. note that "www.my-word-press-url.com/wp-subfolder" replaces the actual Web URL... |
|
I'm going to investigate this today and let you know if I manage to reproduce it and if I can fix it. |
|
Hello, It seems to be a wordpress problem in the file script-loader.php, it loads scripts with this relative path to webroot /wp-includes/... |
|
I'm having the same issue but i don't have woo blocks plug in installed. |
Looks as if the problem has migrated from woocommerce blocks into woocommerce itself . It affects all logged in users OR when an item is in the cart and WP is installed in a sub-folder. |
|
Same problem here. Wordpress installed in subdirectory /wp (bedrock). Rolling back to 6.8.2 fixes the issue |
|
This also causes problems with the |
For me happens when you have some product in your cart, even if you are logged in or out! |
Yes you are right! didnt notice that! |
|
Hi, Also ran in to this issue. Rolling back was not an option si I added this to our in-house mu-plugin as a temporary fix and maybe a few people can adapt it to their project while waiting for a fix: You'll need to at least change the filter declaration to not use "Core::" and remove "public static" if used outside a class. public static function boot(){
if( ! function_exists('is_plugin_active') ){
include_once( ABSPATH . 'wp-admin/includes/plugin.php' );
}
if( ! is_plugin_active('woocommerce/woocommerce.php') ){
return;
}
if( version_compare(WC()->version, '6.3.1', '>') && version_compare(WC()->version, '6.9.3', '<=') ){
Core::add_filter( 'wp_resource_hints', ['WooCommerce', 'wp_resource_hints'], 99, 2 );
}
}
/**
* Fix resource hints for WooCommerce 6.3.1+ - 6.9.3
*
* @param array $urls URLs to print for resource hints. Each URL is an array of resource attributes, or a URL string.
* @param string $relation_type The relation type the URLs are printed. Possible values: preconnect, dns-prefetch, prefetch, prerender.
*
* @return array WooCommerce resource hints (corrected if relation type is 'prefetch' and href starts with a '/').
*/
public static function wp_resource_hints( $urls, $relation_type ){
if( 'prefetch' === $relation_type ){
array_walk( $urls, function( &$url ){
if( '/' === $url['href'][0] ){
$url['href'] = site_url( $url['href'] );
}
});
}
return $urls;
}Hope this helps. Cheers. |
5 tasks
4 tasks
ralucaStan
added
the
priority: high
|
We now have a fix here |
|
@tombroucke do I understand that this bug is breaking cart functionality for you? |
|
Thank you all for reporting. A fix for this issue will be shipped in WC Blocks 8.6.0 coming next week. |
|
WC Blocks 8.5.1 – 2022-09-23 |
|
Did that fix your issue @getfaxing ? |
Yes, updated to 8.5.1 and enabled WooCommerce Blocks plug-in. Seems to have resolved the 404s |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
Prior to version 7.3, scripts loaded from
/wp-includesused absolute URLs. Now they use relative URLs. If someone has placed WordPress in a sub-folder, this will cause all of the scripts to return 404 errors.The scripts included with the plugin continue to use absolute URLs.
To reproduce
Steps to reproduce the behavior:
/wp-includesscripts.Expected behavior
I expected the scripts to continue to use absolute URLs.
Screenshots
Before 7.3
Version 7.3
Environment
WordPress (please complete the following information):
Additional context
Reported here: https://wordpress.org/support/topic/relative-vs-absolute-url-causing-problems
The text was updated successfully, but these errors were encountered: