Cancel

Jeff Chandler

Plugin Style Settings – Database Or CSS?

Today I wanted to talk about a problem which Justin Tadlock will be covering in more detail at some point in the future and that is, plugins which contain a CSS file to edit their style. Don’t get me wrong, Lester Chen is a great plugin author, but I find it increasingly annoying that after I make the necessary styling changes to his WP-PageNavi plugin so that it blends in with my theme, I overwrite those changes once I upgrade his plugin.

wppolloptions

Based on what I’ve been told, it’s fairly easy to add a plugins stylesheet to your themes CSS file so that this sort of thing doesn’t happen. But, I wanted to raise the question if whether or not plugins should come with their own CSS file for editing or just store the styling information in the database so that end users don’t have to worry about messing around with the CSS in the first place? I’m pretty sure this is how Lester’s WP-Polls plugin works as I can define from within the plugin options page which colors the voting bars should be via hexadecimal color codes.

What are the drawbacks to storing plugin style information in the database versus a CSS file? On the surface, seems like adding the style information right into the plugins options table in the database is A OK to do.

Category:
Tags: , , , ,
15

15 responses to “Plugin Style Settings – Database Or CSS?”

  1. I favor a hybrid approach.

    Provide for color changes and styling within the plugin administration, storing the values in the database. Make this the default functionality. Then also provide the necessary CSS information so if a user wants to write his own CSS they can, and they can add this to their themes CSS.

    If a user chooses to manage his own CSS he can tell the plugin not to output the database driven styles.

    This approach satisfies the power users and developers as well as the novices who need a simple solution.

    I’m not a big fan of the plugin itself having it’s own static CSS file(s). Get to be too much to manage if a bunch of your plugins all have their own CSS files to juggle.

    Create forum topic from comment

  2. @Carl Hancock – I like your approach. With regards to too many static CSS files, I agree which is why I tend to lean towards the styling being saved in the database with the plugin options table rather than purely styled from a CSS file.

    All in all, seems like your hybrid approach would probably work out best, catering to normal and power users.

    Create forum topic from comment

  3. My preferred approach is to provide a means to specify the CSS in the plugin settings along with a “use these styles” option. I also like to provide full documentation on what CSS classes and ID’s the plugin utilises. This gives the end user full control of how the plugin output looks.

    No matter how configurable you make the CSS for your plugin, you’ll never be able to take into account all the layout’s, colour schemes and user preferences out there.

    Default CSS should be basic and should take into account different browser implementations – don’t include browser specific CSS styles.

    Create forum topic from comment

  5. When you start to blur the lines between plugins and themes – it gets that much harder to manage. Child-themes are starting to grow as a viable solution for maintenance / upgrade support on one side, but now the other shoe drops.

    I think a better model could be gleaned from the Maintenance Mode plugin (http://wordpress.org/extend/plugins/maintenance-mode/) which used to suffer from the same “overwrite at update” issue. In the latest versions, it looks for a 503.php file in the current theme directory and uses that. If not, it defaults to the standard files from the plugin.

    So for plugin css styling – you could either look to the current active theme for a [pluginname].css or to reduce the volume of css files req’d have a plugin.css that all plugins look for. This would also improve the upgrade path where you lose customizations b/c they were stored inside the plugin files. You could copy any meaningful styles from the plugin directory css into your “plugins.css”.

    Create forum topic from comment

  6. @JamieO – I use the plugins.css file approach. It would be nice to see some standardization there, but I’m not sure it will/could happen. There are too many opinions out there regarding how to handle CSS in general, and plugin CSS in particular.

    I much prefer configuring plugin CSS in a stand-alone file to trying to configure it in an options page.

    Create forum topic from comment

  7. No matter how configurable you make the CSS for your plugin, you’ll never be able to take into account all the layout’s, colour schemes and user preferences out there.

    @Paul – I agree that there is no universal approach to css. However sites like csszengarden.com prove that if developers are mindful of the markup they produce, there are a surprising amount of layouts which can be re-skinned through CSS alone (or the occasional bit of jQuery magic :)

    I use the plugins.css file approach. It would be nice to see some standardization there, but I’m not sure it will/could happen.

    @chip – What is the plugin that you have wrote which uses that look-for-a-plugin-centric-css-file-in-active-theme approach? The “standardization” that is starting to come together for child themes only came about by people talking about it and – where possible – taking their own steps towards implementing it as you have done. As the community shows interest in various areas, the core development team has done a great job of extending / supporting these visions for the platform.

    Anyone else have experience with plugins (either developing or using) which look to an active theme css file before loading their own?

    Create forum topic from comment

  8. @JamieO –

    What is the plugin that you have wrote which uses that look-for-a-plugin-centric-css-file-in-active-theme approach? The “standardization” that is starting to come together for child themes only came about by people talking about it and – where possible – taking their own steps towards implementing it as you have done. As the community shows interest in various areas, the core development team has done a great job of extending / supporting these visions for the platform.

    I’ve not written any such plugin. Plugin development isn’t really my forte (yet, anyway).

    Rather, if I need to style the display/output of a given plugin, I either read the documentation for the plugin, look for a CSS file in the plugin directory, or just view the rendered page source, to find out what CSS declarations (ID/class) the plugin is making. Then, I add those declarations to my plugins.css file, and style as I see fit.

    I like this method, because it provides maximum control and a future-proof (i.e. upgrade-proof) means of controlling plugin style.

    I’m not sure if or how standardization would come about, but I’d sure support it!

    Create forum topic from comment

  10. For the Multi-level Navigation plugin I simply give users the option to either use their theme to provide the CSS or they can add the CSS directly into their admin panel and that is then dynamically added to a stylesheet within the plugin. So the data is either stored in the users theme or in the database, whichever they choose.

    Or if a theme is designed to work with the plugin, then the plugin detects the presence of a compatible theme and automatically relies on the themes CSS file (although this can be overridden).

    Create forum topic from comment

  11. @Ryan – That sounds like a great solution. It might be a very useful thing for other plugin developers if you could share a tutorial / isolated example plugin of that functionality separate from the Multi-level Navigation. Perhaps the beginnings of a best practice for this challenge of integration.

    Create forum topic from comment

  12. In my JavaScript Pull-Quotes plugin I have a folder of CSS files within the plugin directory. The admin page allows the user to select a style from a drop-down list.

    I’ve also integrated some error checking — for example, if that folder goes missing it falls back to a copy of the “default” stylesheet kept in a different part of the plugin file.

    Finally, if there is a file names “pullquote.css” in the theme directory, that overrides any other setting. Thus: a few options for the point-&-click set, and the ability to completely customize (via theme directory) for the power users. Down the road I may also simply allow the user to specify a styles directory so they can keep the folder that populates the drop-down in a completely different location.

    Create forum topic from comment

  13. @JamieO – Good idea. If I get around to it I might submit a post to WPTavern.com on the matter. I’m not sure if my solution is the best, but it seems to work well enough. The main problem I see is a potential performance hit from using the database route, but during some testing I did this seemed to be a non-issue, I couldn’t measure any reduction in performance.

    Create forum topic from comment

  14. Hi, nice discussion here. Hope it keeps going after my comment.

    After I’ve “googled” everything possible to find out some information about the subject of wordpress and plugins CSS management, this is the only good place I’ve found.

    I’d like to have a clean setup for all the CSS involved in my sites, and I really like the approach from Chip, having a plugin.css file where to store all the necessary styles for the used plugins.

    The only thing is that I don’t see how you could override the original CSS within the plugin itself. For example, I think that WP-Polls generates a scripts right before the tag with the to pull the CSS file within the plugin.

    If so,because of its position, the plugin CSS file will override my plugins.css file, correct?

    I’d really would love to know how can one simply choose to setup a plugins.css file that overrised all the CSS files for all plugins.

    Or maybe I didn’t played around enough with this…

    Create forum topic from comment

  15. @Gianfranco –

    The only thing is that I don’t see how you could override the original CSS within the plugin itself. For example, I think that WP-Polls generates a scripts right before the tag with the to pull the CSS file within the plugin.

    If so,because of its position, the plugin CSS file will override my plugins.css file, correct?

    I’d really would love to know how can one simply choose to setup a plugins.css file that overrised all the CSS files for all plugins.

    Depending on how the plugin implements its style, it can be difficult. Most plugins that I have run into, however, implement their style in a way that can be easily over-ridden by the user. (I don’t know how that’s done, because I’m not a plugin developer. :) )

    In my experience, the plugin developer will just say, “the plugin is wrapped in a container with the .mypluginstyle class” – in which case, you just throw .mypluginstpyle into your plugins.css file, and away you go.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.