Forum Replies Created
May 27, 2013 at 7:46 pm in reply to: giving layout builder elements named anchors #8612
Very nice! I had resorted to inserting
<i id="myid"></i>My Headlinein 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…December 31, 2012 at 12:54 am in reply to: replacing prettyphoto, other scripts… #1916
wait – has this been here all along?
how did I not see that earlier?December 31, 2012 at 12:51 am in reply to: replacing prettyphoto, other scripts… #1915
Perfect. I’m assuming you’ll be updating
themeblvd.jsto 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…December 31, 2012 at 12:02 am in reply to: replacing prettyphoto, other scripts… #1912
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.December 30, 2012 at 11:48 pm in reply to: replacing prettyphoto, other scripts… #1910
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):
But it does not work for
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…December 30, 2012 at 9:43 pm in reply to: replacing prettyphoto, other scripts… #1891
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)
[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.December 30, 2012 at 8:49 pm in reply to: replacing prettyphoto, other scripts… #1881
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.jsfile, 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
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.December 29, 2012 at 4:29 am in reply to: replacing prettyphoto, other scripts… #1855
judging by the wonderfully clear documentation here:
maybe expanding the filter for themeblvd_global_config to cover these extra JS assets would be most appropriate…December 29, 2012 at 4:19 am in reply to: replacing prettyphoto, other scripts… #1854
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