Wordpress Theme cannot find CSS (localhost)

Question

I am using the Wordpress theme from http://html5blank.com, and it works great when I upload it to my servers online, but when I use it locally using a Wordpress Bitnami Stack the theme cannot find the css. In header.php you have:

<!-- css + javascript -->
<?php wp_head(); ?>

but when I view the source of dev site at localhost (after activating the theme) I find the href of the css is empty:

<!-- css + javascript -->
<link rel='stylesheet' id='normalize-css'  href='' media='all' />
<link rel='stylesheet' id='html5blank-css'  href='' media='all' />

Meanwhile it does find the images and icons:

<!-- icons -->
<link href="http://localhost:8080/wordpress/wp-content/themes/html5blank-master/img/icons/favicon.ico" rel="shortcut icon">
<link href="http://localhost:8080/wordpress/wp-content/themes/html5blank-master/img/icons/touch.png" rel="apple-touch-icon-precomposed">

My OS is Ubuntu 12.10. Could this be Bitnami issue, or is this something I could fix so I can work on the website locally? Note that default theme "twentytwelve" works fine in my setup.

UPDATE: I compared and tried both versions 1.2.9 and 1.4.0 (current version) of html5blank theme in my Bitnami Wordpress stack. The functions.php files of both versions are identical as far as the wp_register_style() is concerned, yet version 1.2.9 fills in the links to the css while version 1.4.0 leaves the them empty. Also note that 1.4.0 works perfectly fine in Bitnami install on Windows 7.

I've just tried it (I was planning on giving it a try anyway!) and it works for me locally, under a non-Bitnami install. There doesn't seem to be anything odd about the way the styles are queued (it's done in the function html5blank_styles, starting at line 130 in functions.php, if that's any help.) Is there anything in Bitnami's apache error logs? — Matt Gibson
No, nothing I can find in Bitnami's apache logs. I even restarted the services and it gives the same results. I tried adding the stylesheets myself to the header.php file and the css works perfect that way, but the functions.php method flops every time and leaves the link empty. — pooryay21
Re: your update, are you running the same version of WordPress locally and on the server? I'm wondering if it's something odd like an interaction between a WordPress bug and the exact way the theme is coded, or something... — Matt Gibson
Well, here's something: I can reproduce your issue, using Bitnami on OS X. Exactly the same. — Matt Gibson
Yes, both are running wordpress 3.5.1, the latest and greatest. I have no idea what kind of a bug this is or which piece of software is responsible, but if someone else could re-create it we might find out a little more. — pooryay21

Matt Gibson Matt Gibson · Accepted Answer · 2013-04-15T21:20:25

The problem is an interaction between some code in the theme design and WordPress running on a non-standard port number.

I tracked things down to the function wp_kses_bad_protocol reporting to WordPress's esc_url function (which is used by the style enqueuer, the WP_Styles class in wp-includes/class.wp-styles.php) that the protocol for the stylesheet URL was invalid. esc_url is there to prevent naughty things making it into URLs; one of the checks is to see if there's anything suspicious like the javascript: protocol instead of http:, for example.

The false detection of a problem seems to have been caused by the html5blank theme adding a filter function html5blank_protocol_relative for the filter style_loader_src. This doesn't seem like a bad thing to do, in general (protocol relative basically means replacing http://whatever... with //whatever..., which avoids problems mixing https and http on the same page -- the "protocol relative" URL of //whatever will use https or http as appropriate.)

However, when you're running WordPress on a particular port number, that seems to confuse the bad protocol detection.

Long story short: you may want to report this to the developer of the theme, to let him know that because of this, his theme breaks when running WordPress on a non-standard port, i.e. with a URL like http://localhost:8080/wordpress, rather than http://localhost/wordpress.

In the short term, I'd just comment out these lines:

add_filter('script_loader_src', 'html5blank_protocol_relative'); // Protocol relative URLs for enqueued scripts
add_filter('style_loader_src' , 'html5blank_protocol_relative'); // Protocol relative URLs for enqueued styles

...in the theme's functions.php; that should turn off the protocol relative URL filtering, and your theme should work locally. Unless your live sites use https, they should still work just fine with this change, too, and even if they do use https, you won't be any worse off than with most themes that are out there.

Wordpress Theme cannot find CSS (localhost)

3 Answers