- This topic has 16 replies, 3 voices, and was last updated 3 years, 6 months ago by Tom.
-
AuthorPosts
-
October 6, 2020 at 3:00 am #1474281vast
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 tohttps://domain.com/wp-content/themes/generatepress/css/all.min.css
forStyle 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 registerStyle Handle: generateblocks
the same asStyle Handle: generate-style
?October 6, 2020 at 5:26 am #1474467DavidStaffCustomer SupportHi 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 ?October 6, 2020 at 11:30 am #1475088vastHi 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 );
October 6, 2020 at 4:05 pm #1475447TomLead DeveloperLead DeveloperHi there,
This is intended as of right now, as
//
should work withhttp
andhttps
without any issues.Do you have any reading on why this is a bad idea I can check out?
Thanks!
October 6, 2020 at 5:15 pm #1475505vastIs 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/
October 7, 2020 at 9:34 am #1476955TomLead DeveloperLead DeveloperThanks for this – appreciate it! Will get it updated in the next version 🙂
October 7, 2020 at 11:40 am #1477175vastGreat. When will the next version be released? In the meanwhile, is there a workaround?
October 7, 2020 at 11:46 am #1477188TomLead DeveloperLead DeveloperNo 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.
October 7, 2020 at 12:29 pm #1477282vastWhat are the side effects if inline embedding is enabled?
October 7, 2020 at 12:34 pm #1477294TomLead DeveloperLead DeveloperIt loads the CSS in the
<head>
instead of caching it in an external file.October 7, 2020 at 1:03 pm #1477351vastRighto 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?
October 7, 2020 at 3:04 pm #1477487TomLead DeveloperLead DeveloperHaving 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.
October 7, 2020 at 3:33 pm #1477511vastDo 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.
October 8, 2020 at 12:37 pm #1479119vastHi Tom,
Can the recommendation be included in the next release?
October 8, 2020 at 2:38 pm #1479266TomLead DeveloperLead DeveloperSomething 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!
-
AuthorPosts
- You must be logged in to reply to this topic.