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.
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.