Archived topic
Registered style incomplete URI
16 replies · Started by vast on October 6, 2020
It seems that the Style Handle: generateblocks is registered as //domain.com as opposed to https//domain.com.
For example, it loads as //domain.com/wp-content/uploads/generateblocks/style-123.css?ver=1601971961 as opposed to https://domain.com/wp-content/themes/generatepress/css/all.min.css for Style Handle: generate-style
Style Handle: generateblocks appears to be non-standard.
1. Can it be included as a bug fix in the next release?
2. In the interim, what options are there to register Style Handle: generateblocks the same as Style Handle: generate-style?
Hi there,
GB remaps domains - and i have not been able to replicate that issue.
Can you share a link to the site so we can take a look at why thats happening ?
Hi David,
If you include the function below, the output will differ.
It returns;
Style
Handle: generateblocks
URL: //domain.com/as opposed to when comparing to another style;
Style
Handle: generate-style
URL: https://domain.com/function print_scripts_styles() {
// Print Scripts
global $wp_scripts;
foreach( $wp_scripts->queue as $handle ) :
echo '<div style="margin: 5px 3%; border: 1px solid #eee; padding: 20px;">Script <br />';
echo "Handle: " . $handle . '<br />';
echo "URL: " . $wp_scripts->registered[$handle]->src;
echo '</div>';
endforeach;
// Print Styles
global $wp_styles;
foreach( $wp_styles->queue as $handle ) :
echo '<div style="margin: 5px 3%; border: 1px solid #eee; padding: 20px; background-color: #e0e0e0;">Style <br />';
echo "Handle: " . $handle . '<br />';
echo "URL: " . $wp_styles->registered[$handle]->src;
echo '</div>';
endforeach;
}
add_action( 'wp_print_scripts', 'print_scripts_styles', 101 );Hi there,
This is intended as of right now, as // should work with http and https without any issues.
Do you have any reading on why this is a bad idea I can check out?
Thanks!
Is there any reason why the resource should be served over HTTP?
Protocol/scheme relative URIs are an anti-pattern these days given the ubiquity of TLS/SSL. It also introduces an element of misconfiguration and opens an avenue to attacks such as MiTM and MiTB.
Paul Irish (from Google) touched on the topic some time ago - https://www.paulirish.com/2010/the-protocol-relative-url/
Thanks for this - appreciate it! Will get it updated in the next version :)
Great. When will the next version be released? In the meanwhile, is there a workaround?
No workaround as of right now unless you want to turn on Inline Embedding in "Settings > GenerateBlocks".
We're working hard on 1.2.0, hoping for an alpha release soon.
What are the side effects if inline embedding is enabled?
It loads the CSS in the <head> instead of caching it in an external file.
Righto so the potential is for a slightly heavier page (which isn't necessarily a downside depending on the caching methodology).
Out of curiosity, is there any reason why the resource being enqueued with cache busting?
Having it cached as a file means the PHP isn't having to generate the CSS based on your settings on ever load - it just does it once and caches it as a static file.
The cache busting is necessary to prevent issues when a page is updated and the CSS changes.
Do you mean that the CSS is not being generated for every request (assuming it isn't inline)?
If yes, rather than using query strings, is it possible to include in the next release file path instead e.g. /ver1/file.css, /ver2/file.css, etc?
This is because the ability to interpret query strings while native to browsers isn't necessarily the same when using a CDN (dependent on the CDN and the configurations).
For example, if a CDN has been configured (default or otherwise) to ignore query strings, cache busting won't be as effective when using file.css?ver=1.
A file path would cater for multiple scenarios including CDNs, browsers, etc.
Hi Tom,
Can the recommendation be included in the next release?
Something like that would be difficult and likely mean a re-write of the CSS file generator we're using. It's definitely worth some more research and experimentation, but it definitely won't be in the next release.
Really appreciate your feedback and thoughts on this - thank you!
