Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Theme: Controller Overriding and javascript excluding?
I am working a new theme for Vanilla 2. I really like the way Vanilla lets you override files by putting them in directories such as 'views/default.master.php'. I hit a wall, however, when I wanted to NOT import certain JS files such as 'jquery.menu.js'. It appears that this file is included in several controllers. The logical thing to do (I thought) was to put a directory and file in my theme called 'controllers/import.php'. This does not seem to work however.
So my question is: How can I exclude a javascript file from being included, and is it possible to override a controller?
Thank you!
Richard
So my question is: How can I exclude a javascript file from being included, and is it possible to override a controller?
Thank you!
Richard
0
Comments
In two words.
1. Create custom HeadModule class
2. Alter ToString() method:
$Head = array_unique($Head); // removing dup...Now the only trick with the methods I've implemented is that the arguments given to RemoveJsFile have to be identical to the AddJsFile calls in the original files. In one case, there's a '/' before the same script URL on some controllers but not in others, so I had to look for it twice. Another approach might be to look solely for the filename at the end and remove based on that. A still better approach would be to refactor all CSS and JS into themes, or at least to decouple the presentational JS from the functional JS.
Though of course, all this might be moot if you can switch on a presentational mode with cached and minified CSS and JS to speed up browser/server performance. At cache-creation time, you could perhaps first ear-mark the JS from applications, then plugins, then themes, then compile it all together into one file so as to not worry about it until a new app, plugin or theme is installed.
Such caching would also mean that the HeadModule would show one script file rather than a dozen, and again that the HeadModule probably isn't the best location to be removing or adding JS/CSS.
When you consider the idea of putting all your JS into one file for caching purposes, suddenly it makes more sense: look for all the JS in various folders by file name, and then merge them all into one file preserving the usual overrides, such that a blank file would mean adding a blank line (or nothing) to the CSS or JS rather than importing the original file. Perhaps what should normally happen is that each plugin or theme should create its own file nomenclature so they don't conflict each other, e.g. garden.discussion.js and that makes overriding that much more explicit.
The idea of combining all the JS and CSS then makes it easier to contemplate having 20 plugins each with its own CSS or JS, or having view-specific CSS files. You can rest easy knowing that all those tiny files could be combined in to one timestamped cached file when in production and only updated when new themes/plugins/apps are enabled/disabled or on a manual schedule.
If it were simple, I'd do an image sprites technique in a similar way, where all the GIFs, JPGs and PNGs were spliced together into one image, using background-position and width/height to offset and show one image out of the bunch. But it's more complicated than text, with color tables and compression, so it's still best done manually.
The JS and CSS would probably be best separated again by function and style, perhaps to the point where your JS for selectors is kept in a separate file from the API-style JS of functions, just as you can break down CSS that applies to colours from CSS that structures the page to CSS that complements the JS. A stricter approach toward IDs such that every HTML object has a unique ID can really help with some forms of JS also, e.g. CKEditor instances. of textareas.
Perhaps this is something I'll work on in the next month or two. First I want to finish writing more of the website application though, before I focus too much on performance optimization and such. If I come across something useful, though, maybe I'll try my hand at refactoring...