The documention references the ability of editing CSS, compiling into LESS, as well as selective asset loading and such. One thing which pops up in testing is - correct me if I am wrong - compiling taking the full CSS files plus anything additionally loaded.
It's possible (in theory, I haven't figured it out in practice yet) to unload css styles like other assets. That should help a lot, but there's still a fair chance of a boatload of css rules making it into LESS.
Is there a way to process / map / clean up unused styles prior to compiling?
I realise that's only something to be done once everything is really really really ready to deploy. It's just, Google & other tools keep throwing over a thousand unused CSS rules up 😛
Hey J.C,
WP gives you full control over every files loading on a page. Regarding UIkit, Beans gives you control about adding/removing components as you which on a per page basis. When it comes to automating it, I can't think of a non-destructable way of doing it.
Is there a specific script you are looking to remove?
No, I was looking at it more in a sense of post-delivery cleanups. Overall the css is pretty tight, I suppose it was a bit of an "hmmm" moment - seeing how many unused css rules, which translates into how little I've really used 😛
What I could do is probably work out which components I used, and which ones I haven't. That would produce a list of scripts to remove, I suppose.
Absolutely, if you have a list of components you want to remove, I am happy to help and provide you with the snippet to do so 😉
When it comes to cleanup automatically, it would be pretty ressource heavy to scan the page and then process the clean up on every page load. That means the only way would be to do it using caching which would only work for pages which are entirely cachable. I love pushing the bunderies (like really) as long as it is solid and I really can't see that being a stable feature. It could potentially belong caching plugins or services such as cloudflare.
Cheers,
I might just take you up on that list 🙂 Trying to figure out which components are in use, which is something I need to come up with a reusable method for 🙁 But I'll figure that one out in the morning.
As for automated cleanup, I really agree there. Heck, if matters came to a point where there's option panels and god knows what kind of thing to dumb matters down for people like me (wait .. what) you're already in a realm where support cost would far outweigh benefit. At such a point you'd find more business related questions on the table - seen it happen.
But even without that, there is something to be said for keeping things pure and strict. A high key dev can take matters beyond the ceiling, the no-profit helper can still deliver something far beyond the typical themeforest dribble.
And then there's the external dependancies, compability challenges, etc.
Maybe the following sounds a little strange, but beans is the first thing I see where there is enough magic to create an ecosystem. Does that make sense?
Absolutely, if you have a list of components you want to remove, I am happy to help and provide you with the snippet to do so 😉
I think I managed to work out the code, based on the reference documentation.
// Dequeue UIKit Components not in use.
add_action( 'beans_uikit_dequeue_components', 'mk_dequeue_uikit_components', 15 );
function mk_dequeue_uikit_components() {
beans_uikit_dequeue_components( array( 'table, badge, alert, overlay' ) );
}I'm in development mode, but I do wonder now whether there is something else I need to do, because when I use the method to output a list of all loaded components those do still show as present. I think where I'm missing something is linked to the requirement of "This function must be called in the ‘beans_uikit_enqueue_scripts’ action hook" but I'm not sure I see how?
There are two issues in your code. First the action hook is still beans_uikit_enqueue_scripts even when you dequeue components. The array format is incorret, you set all in components in one string which would construct an array with only one key value and instead of keys values for each components (array( 'table, badge, alert, overlay' ) vs array( 'table', 'badge', 'alert', 'overlay' ). So your code should be as such:
// Dequeue UIKit Components not in use.
add_action( 'beans_uikit_enqueue_scripts', 'mk_dequeue_uikit_components' );
function mk_dequeue_uikit_components() {
beans_uikit_dequeue_components( array( 'table', 'badge', 'alert', 'overlay' ) );
}Happy coding,
Hmm, so each on its own within the array, basically. But indeed, this approach does yield the expected result.
So if I understand the approach correctly, first everything comes in (core), and then we can pick out what isn't used and ditch it - in one go but each component individually.
The following might very well be a dumb question, but would it not make sense to build from the ground up rather than first build the house and then decide which rooms to tear out? 🙂 I don't know if I'm making sense, but there's this weird idea in the back of my mind that scoping a project should go hand in hand with knowing what to use where. Which - if this line of thinking is correct - would for beans translate to "do not just load it all, only enqueue per element (for example page / template) what you're going to use"?
Well, this is only really setting/unsetting an array containing all the components before the compiling is processed so it really doesn't do any arm doing so.
The components loaded by default are needed for Beans to work smootly as Beans is intented to work well with all widgets etc. out of the box. If we take the table component as an example, you wouldn't really need it if you are not using the Calendar widget.
If you prefer to build from ground up, you could dequeue everything loaded by default and start building from ground up:
add_action( 'beans_uikit_enqueue_scripts', 'mk_dequeue_uikit_components' );
function mk_dequeue_uikit_components() {
// Unset all the components set by default.
beans_uikit_dequeue_components( true );
beans_uikit_dequeue_components( true, 'add-ons' );
// Enqueue your project components.
beans_uikit_enqueue_components( array( 'base', '...' ) );
}Happy coding,
Cheers!
By the way, I understand - and appreciate - the line of thinking, as well as the approach. It just struck me that once Beans gets used for production (so to speak), it might make more sense to build from the ground up. From a design angle, that function is also very handy. Base design, figuring out how what should work where also provides good testing grounds for making decisions on the very same thing.