- - - By CrazyStat - - -

26. February 2013

Montezuma WordPress Theme: Solve Inline CSS

Filed under: PHP,Wordpress — Tags: , , , , , — Christopher Kramer @ 18:12

I was recently asked, why CSS changes within admin panel of the Montezuma WordPress Theme were not reflected on the frontend.

I found out that there is an issue with Multisites, but no solution. So I digged into the code to solve the issue. As I think it might be useful for somebody, I post here what I found out.

if you are not interested in technical details, just look for what I highlighted ;-)

Montezuma theme uses inline CSS

If you look at the HTML Source of your site, you will find the whole CSS inline along with this text:

Default CSS served INLINE because wp-content/uploads is not writable.
This will change once wp-content/uploads is writable

So the issue seems to be simple: Just correct permissions. Something like this:

chown www-data:www-data wp-content/uploads

Unfortunately, this was not the issue here. So why does Montezuma fail to place the static CSS file in wp-content/uploads?

Invalid file type

It took me a while to figure out what Montezuma does. In save_css_file() in includes/admin.php, it uploads/stores the theme’s css using wp_upload_bits(). The first problem in the theme is that it does not catch the resulting error while doing this. It should at least print it somehow. In this case, this would result in “Invalid filetype” (in your language).

So wp_upload_bits() calls wp_check_filetype(). This will call get_allowed_mime_types() for a list of allowed mime types. And this looks like this:

function get_allowed_mime_types() {
        return apply_filters( 'upload_mimes', wp_get_mime_types() );

So it calls wp_get_mime_types() for a list of mime types. This will again apply a filter on a list of arrays, which in fact contains css. This is good news, because we want to store a css file…

So one of the filters kicks “css” out. And the short story is that it is upload_mimes. The upload_mimes filter uses a list of allowed extensions that can be edited by the user!

To edit it, open in your browser.  The list of allowed filetypes for uploads is quite at the end of the list of settings. Just add “css” here (space-separated).

I think Montezuma should better overwrite the upload_mimes filter with one that allows css.

If you now save your Montezuma settings, it should successfully create a file

But in a Multisite setup, this is not the end of the story.

Montezuma uses CSS per site (in a Multisite setup)

With a multisite setup, it depends in which site-backend you change the Montezuma css. If you login one site, it will create the css for this site. If you log into another site, it will create the css for this site.

So you need to change the css in the backend of every site.

So let’s assume you have a site “de” and a site “en”. Then go to and change the CSS in the Montezuma settings.
This will create a file like:

Then log into the next site and edit the css there as well.
This will create a file like:

Then the css as you edited it should be used in the frontend.

I guess Montezuma should add an option to use a global css for all sites.

Update: Similar problem: Google Webfont is not loaded

The theme allows you to easily use a google webfont. But it does not load?

The problem is almost the same: It fails writing the .js-file. So go into the network-settings and add “js” to the list of allowed extensions, save the Montezuma settings and it should work.



Try my Open Source PHP visitor analytics script CrazyStat.


  1. Thanks a lot! I have a problem in a blog with wordpress as a network and your solution works just fine! ciao francesco

    Comment by francesco — 29. March 2013 @ 21:21

  2. FYI, the Montezuma CSS will only be inline IF it can’t write to the wp-content/uploads/montezuma folder

    Comment by juggledad — 29. March 2013 @ 22:09

  3. @juggledad: Well, yes. But file system permissions are not enough for it to write there. You also need to add “css” to the list of allowed file types (as I wrote above). And imho this is not that obvious.
    Probably only happens in a multi-site setup.

    Comment by Christopher Kramer — 2. April 2013 @ 20:37

  4. THANK YOU!!! This beautifully solved my issue .

    Comment by Wilma — 25. September 2013 @ 19:33

  5. Thanks, I have a multisite which had the same problem. This fixed it.

    Comment by Daniël Tulp — 17. October 2013 @ 10:33

RSS feed for comments on this post. TrackBack URL

Leave a comment

%d bloggers like this: