- This topic has 16 replies, 3 voices, and was last updated 1 year ago by
.
-
Posts
-
It seems that the
Style Handle: generateblocksis 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=1601971961as opposed tohttps://domain.com/wp-content/themes/generatepress/css/all.min.cssforStyle Handle: generate-styleStyle Handle: generateblocksappears 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 registerStyle Handle: generateblocksthe same asStyle Handle: generate-style?Customer Support
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 ?Documentation: http://docs.generatepress.com/
Adding CSS: http://docs.generatepress.com/article/adding-css/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 );Lead Developer
Hi there,
This is intended as of right now, as
//should work withhttpandhttpswithout any issues.Do you have any reading on why this is a bad idea I can check out?
Thanks!
Documentation: http://docs.generatepress.com/
Adding CSS: http://docs.generatepress.com/article/adding-css/
Ongoing Development: https://generatepress.com/ongoing-developmentIs 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 🙂
Documentation: http://docs.generatepress.com/
Adding CSS: http://docs.generatepress.com/article/adding-css/
Ongoing Development: https://generatepress.com/ongoing-developmentGreat. 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.
Documentation: http://docs.generatepress.com/
Adding CSS: http://docs.generatepress.com/article/adding-css/
Ongoing Development: https://generatepress.com/ongoing-developmentWhat are the side effects if inline embedding is enabled?
It loads the CSS in the
<head>instead of caching it in an external file.Documentation: http://docs.generatepress.com/
Adding CSS: http://docs.generatepress.com/article/adding-css/
Ongoing Development: https://generatepress.com/ongoing-developmentRighto 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.
Documentation: http://docs.generatepress.com/
Adding CSS: http://docs.generatepress.com/article/adding-css/
Ongoing Development: https://generatepress.com/ongoing-developmentDo 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!
Documentation: http://docs.generatepress.com/
Adding CSS: http://docs.generatepress.com/article/adding-css/
Ongoing Development: https://generatepress.com/ongoing-development
- You must be logged in to reply to this topic.