Autoptimize changes and disables icons on siteground staging server

  • Resolved kulakaula

    (@kulakaula)


    8 years, 3 months ago

    Hi,

    I am using Autoptimize together with Async JavaScript and Siteground’s Supercacher.

    Autoptimize changes the back-to-top arrow into a “2” and disables one icon in the top bar of the dashboard, as well as disbles the “x” closing icon of Bloom plugin, all in the Divi theme, in 2 different versions (2.7.10 and latest 3.0.19) – but that happens only in the staging environment of Siteground, not in the public sites from which the staging copies were made.
    When I deactivate Autoptimize, everything goes back to normal again.

    Siteground’s support commented as follows:

    “Indeed this issue is caused by the Autoptimize plugin. I recommend to you bring this to the attention of the developer of the plugin as it could be related to a charset used by the plugin.
    We’ll be more than happy for provide any details from the server if the developer request this during his investigation.”

    The URLs of the problematic staging sites are:
    https://staging3.ingutenwieinschlechtenzeiten.at
    and
    https://staging2.einsichtspsychologie.at

    The URLs of the unproblematic public sites are:
    https://ingutenwieinschlechtenzeiten.at
    and
    https://einsichtspsychologie.at

    On staging3… I have ticked:
    optimize HTML code, optimize JavaScript code, combine inline JS, exclude scripts: seal.js, js/jquery/jquery.js; optimize CSS code, combine inline CSS, exclude CSS files: admin-bar.min.css, dashicons.min.css; save combined CSS/script files as static files;

    There is no CDN being used; Siteground’s Supercacher is active.

    On staging2… the settings are the same with the exception of combine inline CSS not being ticked (for no particlar reason, by the way, as far as I remember, at least).

    For both staging sites:

    Async JavaSript method: async;
    jQuery method: async;
    Enable Autoptimize support method: defer (the reason eludes me if there was any for this choice);

    I would be grateful if you could advise me how to resolve the issue, or perhaps find the time to have a look into the matter yourself.

    Thank you,
    Peter

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

    (@futtta)

    those or font-images and it simply looks like your font-files aren’t loading due to cross-origin concerns:

    18:29:03.147 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.woff. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). 1 (unknown)

    your fonts indeed are being called from the main domain when autoptimizing;
    @font-face{font-family:"ETmodules";src:url(//ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.eot);src:url(//ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.eot?#iefix) format("embedded-opentype"),url(//ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.ttf) format("truetype"),url(//ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.woff) format("woff"),url(//ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.svg#ETmodules)

    which is not default AO behavior, are you doing something special here somehow (hooking into AO’s api or something)?

    frank

    Thread Starter kulakaula

    (@kulakaula)

    Thank you for your answer,

    regarding your question – I don’t do anything special, I would not even know how to!
    Would it be helpful if I sent your reply to Siteground’s support?

    Peter

    Plugin Author Frank Goossens

    (@futtta)

    doubt siteground will be able to help with this specific case, but let me understand what I find weird and why;

    * autoptimize, while aggregating css, normalizes URL it finds inside the css (mainly to ensure a URL that is relative to the original stylesheet still works).
    * this should result in url("core/admin/fonts/modules.woff") becoming url(//staging3.ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.woff) for which autoptimize uses the content_url() function
    * but in your case this does not seem to work, as the resulting CSS has url(//ingutenwieinschlechtenzeiten.at/wp-content/themes/Divi/core/admin/fonts/modules.woff), which is blocked by the browser as originating from a different domain.

    so I don’t know the root cause (maybe the siteground guys&girls do), but these are two workarounds;
    * you could add wp-content/themes/Divi/style.css to the comma-separated CSS optimization exclusion list
    * you could (ask siteground) to adapt your .htaccess to add the correct headers for font-files to be allowed to download from other domains (*ingutenwieinschlechtenzeiten.at)

    the good news; this will not happen on your production instances, as the font-files are those on production there is not cross-origin-request anyway …

    hope this clarifies somehow,
    frank

    Thread Starter kulakaula

    (@kulakaula)

    Thanks a lot,
    I am going to ask Siteground support as you suggested!

    Again, many thanks for your quick response!

    Peter

    Thread Starter kulakaula

    (@kulakaula)

    Hi again, Frank!

    The Siteground support guy asked me to check with you whether either of the changes you suggest would cause issues when the staging site is pushed to the live (public) site?

    What do you think?

    Regards,
    Peter

    Plugin Author Frank Goossens

    (@futtta)

    adding the stylesheet.css to the CSS-exclusion list would be staging-only (it’s a wordpress option and I assume wordpress options are not shared between staging & production)

    the .htaccess change (or other config file when not on apache) would have to be done on production itself, but would not affect any functionality there (it just tells browsers the font-files can be used on other sites).

    did they have any idea of what the root cause might be?

    frank

    Thread Starter kulakaula

    (@kulakaula)

    Hi,

    this is Siteground’s support answer, perhaps it is useful for you:

    ”
    The issue was caused by the fact that access to the desired files was not allowed. As per your developer’s notes, I added the following code to both sites’ .htaccess files and the arrow is now properly shown:

    Code:
    <IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
    # mod_headers, y u no match by Content-Type?!
    <FilesMatch “\.(gif|png|jpe?g|svg|svgz|ico|webp)$”>
    SetEnvIf Origin “:” IS_CORS
    Header set Access-Control-Allow-Origin “*” env=IS_CORS
    </FilesMatch>
    </IfModule>
    </IfModule>
    <IfModule mod_headers.c>
    <FilesMatch “\.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$”>
    Header set Access-Control-Allow-Origin “*”
    </FilesMatch>
    </IfModule>

    The applications are not directly linked but the original URL is actually used for the staging copies and is replaced using mod_substitute with “staging*”.
    ”

    Thanks again for all your help, currently the problem is fixed.
    What actually might happen if the staging sites are pushed live, would have to be seen.

    Regards,
    Peter

    Plugin Author Frank Goossens

    (@futtta)

    great!

    the original URL is actually used for the staging copies and is replaced using mod_substitute with “staging*”

    that indeed is our root cause!

    What actually might happen if the staging sites are pushed live, would have to be seen.

    it will work out of the box ??

    have a nice weekend!
    frank

    Thread Starter kulakaula

    (@kulakaula)

    Same to you!
    Peter

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Autoptimize changes and disables icons on siteground staging server’ is closed to new replies.