Drupal 6.x and removing JavaScript files via preprocessing

CMS & WordPress
1

I’m using Drupal 6.x and I’m trying to remove some of the JavaScript (JS) files that get generated inside the source if and only if the current page is of a particular content type I designate (for example, if some of the modules I use generate a bazillion JavaScript references inside the markup, well, it would be nice to be able to remove some of those if they’re not needed.) Having this capability would allow me to remove unnecessary overhead.

So in trying to accomplish this, I’ve come up with the following code:

function <THEME NAME>_preprocess_page(&$variables){
        if(arg(2) == '<CONTENT TYPE>' && arg(1) == 'edit' || arg(1) == 'add'){
                $scripts = drupal_add_js();                
                $css = drupal_add_css(); 
                $path = base_path().'sites/all/libraries/syntaxhighlighter_3.0.83/scripts/shCore.js';                
                unset($scripts['module'][$path]);//At this point, this is NULL--so it works here.
 
                $variables['scripts'] = drupal_get_js('header', $scripts);//I  think this is where I'm having problems. The output should not have  that shCore.js file in it, but it does when you view the source...
        } 
        if (isset($variables['node']) && $variables['node']->type != "" && arg(2) != 'edit' && $variables['template_files'][2] != 'page-node-delete') {                
             $variables['template_files'][] = "page-" . $variables['node']->type;        
        }
}

In the above code, I’m trying to remove “shCore.js” from the end-user’s markup stack (this is just an example I was trying to test with; this particular file is output by the “syntaxhighlighting” module). This preprocessing function looks to see what content type the current page is, determines if it’s an “add” or “edit” page, and then based on this, attempts to unset whatever is found within $path. After that, I’m trying to re-insert what’s in the $scripts array back into $variables[‘scripts’] to be output to the end-user.

Unfortunately, that JS file still gets output… I’m just not sure what I’m doing wrong. I think it might have to do with the fact that I’m trying to remove / unset a library-based JS file, but this is pure speculation at this point.

Any insight would be appreciated. Long story, short: I’m just trying to remove unnecessary JS files form the markup stack if and only if they’re not needed.

2

I had to do something “less Drupal” but got it to work regardless: I took the normal output from a standard page and copied the JavaScript sources from the printed markup and pasted all that into my theme file. From that point, I was able to control which files were used. It’s less cohesive / API-ish, but it got the job done. The only drawbacks pertain to caching and whether or not SheetNode needs to add different files to the $scripts variable. Not a big deal in my situation because I don’t see that ever being an issue in the future.

3

The bulk of the overhead is separate requests. However, most of JS is aggregated into a single request. You are really just making more work for yourself by doing this. Not to mention if someone adds something through the UI which expects a JavaScript file which has been removed for the page the site will appear broken. Copy and pasting the source into static file is probably one of the worst things you can when it comes to continued maintenance.

4

Careful, because you better ask me how many JavaScript files are being printed from $scripts that aren’t being used in this theme before assuming that the majority of overhead consists of numerous requests. Don’t get me wrong, I see where you’re coming from and if I need to, I’m sure I can still find a way to cache / compact all the JavaScript (you can’t tell me there’s no way of manually calling some function or whatever the API has to do that in a theme file without using $scripts)…

As for continuity, that’s the last thing I’m worrying about here because I don’t even plan on using this P.O.S. module I did all this for because styling this thing has been a NIGHTMARE. The module I’m speaking of is the Sheetnode module (spreadsheet)… It’s cool for some of the things it can do but it sucks when it comes to full-fledged element control, which is why I had to resort to doing this. But hey, if you know of a better way to not only style the add / edit page of an online Excel form while also providing an efficient way to style the view page without making multiple requests and reducing the JavaScript being printed to only use that which is used, by all means, fill me in. :slight_smile: