[Resolved] Registered style incomplete URI

Home Forums Support Registered style incomplete URI

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #1474281
    vast

    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?

    #1474467
    David
    Staff
    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 ?

    #1475088
    vast

    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 );
    #1475447
    Tom
    Lead Developer
    Lead Developer

    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!

    #1475505
    vast

    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/

    #1476955
    Tom
    Lead Developer
    Lead Developer

    Thanks for this – appreciate it! Will get it updated in the next version 🙂

    #1477175
    vast

    Great. When will the next version be released? In the meanwhile, is there a workaround?

    #1477188
    Tom
    Lead Developer
    Lead Developer

    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.

    #1477282
    vast

    What are the side effects if inline embedding is enabled?

    #1477294
    Tom
    Lead Developer
    Lead Developer

    It loads the CSS in the <head> instead of caching it in an external file.

    #1477351
    vast

    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?

    #1477487
    Tom
    Lead Developer
    Lead Developer

    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.

    #1477511
    vast

    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.

    #1479119
    vast

    Hi Tom,

    Can the recommendation be included in the next release?

    #1479266
    Tom
    Lead Developer
    Lead Developer

    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!

Viewing 15 posts - 1 through 15 (of 17 total)
  • You must be logged in to reply to this topic.