Sage - uglify all files except one


I’ve added another script that my project depends on to mainfest.json:

"jquery.flexslider.js": {
  "files": [
  "main": true

and copied the file (jquery.flexslider.js) to assets/scripts.
Then when I run gulp commands, everythink is well - the file is processed as expected and enqueued with Wordpress.

However, there are two problems that arise when jquery.flexslider.js is uglified (and only then):

  1. JsHint outputs so many warnings that it aborts all gulp tasks,
  2. Uglified jquery.flexslider.js conflicts with Bootstrap scripts and disables some of Bootstrap JS components.

My question is how I can exclude jquery.flexslider.js from being uglified in the normal Sage workflow?

I’m not sure I can help you regarding not uglifying one script, that said, I think I can help you re-think how you’re using flexslider. And just FYI on the above you don’t want to have main: true on, as I’m guessing it’s not your main script file.

First of all, FlexSlider has a bower.json file, and it looks like their “main” arguments are properly figured out, so you should be calling in FlexSlider with Bower, and then the gulpfile will put it into your code automatically for you. Just install it with bower install FlexSlider --save.

Let me know how that goes for you and check back in.

Also… it’s WordPress - capital P :thumbsup:

Hi @JulienMelissas,

Injecting FlexSlider with Bower would definitely be a way to go. However, it will not work for me.

This is because I’m using a MetaSlider plugin to have sliders published here and there on my site. MetaSlider enqueues FlesSlider’s styles and JS. On one of my pages, however, I couldn’t use a MetaSlider’s shortcode due to its editing limitations. For that page, I had to conditionally enqueue a separate jquery.flexslider.js with:

if (is_singular( 'brand' )) {
    wp_enqueue_script('brands_flexslider_js', asset_path('scripts/jquery.flexslider.js'), ['jquery'], null, true);
    wp_enqueue_style('flexslider_css', asset_path('styles/flexslider.css'), false, null);

And then set up custom FlexSlider for this one page (or rather a post type). I did not have much choice but to enqueue the script in assets.php. All woudl be good if it was not this interference between Bootstrap’s JS and jquery.flexslider.js.

I agree I should remove "main": true from my manifest.json.

Unfortunately, I wouldn’t be able to control the scripts injection conditionally with Bower.

If you have access to the code, can’t you just do do_shortcode('whatever'); on that page? Loading separate versions of the same script is going to bring your load times and the amount your user has to download up. Just a suggestion.

I’ve never heard of FlexSlider interfering with Bootstrap’s JS - are you sure that’s what’s happening?

I’m sorry if you think I’m being annoying. Because I don’t know the answer to your question, and I noticed that there were some things I might do differently, I’m just offering the help I can.


You gave me many valuable suggestions which is much appreciated!

Regarding the slider, sure I could use a shortcode on that one page. This, however, is not the problem with MetaSlider - it’s limited customization of the slider that this plugin allows you to do. I had some more complex markup to implement with the slider on that one page than what I can do with MetaSlider plugin.

Now regarding the interference. FlexSlider as such do not interfere with Bootstrap. Nevertheless, sometimes some unpredictable behaviour might be expected if scripts are uglified and concatenated.

I inspected main.js in the dist folder. It appear that it has Bootstrap’s scripts uglified and injected. Main.js includes also my own invokations of FlexSlider’s functions. jquery.flexslider.js is enqueued separately, but it does not play well :confused: - as I said, it’s the case only when the FlexSlider script is uglified

For the time being, in order to move on with other work I have, I just conditionally enqueued non-uglified FlexSlider’s JS outside the normal Sage workflow. I guess this is just a temporary patch.

Just a few points:

  1. Using "main": true in manifest.json will add in all the Bower dependencies, so you would want to keep that to the actual “main” files. If you had it for flexslider, that’s probably why it was breaking Bootstrap JS, since it was being included twice.
  2. If you want to build JavaScript files but not have them linted (since it’s not your code), change "files" to "vendor", then it will be minified and concatenated but not linted.
  3. You can dequeue plugin scripts, check the codex or watch Ben’s screencast on using gulp.js in Sage.

Hi @kalenjohnson, thank you for your advice. However, I’m not sure what you mean by:

so you would want to keep that to the actual “main” files

Should I after all keep "main": true on this additional, ‘vendor’ JS file or not?

True, I’m a bit confused about what "main": true actually does. I noticed that when I set "main": true and dump the actual file to assets/scripts, it gets processed by gulp and output to dist/scripts (uglified and with source map).

On the other hand, files like, e.g.

"modernizr.js": {
  "bower": ["modernizr"]

are never present in assets/scripts, but live only in dist/scripts.

Should I then declare my dependency like this:

"jquery.flexslider.js": {
  "vendor": ["scripts/jquery.flexslider.js"]

and dump the script file to dist/scripts myself?

I will later need to enqueu this script conditionally for one post type only.

"jquery.flexslider.js": {
  "vendor": ["scripts/jquery.flexslider.js"]


if (is_singular( 'brand' )) {
    wp_enqueue_script('brands_flexslider_js', asset_path('scripts/jquery.flexslider.js'), ['jquery'], null, true);

and then running gulp did the trick.

Thank you a lot guys. This is the most helpful community.


Glad it worked!

To clarify as to what main:true actually does, it’s basically a “catch all” for the files you haven’t specified somewhere else in your manifest. See the docs here.

1 Like

I have some updated instructions available here that help explain the problem you were having:

Would you mind taking a look and give me some feedback on how the explanation could be better?

Hi @austin, thanks a lot for putting effort into providing more detailed instructions in asset-builder’s documentation.

The new instructions make it much clearer now.

However, there are two issues that came to my mind reading the new docs.

First, it would perhaps be useful to provide some advice on where paths.source could be configured for the manifest.json file and what the exact meaning of external set to true is.

Second, I believe that the table showing the paths at the end of the docs should have the headings change to:

“Path Before” => “Path in manifest.json”
“Path After” => “Refers to/Points to”

or something similar

The current wording seems to suggest that the paths are somehow converted or rewritten, which I believe is not the case - only the base (path.source) is appended.

This is just me thinking aloud, feel free to disagree.

Thanks again.