For more technical users or to skip the the background explanation, skip directly to the code.

One of the challenges that comes with building WordPress plugins is supporting the conflicts that ensue with other poorly coded plugins and/or poorly coded themes.

It’s just the nature of the beast.

When it comes to addressing the way a plugin or widget looks on the frontend, I’ve often advised users to modify the plugin’s stylesheet in order to achieve the results they want.

Unfortunately, this is problematic for a number of reasons.

The Problems with Stylesheets

First, I never advise my users to update their theme’s stylesheet – only my plugin’s stylesheet. This gives me at least some levelĀ of managing the problem. If I were to instruct user’s to update the core style.css file, then the changes would be at the mercy of the theme developer.

The second problem is that when the plugin is updated, the changes will be overwritten so anything that they’ve added, removed, or modified will be lost. For many, this causes frustration and clearly negatively impacts their experience with me and my plugin and, by extension, with the visitors to their blog.

Ain't No Body Got Time For That

This ends up with needing to create some type of feature that makes updating stylesheets manageable from the dashboard without being lost during upgrades.

Dynamically Creating Stylesheets

To do this, I’ve begun adding a custom.css file to some of my plugins. The idea of a custom stylesheet is not a new idea. In fact, it’s something that I used to do, then I stopped doing, but have obviously resulted in doing it again out of necessity.

But that whole topic is content for another post.

To dynamically create stylesheets in the context of WordPress plugins, I do the following:

First, I add a hook in my constructor:

/* Setup the activation hook specifically for checking for the custom.css file
 * I'm calling the same function using the activation hook - which is when the user activates the plugin,
 * and during upgrade plugin event. This ensures that the custom.css file can also be managed
 * when the plugin is updated.
 */
register_activation_hook( __FILE__, array( $this, 'activate' ) );
add_action( 'pre_set_site_transient_update_plugins', array( $this, 'activate' ) );

Secondly, I define the function. The code comments should make this clear enough but I’ll discuss it a bit more after the code:

 /**
  * Checks to see if a custom.css file exists. If not, creates it; otherwise, does nothing. This will
  * prevent customizations from being overwritten in future upgrades.
  */
 function activate() {
	 
	 // The path where the custom.css should be stored.
	 $str_custom_path =  dirname( __FILE__ ) . '/css/custom.css';
	 
	 // If the custom.css file doesn't exist, then we create it
	 if( is_writable( $str_custom_path) && ! file_exists( $str_custom_path ) ) {
		 file_put_contents( $str_custom_path, '' );
	 } // end if
	 
 } // end activate

Note Thanks to comments by Geert and Stephen, I’ve added the is_writable checks and also made sure to check for the custom.css file upon plugin upgrade as well as activation.

Simply put, the plugin – upon activation or upgrade – will check to see if a custom stylesheet exists. If not, it will create it; otherwise, it will not. This ensures that users will always have a way to customize the look of their plugin without losing changes during upgrades.

The feature’s easy enough to port from plugin to plugin and it provides a consist way for me to support users. Again, I’ve my own thoughts on custom stylesheets that I’ll discuss in another post.