Make class `container-fluid` on nav filterable

[salcode]

Make class container-fluid on nav filterable in lib/nav.php

@atcraigwatson is doing some awesome work with the customizer and changing some of the nav options.

Typically, my use-case for this theme is a starting point for a fully styled theme. In these cases, there is one prescribed nav to be used as part of the theme and adding customizer options doesn't seem like a good fit for my clients. However, I see a lot of value in this for those who want to have this flexibility (including myself on my own sites). To that end, I'd love to introduce these customizer fields via a plugin and the plugin can then take advantage of the Bootstrap Genesis filter(s) to apply the changes.

[atcraigwatson]

@salcode I think I am understanding your method a little more now. I made a change to page and single post titles by putting them in a full width .jumbotron.

The commit can be seen here Move page and single post title

Are you suggesting that this nature of change, you would have liked to see put in a plugin with features such as choosing which pages, post, archives, etc. that you wish for this functionality to be used on?

For example:

Use the theme customizer to have checkboxes for moving the page title in:

• Pages
• Posts
• Archives
• Etc.

I quite like the sound of that because it prevents theme bloat while allowing quick options if you want to install the plugin.

[salcode]

@atcraigwatson

Firstly, I was checking out your Move page and single post title commit and it looks very cool (to the point, I'm wondering if I want to modify my own site to use this format).

At the same time, I imagine building a custom theme that does not use this same presentation, in which case, I imagine one would have to find these modifications, remove them, and then apply their own modifications. That is what I'd ideally like to avoid.

This is a really long was of saying, yes, I think this would work great in a plugin 😀

I think one thing that is worth considering is how comprehensive a plugin should be. On one extreme, I could imagine having a single plugin that adds all of these options to the Customizer. On the other extreme, I could imagine having a bunch of tiny plugins that do not have any Customizer options (e.g. in regards to the navbar modifications you have in the Customizer, there would be a plugin that when run sets the navbar to inverse (no settings), another plugin when run would make the navbar contained (no settings)) - in this setup the turning on/off of the plugin would be in place of changing settings.

I don't think either approach is necessarily wrong or right (and I can imagine some things existing in both forms). In the context of building themes that are not meant to be modified (e.g. building a custom theme for a specific client), I think the tiny no setting plugins might work best (especially if the plugin is easy to use as a mu-plugin). In the case of running the theme as a Bootstrap theme (or restyled almost entirely through Bootstrap Sass variables), I think the Customizer route would have the most value.

At the end of the day, of course please feel to write whatever kind of code you like 😀

and if adding something like a filter or action to the Bootstrap Genesis core is helpful, I'm definitely open to that.