• Resolved acsnaterse

    (@acsnaterse)


    Hi there,

    It seems that the CDN URL is not used in the generated/optimized CSS (the CSS file itself is on the CDN URL though). It still uses the main domain’s URL.

    We use KeyCDN together with the CDN Enabler plugin. Also the “Basis CDN URL” option is set to the CDN URL in the Autoptimize settings.

    What could this be?

Viewing 15 replies - 1 through 15 (of 24 total)
  • Plugin Author Optimizing Matters

    (@optimizingmatters)

    Can you share a link to I can have a look?

    Thread Starter acsnaterse

    (@acsnaterse)

    Sure, the site is https://www.dresscode.nl

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Had a quick look, see multiple instances of cdn.dresscode.nl in the Autoptimized CSS, e.g.

    .button--wishlist{background-image:url(https://cdn.dresscode.nl/content/themes/dresscode/assets/css/../images/icon-star.svg)}

    So (from AO’s point of view) all seems OK?

    Thread Starter acsnaterse

    (@acsnaterse)

    Sorry, a bit mor specific: search in the generated CSS for .woff files (or other fonts), and that gives a strange URL: //www.dresscode.nl/content/themes/dresscode/assets/css/../fonts/canela-regular.woff2.

    This probably is, because the URL in the original CSS is relative, but shouldn’t that be replaced as well?

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    fonts are .. special; due to cross-origin limitations those are not CDN’ed automatically. More info (and a solution) in the AO FAQ (see “Why aren’t my fonts put on the CDN as well?”).

    groeten uit Belgi? ??
    frank

    Thread Starter acsnaterse

    (@acsnaterse)

    Ah, I see. Many thanks ??

    Groeten!

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    Graag gedaan ?? Feel free to leave a review of the plugin and support here.

    Thread Starter acsnaterse

    (@acsnaterse)

    Hi, I’m opening this ticket, because it seems that this issue is back, regardless to the fact I have added this filter.

    Any clue what this could be?

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    looks like a regression in 2.4.x @acsnaterse, I’ll try to see if I can reproduce the issue.

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    tested (on my localhost dev computer with 127.0.0.1 as cdn url and the filter returning true) and I can’t reproduce the issue;

    I checked and the font-cdn’ing is part of our non-regression tests (executed by travis-ci.org), which pass as well.

    So this looks like something specific to your environment. Could you, for starters, empty AO’s cache (and page cache if you have one) to allow for the autoptimized CSS to rebuild?

    Thread Starter acsnaterse

    (@acsnaterse)

    Sorry for the late reply, but I haven’t had the time yet to test it. However, it also not seems to work in my local environment. I’ve emptied AO’s cache several times (locally I do not have any other caching mechanisms), but still it doesn’t show the CDN URL in the minified CSS.

    Any clue?
    And what’s the best method to debug this, because, just outputting some debug info in the hide_fontface_and_maybe_cdn() function doesn’t seem to work ??

    Plugin Author Optimizing Matters

    (@optimizingmatters)

    no clue off the top of my head I’m afraid.

    re. debugging; add error_log() statements to

    
        public function hide_fontface_and_maybe_cdn( $code )
        {
            error_log('in hide_fontface_and_maybe_cdn');
            // Proceed only if @font-face declarations exist within $code.
            preg_match_all( self::FONT_FACE_REGEX, $code, $fontfaces );
            if ( isset( $fontfaces[0] ) ) {
                error_log('hide_fontface_and_maybe_cdn: fontfaces found');
                // Check if we need to cdn fonts or not.
                $do_font_cdn = apply_filters( 'autoptimize_filter_css_fonts_cdn', false );
                foreach ( $fontfaces[0] as $full_match ) {
                    // Keep original match so we can search/replace it.
                    $match_search = $full_match;
                    error_log('hide_fontface_and_maybe_cdn: doing '.$full_match);
    
                    // Do font cdn if needed.
                    if ( $do_font_cdn ) {
                        error_log('hide_fontface_and_maybe_cdn: replacing '.$full_match);
                        $full_match = $this->replace_urls( $full_match );
                        error_log('hide_fontface_and_maybe_cdn: replaced with '.$full_match);
    
                    }

    warning; untested code, keep a backup of that file around and be sure to doublecheck!

    but something like that should give you info in our php errorlog.

    hope this helps,
    frank

    Thread Starter acsnaterse

    (@acsnaterse)

    Thanks! Should have known that ??

    But I found the issue. The reason it didn’t work with us, was that we use load WP via composer (kind of a Bedrock setup), so it “lives” in a different folder. For that reason the site_url is /wp.

    And that will not work, when you’re replaceing the URLs on line 318 in autoptimizeeBase.php, since the actual URL from the CSS does not have this /wp in the URL.

    I’ve now fixed this in my install by adding a filter for autoptimize_filter_base_cdnurl and setting the AUTOPTIMIZE_WP_SITE_URL constant in my config to remove thie /wp, but you might want to check on this in your plugin ?? (it did work before ?? ).

    Thanks a lot for the support!

    Plugin Contributor zytzagoo

    (@zytzagoo)

    If possible, could you please try testing with only this filter?

    
    add_filter( 'autoptimize_filter_cdn_magic_path_check', '__return_false' );
    

    The idea being that I’m hoping it could “fix” the issue you appear to be having without having to go through the extra hassles of filtering autoptimize_filter_base_cdnurl and having to change AUTOPTIMIZE_WP_SITE_URL

    If not, could you provide more details on how to exactly replicate your setup (or as close as possible but to still repro reliably)? Thanks.

    Thread Starter acsnaterse

    (@acsnaterse)

    This filter does not work. But maybe that’s because this filter does a check on the CDN URL. And the CDN URL is just fine.

    The issue is this:
    we’re running an install where we install via composer. See https://github.com/ttskch/WordPress.Skeleton for more info.

    With this setup, it is required that the “siteurl” option is appended with /wp in the URL, so:
    – wp_home: https://www.yoursite.com
    – siteurl: https://www.yoursite.com/wp

    And when you do the replace-action, it uses this siteurl. In my case the repace action would look like:
    str_replace( 'https://www.yoursite.com/wp', 'cdn.yoursite.com', '//www.yoursite.com/content/themes/my-theme/assets/css/fonts/canela-regular.eot')

    And that will just result in no replacement at all.

    So, as far as I can see, it can be resolved like that I did now, or you should use get_home_url() in the replacement action.

Viewing 15 replies - 1 through 15 (of 24 total)
  • The topic ‘CDN image does not reflect in generated CSS’ is closed to new replies.