Using WP_Filesystem to generate dynamic CSS
A few months ago I wrote an article on how to generate dynamic css file which you can use for storing your css options data, among its many other practical uses. There is no shortage of real world examples where dynamic css were used with little to zero impact on security & performance it might do to your site (with correct implementation), but a few doing_it_right() policemen were not very happy with how we’re using certain functions that’s not “WP compliant” in that tutorial. Therefore here’s another instalment of that method, and a small enhancement to top it off.
I’m going to be very brief here and just put the codes which you can just copy and replace the function you used in the previous tutorial, specifically the
You can see that the function is relatively a bit more lengthy now.
On line 9-13, I have added a little check to make sure that your options.css file will be stored independently on a Multisite setup. On a Multisite setup, the CSS file will now be written on individual blog’s uploads folder instead of directly inside your theme’s /css folder. If your theme is not going to be used on a MS, ever, then you can just delete those lines. The only reason why I have them there is that I’m doing most of my client’s development on a multisite setup, so I don’t want the options to be writing off each other if I were to use the same theme on multiple sites.
Line 21-25 is where the good stuff are. Previously, this is where the file_put_contents() were used, and we swapped them with the WP_Filesystem instead to better comply with WP coding standards. If you want to dig a little deeper into what’s going in there, read on.
The first line of that chunk of code initialises the WP_Filesystem_Base class via the WP_Filesystem_Direct subclass (see line 802 of /wp-admin/includes/file.php).
“But Syamil”, I hear you shouting from halfway around the world, “I saw from another tutorial that you need to use the request_filesystem_credentials() and all that before you use WP_Filesystem, while your method do not. How is this safe?” Well, Mr. Incredibly Loud Person, you don’t need a bloody credential if you’re just using the default “direct” method.
If you look at line 891-892 of /wp-admin/includes/file.php, the request_filesystem_credentials() function will simply return a
true if there was no method defined, i.e. it defaults to “direct” method which requires no credentials whatsoever to run. It is only useful if you’re planning to use other methods like FTP or SSH.
Rather than worrying for something that’s not even remotely safer than the widely used file_put_contents() in the first place, you could be worrying about the state of the WordPress community that’s beginning to be infested with a certain breed of elitist who think they’re above everyone else and reserve the right to make fun of others just because they know some PHP codes.
Where were we..
Okay, after the WP_Filesystem function is called, you will now have access to the $wp_filesystem object and its method, which in our specific case is the $wp_filesystem->put_contents method. There are a bunch of other methods in that class, all of which are public so feel free to dig around and innovate some cool & awesome stuff from them.
The last parameter in that put_contents method, $mode (0644) is optional, but you might want to change that to something more secure if you’re ever going to publish your WP username & password on Facebook or Twitter.
A little snippet that you might need if you chose to support multisites is as below:
Just put that where you registers all your theme’s scripts/styles and you’re all good.
So that’s about it from me for now. I hope you found the article useful, and have a great day