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 http://example.com/wp-admin/network/settings.php 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 http://example.com/wp-content/uploads/montezuma/style.css

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 http://example.com/de/wp-admin/themes.php?page=montezuma and change the CSS in the Montezuma settings.
This will create a file like: http://example.com/wp-content/uploads/sites/1/montezuma/style.css

Then log into the next site http://example.com/en/wp-admin/themes.php?page=montezuma and edit the css there as well.
This will create a file like: http://example.com/wp-content/uploads/sites/2/montezuma/style.css

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.