replacing prettyphoto, other scripts…

[Israel Curtis]

So I’d prefer to use a different lightbox with standard post galleries, but I’m not seeing a clear way of doing so. I found all the registering going on in /framework/frontend/functions/general.php, so I thought I’d just “dequeue” them, so in the wp_head hook I used:

wp_dequeue_script('prettyphoto');
wp_dequeue_style('prettyphoto');

but this resulted in javascript console errors, as prettyphoto was still being called in themeblvd.js (/framework/frontend/assets/js/themeblvd.js) – and I don’t see any mechanism for overriding these functions. Do I have to override this entire themeblvd.js file? how?

The same problem exists for superfish, roundabout, etc. You have a confusing filter for $themeblvd_framework_scripts, which seems to be only about dependencies – I thought maybe by hooking this filter it would actually change which scripts were activated. That would be far clearer.

Topic

[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

[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…

[Jason Bobich]

Hello Israel,

I don’t think you really need any filters specifically on the enque’ing of javascript files because, as you pointed out in your first post, you’ve got WordPress functions to override or de-activate the scripts. I’m doing my best to keep it in the proper “WordPress way” in order for you to have the ability to manipulate scripts without any specific knowledge of the framework, other than seeing where the scripts are enqueued.

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

Your problem seems pretty straight-forward though. You want to disable these different jQuery plugins, but since they are being utilized within themeblvd.js obviously you’re going to get javascript errors because you can call functions that don’t exist. So in addition to removing the jQuery plugin scripts themselves, you need to actually edit themeblvd.js, as well, which calls all of these plugins.

So, you’d just copy themeblvd.js to your Child theme and register it from there.

function my_scripts() {
    wp_register_script( 'themeblvd', get_stylesheet_directory_uri() . '/themeblvd.js' );
}
add_action( 'wp_enqueue_scripts', 'my_scripts', 9 );

Here’s a more descriptive write-up on this: http://dev.themeblvd.com/tutorial/overriding-a-framework-javascript-file/#example-2

Make sure you’re not hooking anything to “wp_head” though for editing these scripts. Make sure you’re hooking everything to “wp_enqueue_scripts” and using the $priority parameter to determine what comes before or after whatever else. All the javascript files for the theme come in at priority 10, which is the default for the add_action function. So, in that example above I wanted my function to come before the framework so my wp_register_script function comes first. So, I passed in 9 as the priority.

[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.

[Jason Bobich]

I do find this idea intriguing. I’ve started a ticket in our repository and will look into it a little more. Just some thoughts about this. —

The problem is that in order to do this, you wouldn’t be able to have the javascript utilizing these jQuery plugins in themeblvd.js or in any enqueue’d script in quite the same way. So, we’d be effectively somewhat abandoning WordPress’s system for scripts and creating our own system.

You’d need to have this javascript be spit out inline in some function attached to wp_head or something similar to that. Yes, some plugins do this, but I don’t believe this is the right approach. Because when you do this, your javascript code is no longer being enqueue’d within the WordPress system.

Now, contrary to what I said above, an alternate approach that the framework could accomplish what you’re suggesting with still enque’ing a file would be to register locals within the PHP that have true/false booleans for our different plugins and check for them in the themeblvd.js (for example). This is the only way I know to really pass on the functionality of PHP elements through to static javascript files within the limitations of WordPress. However, then when someone wants to edit themeblvd.js in the traditional way, it’s now going to be a little more confusing of a file. Also, we’ll now have a few extra PHP processes happening along with a little bit of extra javascript to register these locals and check against them.

So, I’m not quite sure how to handle what you’re suggesting without causing other issues or making other things more confusing. With a framework like this, there are just so many scripts coming into play, and I’m just trying to keep them as tight to the WordPress-intended system as possible. But I will take a look at what you’re suggesting and see how this could possibly be incorporated within the global config filter and possibly not effect other things.

[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.

[Jason Bobich]

Yeah, definitely some good ideas here to essentially make the scripts included more dynamic with themeblvd.js. I’ll look more into it.

For my reference: https://github.com/themeblvd/Jump-Start/issues/55

[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 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.

[Jason Bobich]

your github link is 404?

Yup, private repository. Can’t give the product away for free. 😉 … I just put the link for my own reference for later if I’m searching through.

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.

The priority 9 I mentioned above was for the javascript files only. The CSS files have a little more going on.

So yeah, if you were looking to accomplish overriding the javascript files and CSS files from one function (which obviously makes sense), you’d just hook it to priority that is before the CSS files, as well. So, in that case 4 would be a good number to use there.

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.

Yeah I see where the confusion is on some of these things in what you’re trying to do. These dependency arrays were added to make life easier in other aspects of including assets, but I guess add an extra step for those doing what you’re trying to do.

I’ve got this in the next update, and also modified how those dependency arrays get built.

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

If you have any thoughts on this, feel free to share, as this change is not officially published just yet.

[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]

wait – has this been here all along?

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

how did I not see that earlier?

[Jason Bobich]

Perfect. I’m assuming you’ll be updating themeblvd.js to accomodate the new global config options?

Yup, this definitely involved some changes to that javascript file. lol so be careful if you did something ridiculous and copied the whole thing to your Child theme to edit, right?

What’s also nice about this is that in the future you could easily add checkboxes in the admin UI to toggle all these…

I don’t think I’d add this directly to Jump Start, but it would definitely allow to easily create a plugin or something to accomplish that, yeah. I will probably create more plugins in the future that add more UI components to Jump Start, but am trying to keep Jump Start kind of lean in that regard by default.

[karlo]

I have been tinkering with that JS file with same thoughts so also went WHAT?? seeing link about removing framework scripts. How stupid of me! but

The functionality outlined in this article was added with Theme Blvd framework v2.2.1.

Made me feel better 🙂 I will stop tinkering with that.

Idea:
Add a “history” or “new and improved” menu entry to doc site? For when big picture stuff is changed or added? Not sure if doing docs is favorite hobby but I value those pages highly so this will just add 1 more point.

[Jason Bobich]

wait – has this been here all along?

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

how did I not see that earlier?

I wrote this article today after our conversation and I made the changes to the working version of the framework (v2.2.1). So don’t worry you didn’t miss it. Framework v2.2.1 doesn’t exist anywhere yet. v2.2.0 is currently what’s in Jump Start 1.0.0.

[Author]

Replies