Israel Curtis (Page 3)

[Israel Curtis]

Very nice! I had resorted to inserting <i id="myid"></i>My Headline in the text box for headlines, giving me something to target. Clunky, but it worked.

However, this solution might solve something else I needed to do, which was group multiple builder elements and wrap in a div so that I could style their background similarly. Think this might do it…

[Israel Curtis]

wait – has this been here all along?

http://dev.themeblvd.com/tutorial/removing-framework-scripts/

how did I not see that earlier?

[Israel Curtis]

Perfect. I’m assuming you’ll be updating themeblvd.js to accomodate the new global config options?
What’s also nice about this is that in the future you could easily add checkboxes in the admin UI to toggle all these…

[Israel Curtis]

I think I found it (though I don’t completely understand it) – it seems your dependency system is re-enqueueing it after I’ve dequeued it (as I noticed it was showing up at the bottom of the list in my source). So by filtering here (and removing prettyphoto from the array), it doesn’t get re-added.

themeblvd_include_styles in general.php:
apply_filters( 'themeblvd_framework_stylesheets', array( 'bootstrap', 'fontawesome', 'prettyphoto', 'themeblvd' ) );

What’s particularly confusing about this filter is you can’t depend on it alone to remove a script/style from the queue, but if you don’t filter it, the same script/style you’re trying to remove will be re-added.

So in the end, I have to both dequeue the prettyphoto styles and scripts, as well as hook the filter. I would suggest modifying your dependency filter routines to fully control loading of these various components. Then a simple filter hook is all that’s needed to modify the output.

[Israel Curtis]

Thanks for your consideration. (your github link is 404?)

on a related note, I’m having some trouble “dequeueing” the styles associated with these JS components (prettyphoto in particular). I see that they are hooked here:
add_action( 'wp_enqueue_scripts', 'themeblvd_include_styles', 5 );
I noticed a minor gotcha in that the priority here is 5, so previous instructions to hook at 9 to override JS should be updated to take this into account. Of course, that would only be in the case that you wanted to replace an enqueued style with your own, like the JS:
wp_enqueue_style( 'prettyphoto', TB_FRAMEWORK_URI . '/frontend/assets/plugins/prettyphoto/css/prettyPhoto.css', array(), '3.1.3' );
In my case, however, I don’t want to replace – I want to simply remove it from the loading queue. This works fine for scripts in the wp_enqueue_scripts hook (at normal priority, as I’m not trying to preempt the existing script):
wp_dequeue_script('prettyphoto');
But it does not work for
wp_dequeue_style('prettyphoto');
And I have no idea why. When I check the source for the rendered page, the JS for pretty photo is gone, but the CSS is still being called…

[Israel Curtis]

I’m not suggesting a proprietary system: apply_filters( 'themeblvd_js_locals', $locals ) is precisely what I had in mind for you to pass the booleans for various script support into themeblvd.js. Then you just add conditional checks within that file for each section of code that deals with a particular feature (prettyphoto, superfish, etc). This is perfectly in keeping with WP standards, and a simple comment line before each section’s conditional test would be sufficient to explain to anyone tinkering under the hood what’s going on.

In fact, just by adding the conditionals to themeblvd.js, even before you modified your global config, you would allow users to disable JS components by passing the localized variables themselves (in combination with manually dequeueing the scripts). This could be a quick intermediate step towards a more comprehensive global config system that would do it all for you – while being fully forward-compatible with those changes once they appeared (as they would be using the same mechanism)

The problem with the current system is that you have hard-coded a bunch of javascript that is not easily disabled without completely replacing the entire script. The principle I’m describing here is no different than “pluggable functions”, which you use generously throughout your php. Just extend the same idea to the javascript components. Otherwise what is required is akin to asking the user to replace the entire /framework/frontend/functions/display.php file just to modify the behavior of the themeblvd_viewport_default() function. Not very update-safe, and prone to errors. IMHO, it’s best for child themes to have their own independent functions that hook, filter, or plug-replace parent theme functionality, rather than taking over parent files completely.

[personal confession] I’m speaking as a previous Thesis power-user, where there’s either a hook, filter, or an options panel to override practically everything without ever touching or replacing the “parent” theme files. This has made it possible for me to safely update the core theme many times without ever worrying about whether my customizations will survive – or whether I’ve managed to find every last bit of new and improved “parent” code to transfer into my custom files.

[Israel Curtis]

While I understand your answer, and yes it will work, this solution seems a bit overkill just to disable one of the many framework scripts. It’s also problematic in terms of future theme/framework updates to have the user clone and overridde the entire themeblvd.js file, just to remove one small function. There’s a lot of other JS code going on in there that a user could accidentally break, and it’s likely to be difficult, when an update comes out, to accurately identify all the new changes and map them to the child theme’s overriding themeblvd.js.

My suggestions about using filters – particularly with the global config “supports” – wasn’t only to target the enqueueing, but also (in a future release) for you to include some conditional logic to check those global configs and to only enqueue and call the functions if the configs are set to true (which they could be by default). This would allow upgrade-proof customization.

[Israel Curtis]

judging by the wonderfully clear documentation here:
http://dev.themeblvd.com/tutorial/managing-framework-features/
maybe expanding the filter for themeblvd_global_config to cover these extra JS assets would be most appropriate…

[Israel Curtis]

You also have a handy filter here:

apply_filters( 'themeblvd_js_locals', $locals )

But it is only being used to pass the theme to prettyphoto. Seems like it would be simple to expand the utility of this filter and allow variables to be set that modified more than just the theme. You could inject completely different parameters for prettyphoto – or have a series of toggles to completely disable functions in themeblvd.js

[Author]

Replies