Skip to:

custom-styles.css and customising the supplied themes

  • Simon


    I’ve starting to customise both the home and member themes supplied with buddypress, adding my customisations to a file called custom-styles.css that, as Andy pointed out on the mailing list a few weeks back, is imported automatically. Everything works fine but I have some suggestions as to how it could be better implemented.

    Currently custom-styles.css is called by way of an @import at the beginning of style.css. This is problematic for a couple of reasons. By calling the customisations BEFORE the default styles you must add “!important” to all your selectors in custom-styles.css in order to effectivly over-ride the defaults which can be a real nightmare. Also, as pointed out in Ticket 164 the @import reference to custom-styles.css is included in styles.css but the file itself is not included in the theme so a 404 is generated and the error logs get hammered.

    I have implemented what I beleive is a better, cleaner approach:

    style.css contains just two @import calls to default-styles.css and custom-styles.css (in that order). By default the latter can be either commented out or an empty file included with the theme.

    The current content of style.css becomes default-styles.css (minus the @import call to custom-styles.css of course).

    Basically this means that when customising the theme you can choose to add custom styles by over-riding in custom-styles.css or, as I imagine a lot of developers will prefer, completely replace the default styles by commenting out the default-styles.css import line and design from the ground-up (using default-styles.css just for reference).

    This simplified approach should also be easier to manage as new builds are rapidly being released and applied during the development of BuddyPress.

    I’d be interested to here how others have approached managing customisation as the platform has developed.

Viewing 5 replies - 1 through 5 (of 5 total)

  • Simon


    Wow, sorry, that seemed shorter in my head ;-)

    Nice ideas. I think it should change to something similar to this.

    What I had in mind was to use a PHP file with a text/css header that would dynamically include the styles for each component, as long as they were present. That way you don’t need to load any of the groups CSS if you don’t have groups installed. In the same file, the custom-styles.css file can be imported at the bottom (with a PHP check to see if the file exists – stopping the log errors).

    Any thoughts?

    Also – the reason there is no custom-styles.css file present right now is because that file would be overwritten every time a new version is checked out of SVN. A custom-styles-sample.css could be included though, but that wouldn’t make any difference to the logs.



    Ah, good point on the overwrite… don’t want THAT happening! ;-) The php stuff sounds good. I guess the difference is during the development stage that all the plugins tend to be running but thats not always going to be the case once it’s a stable platform.

    Lovin’ your work by the way dude, keep it up ;-)

    Burt Adsit


    I play with the tarski theme and the way Ben does it is to use the wp filter mechanism. He builds up the stylesheets and javascript libs that are used and then calls apply_filters to trigger them. This allows for backend admin selection of any custom css files. (Anything in a specific dir gets backend admin selection). If I want to create a custom style sheet I create it and plunk it into the ../styles dir.

    His entire header.php really doesn’t have any html in it at all. Just a function call. It’s a pain to try and track down one little thing in his theme but it makes it flexible.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘custom-styles.css and customising the supplied themes’ is closed to new replies.
Skip to toolbar