<p>The fix in this particular case was to modify and save <code>/craft/app/resources/css/craft.css</code> — this revs the timestamp in the query string.</p>

CC BY-SA 3.0
2016-11-14T13:47:12.643Z
2016-11-14T13:47:12.643Z
Andy
<p>Craft will use whatever protocol (http/https) you've defined for your siteURL (either as the <a href="https://craftcms.com/docs/config-settings#siteUrl" rel="nofollow noreferrer">config setting</a>) or in the control panel under Settings->General->Site URL.</p>

<p>It's also possible you've got some <code>.htaccess</code> URL rewrite rules interfering with those specific requests as well.</p>

CC BY-SA 3.0
2016-11-14T12:41:14.690Z
Hi Brad, thanks for the answer (and sorry for my slow response!). We’ve got the site URL set with https, and we’re using Nginx rather than Apache, it isn’t interfering with https requests at all — I can directly access the correct stylesheet at the correct address over SSL.
Andy
CC BY-SA 3.0
2016-11-09T17:58:53.387Z
2016-11-09T17:58:53.387Z
Brad Bell
<p>We’re using Craft over SSL and everything is working fine apart from the admin fonts:</p>

<p><a href="https://i.sstatic.net/ewESj.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ewESj.png" alt="Admin settings with missing fonts"></a></p>

<p>This is due to a mixed content, because craft.css is requesting the fonts from non-ssl URLs:</p>

<p><a href="https://i.sstatic.net/eCImr.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/eCImr.png" alt="Non-ssl URLs"></a></p>

<p>The CSS file requesting these non-ssl assets is:</p>

<p><code>/admin/resources/css/craft.css?d=1478612388</code></p>

<p>When I clear caches, everything works for one page load, then reverts to broken fonts on the next page load. This is because for one page load after clearing caches, the CSS file is requested with a different query string:</p>

<p><code>/admin/resources/css/craft.css?x=EVPBt6yJn</code></p>

<p>This file uses the correct SSL URLs for font files, as does any other variation on the query string. </p>

<p>I’ve tried completely emptying the storage directory.</p>

<p>I can’t find anything in the docs about how Craft generates these CSS files, or the query strings. Can anyone give me any pointers?</p>

<cache><admin><css>
Admin pages request a broken version of the craft.css file
# Admin pages request a broken version of the craft.css file

(Asked by: username_0 on 2016-11-09)

We’re using Craft over SSL and everything is working fine apart from the admin fonts:

[![Admin settings with missing fonts](https://i.sstatic.net/ewESj.png)](https://i.sstatic.net/ewESj.png)

This is due to a mixed content, because craft.css is requesting the fonts from non-ssl URLs:

[![Non-ssl URLs](https://i.sstatic.net/eCImr.png)](https://i.sstatic.net/eCImr.png)

The CSS file requesting these non-ssl assets is:

`/admin/resources/css/craft.css?d=1478612388`

When I clear caches, everything works for one page load, then reverts to broken fonts on the next page load. This is because for one page load after clearing caches, the CSS file is requested with a different query string:

`/admin/resources/css/craft.css?x=EVPBt6yJn`

This file uses the correct SSL URLs for font files, as does any other variation on the query string.

I’ve tried completely emptying the storage directory.

I can’t find anything in the docs about how Craft generates these CSS files, or the query strings. Can anyone give me any pointers?

**Tags:** cache, admin, css


---

## 2 answers

### Answer by username_0 on 2016-11-14. Score: 2

The fix in this particular case was to modify and save `/craft/app/resources/css/craft.css` — this revs the timestamp in the query string.


---

### Answer by username_1 on 2016-11-09. Score: 1

Craft will use whatever protocol (http/https) you've defined for your siteURL (either as the [config setting](https://craftcms.com/docs/config-settings#siteUrl)) or in the control panel under Settings->General->Site URL.

It's also possible you've got some `.htaccess` URL rewrite rules interfering with those specific requests as well.

> **Comments:**
> **username_0**: Hi Brad, thanks for the answer (and sorry for my slow response!). We’ve got the site URL set with https, and we’re using Nginx rather than Apache, it isn’t interfering with https requests at all — I can directly access the correct stylesheet at the correct address over SSL.  

---

