Support » Plugin: Autoptimize » Autoptimize caching old css URLs on site move

  • Resolved Logman64

    (@logman64)



    Hi Frank,

    Got a weird one here. So today I’ve been testing some internal preview mechanisms we have on the server. So the scenario is someone moves their website to us, they get a preview URL. So I imported a site to test but the CSS was lacking FA icons. Looking at the browser console I saw the errors:

    Redirect from ‘http://wpnex.us/wp-content/themes/herald/assets/fonts/fontawesome-webfont.woff2?v=4.7.0’ to ‘https://wpnex.us/wp-content/themes/herald/assets/fonts/fontawesome-webfont.woff2?v=4.7.0’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://96.125.178.146’ is therefore not allowed access.

    If I deactivate Autoptimize the icons do show. So the theme CSS has the URL hard-coded I guess like:

    url(//wpnex.us/wp-content/themes/herald/assets/css/../fonts/fontawesome-webfont.eot?

    Do you have any idea why they’d show with Autoptimize disabled. If Access-Control-Allow-Origin was the issue surely the console would throw an error with AO disabled?

    Just scratching my head a bit on this one.

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Frank Goossens

    (@futtta)

    hey Logman64;
    The original code is very likely in the theme’s CSS like this

    @font-face{
      font-family: "fontawesome";
      src: url("../fonts/fontawesome-webfont.eot") format("truetype")
    }

    when AO aggregates the theme CSS, the relative path in the font-face’s source would not work, so AO automatically adapts the URL (of fonts and images) by prepending the url with the url to the folder in which the CSS is found (https://wpnex.us/wp-content/themes/herald/assets/css/).

    If AO is not active, the font is requested relative to your domain so there’s no cross-domain-issue.

    Now to fix this I would need to understand how you’re doing the preview; is the entire site installed (and configurable) on your end? Could you change AO config? Could we hook into AO’s API to automagically fix things?

    frank

    Thanks Frank, that’s make a lot of sense. So we’re launching a new WP service and I’m just trying to smooth out the onboarding process and going through a standard account setup, website import and testing phase. As your plugin is so popular it’s super likely we’ll run into this issue if this is a common CSS coding practice. So sure, we’d have full access to configure AO if a client was to request help. Just trying to cover all the bases. 🙂

    Plugin Author Frank Goossens

    (@futtta)

    well, if the live preview is running entirely on your servers and the site url is configured correctly in WordPress -> General, then -after clearing the cache- the full URL to the font-file should point to your servers and it _should_ be smooth sailing 🙂

    The problem is, adding the preview URL to the Site URL setting breaks things. Like not being able to login to the dashboard.

    Plugin Author Frank Goossens

    (@futtta)

    afraid we’re entering unknown territory there logman; I have no idea how your preview works and why setting the site-url would break things, but AO indeed uses the site_url as the basis for a lot of things.

    is your preview some kind of proxy-based solution, or is the site entirely copied/ duplicated on your server(s)? are requests coming in being handled by wordpress being executed on your preview server? because in that case AO is running on preview as well and you could use a filter like autoptimize_css_after_minify to alter the optimized CSS on the fly (replacing “//wpnex.us/wp-content/” by “//96.125.178.146/plesk-site-preview/wpnex.us/96.125.178.146/wp-content/”)?

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.