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

    Thread Starter Logman64

    (@logman64)

    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 ??

    Thread Starter Logman64

    (@logman64)

    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)
  • The topic ‘Autoptimize caching old css URLs on site move’ is closed to new replies.