Keep Bootstrap 'core' lean

A lot of what is in 7.x-3.x is not yet documented, no. Partially because it isn't a release yet. There has been a ton of commits since the 7.x-3.0 release. Please see the release notes for 7.x-3.1-beta1.

I find it a little funny that you consider it "over-engineered" as many things are simply trying to bridge the gap between what the Bootstrap framework provides and what Drupal core actually assumes will work with this external framework.

developer centric rather than cater for themer/designer

The whole purpose behind providing a UI to toggle features is to allow a themer/designer to affect different outcomes without having to be a developer and understand how the theme registry and [pre]process functions work. That being said, what you're asking for is actually already being discussed in the related issue. The ability to "turn off" or ignore certain theme hook implementations (bootstrap_preprocess_region(), which should include the separation of [pre]process functions and templates).

I'm not discounting that there are still some pain points. To be quite fair, however, the popularity of this base theme hasn't been fully geared for advanced use cases (customizations) yet. Which is evident by your ability to walk through code and understand what functions are affecting what. There are indeed some things still left to do; specifically around settings and sub-themes that wish to control more of what the base theme "assumes" is desired.

I originally thought that I should close this issue as a dup in favor of the related issue, however I think this one can remain open for now (perhaps as a meta). There are indeed several things that need to happen to make this base theme more lean and developer (advanced themer) friendly. Especially around updating documentation.

In summary, I agree with most of what you're saying. We have discussed this quite in length in the #drupal-bootstrap channel actually.

If you've downloaded the beta, you must have gone to that particular node's download page: 7.x-3.1-beta1 (which lists all the changes). I suggest you re-read the change records, specifically https://www.drupal.org/node/2229627.

"forced layout?"

There is nothing "forced". It has merely moved (hence the duplication).

@ckng - I would be interested in your opinion about creating leaner bootstrap implementations (eg using mothership subtheme) for some simple edge cases.

https://www.drupal.org/node/2231153#comment-9183231

The whole purpose behind providing a UI to toggle features is to allow a themer/designer to affect different outcomes without having to be a developer and understand how the theme registry and [pre]process functions work. That being said, what you're asking for is actually already being discussed in the related issue. The ability to "turn off" or ignore certain theme hook implementations (bootstrap_preprocess_region(), which should include the separation of [pre]process functions and templates).

-- AMEN! Some of us are site builders and do not want to struggle with the complexities of how things work under the hood. Kalatheme is also doing a great job of this (although I couldn't deal with Panopoly requirement.) and Drush wizard is a fantastic approach.

That said, I'm concerned about stability of current releases. If keeping things "Lean" meant getting to a faster release that could be used in production then I'm all for it. Feeling stuck in the dark ages with 1 year old code :). Thanks for this wonderful contribution.

I am hoping to put some serious time in this week (as I am on holiday). I am waiting to do a security release (7.x-3.1), likely on Wednesday, and then will hope to do a full feature release shortly after or by the end of the week (7.x-3.2).

Though this thread is a bit old, I'd throw some of my thoughts.

I am mostly leaning toward Omega and Zen as true base themes though (as anyone else here) there are some things that I like and some that I do not like. Zen has structure that is somewhat hard to override and Omega on the other hand is a bit ignorant to overcoming Drupal unlucky templates and not so shining HTML.

When I was evaluating Bootstrap theme I was looking into how heavy it is (HTML, CSS, JS) and how it fits some of my needs but the CSS/JS alone which weights ~230KB is deal breaker comparing to ~100KB at Omega and Zen (on clean Drupal, just theme without any setting).

I also support having core version and enhanced version or even better some sort of enhancement on needs meaning that it starts as base and light but can be configured to be powerful and all inclusive (albeit bloat) to suit end user needs.

Not having strong idea on that but I am thinking in that direction.

The such separation is done on Arctica - Tundra - Touch Pro trilogy and that seems to me like an interesting idea.

Complexity vs advanced base battle is best seen on Omega 3.x versus Omega 4.x.

I used to have stand that theme should be one size fits all (everything-and-kitchen-sink) then bare base and now I just think that every task and client has their special needs and one should choose accordingly.

Luckily there is a plenty of choice, sadly the choice is always hard and it is even hard to track them in sensible way (idea to myself: put up a web site on that :)

@MacMladen, thanks for the thoughtful review! This certainly does help give a different perspective on things. I do have a few questions though that I think I need help clarifying with because it confuses me a bit from how I view this project:

I am mostly leaning toward Omega and Zen as true base themes

This project has risen to be the #3 top Drupal "theme" on d.o with ~67k installs (at time of writing): https://www.drupal.org/project/usage/bootstrap

Omega and Zen are projects in their own respect and their own use cases. And yes, if people find them more helpful/useful, by all means... they should use them.

However, this base-theme isn't about trying to "squash the other base-themes". I have always said there are use-cases in needing base-themes like Omega and Zen, that will never change.

Given the rate at which this project has grown I would imagine that in the next year or so we will eclipse even Omega (~90k installs) and Zen (~127k) within a year or so after that.

So I am really curious to know what your criteria for a "true" base-theme is.

but the CSS/JS alone which weights ~230KB is deal breaker comparing to ~100KB at Omega and Zen

Where are you getting this stat exactly? Also I think it is a little bit misleading.

Omega/Zen are essentially just bare bones (basically grid only, which is fine), but you still have to build up your actual site (styles) on top of it. How much does that add to the final "cost" of your CSS/JS? From my experience, that initial ~100KB can easily jump sky high once your final "product" is done.

With Bootstrap, I have only ever had to add small bits and pieces that were unique to the site itself (i.e. minimal changes to make things like headers and landing pages, etc). For the most part, we try to re-use the existing components as much as possible through out the site and take advantage of them instead of ignoring them (thus justifying what some may consider the initial "bloat" of Bootstrap's CSS/JS).

The such separation is done on Arctica - Tundra - Touch Pro trilogy and that seems to me like an interesting idea.

Interesting ideas aren't always good ones. Look at their usages:
https://www.drupal.org/project/usage/arctica
https://www.drupal.org/project/usage/tundra
https://www.drupal.org/project/usage/touchpro

In 3 years, they average ~1k +/- installs... this isn't the best indication, but it's a very strong one that it doesn't "resinate well" with developers (DX/UX).

Just because it's a great "idea", doesn't mean it always works in the real world. People are complicated and developers are picky (even more so if you're front-end).

Luckily there is a plenty of choice, sadly the choice is always hard and it is even hard to track them in sensible way (idea to myself: put up a web site on that :)

Yes, it's really just a matter of choice. Many do not want to have to install "multiple projects" just to get something working "out-of-the-box". Yes, for some it's a simple drush command and they can easily install the dependents... for others though, they're not as technically savvy and it takes a few tries to actually get something working. It leaves them with "bad taste" in their mouth about how Drupal "works".

In many regards though, this is really just a balancing act.

As stated above, I have actually talked with @neardark (in IRC, #drupal-bootstrap) in great detail about this topic (and imagine that we will talk even more). I think the best we can hope for (especially if D8 will allow themes to contain discoverable/installable modules) is to offset some this base-theme's underlying "work" into a [sub-]module.

We currently have https://www.drupal.org/project/bootstrap_core (used to be bootstrap_ux) which may help solve some of this.

----

I think though, @ckng's original concern is getting lost in here. From my understanding this issue was more about how Bootstrap currently "overrides" or rather "touches" a lot of theme hooks with no way for a sub-theme to actually revert or prevent it from happening in the first place.

Honestly though, I'm not entirely sure how much of a concern this really is. @ckng, I really will need a real world use-case to justify this level of "separation". So far you're really the only one that has said anything about that issue specifically.

----

@sonicthoughts, as far as the "stable release" problem. That issue has more to do with my availability to actually work on this project, than anything. I have been inundated with client work (that doesn't use this project) for nearly a year now and haven't been able to spend time on this like I would like. I am only human and can't do everything. It would be nice to get others to help push the release blockers.

You guys have done an excellent job on this startertheme, but I tend to agree ...some of the theme settings seem to just add confusion when you are a developer. I think more specifically some that have to do more with theme layout/css.

For example settings like "Container" - Fluid container is such a basic setting to modify in a tpl file I always just end up removing the variables from the tpl files for these settings. Or if I am building a navigation, I'm going to rewrite the tpl files for the Bootstrap layout, rather than adjusting settings under "Bootstrap Settings" -> "Components"-> "Navbar".

It would almost be nice if there were two versions/branches of this theme:

- One that provides Bootstrap/Bootstrap CDN, Drupal .tpls with no bootstrap variables, SASS, and LESS, compiler files, and basic development toggles/features in the UI (For programmers)

- One that provides Bootstrap/Bootstrap CDN, Drupal .tpls with bootstrap variables, SASS, and LESS, compiler files, and basic development toggles/features and a UI for configuring Bootstrap Layout and Look & Feel/variable features (For amateur themers).

It would almost be nice if there were two versions/branches of this theme:

That isn't going to happen.

I would consider myself an "advanced" user (obviously) and hardly ever go into the settings UI. I do almost everything via templates and vars preprocessing. It really is "ok" to simply ignore settings/UI in a workflow. I certainly do when they're not needed for a custom build.

I think people forget that not everyone is a developer. It has been one of the goals of this project to provide something that is fast, easy and a nice UI for novice users. I know that is actually one of the many reasons this base-theme (not startertheme) has become so wildly used/popular over the past 2 years. It's "out-of-the-box" integration of Bootstrap <-> Drupal is easy to configure in categorical settings that match the documentation on http://getbootstrap.com.

----

I'm not sure why people aren't quite getting what I'm saying here, but let me put it into numbers (universal language and all):

So let's just say, hypothetically, that this project has a 1:10 ratio (1 user per 10 installs), that leaves ~6,714 users of various levels of DX. Of which, only 5 of those (a higher DX I am guessing since you're here in the IQ and all) users are represented in this issue here. That is only ~0.07% of the entire user base that this project affects.

It is far easier for us (the "advanced" users) to take something out quickly in a template (10-20min) than the "novice" users to have to actually _learn_ how Drupal theming works in the first place (hours, days, weeks).

----

But again, I think we're getting off tract here. The reason why @ckng opened this issue (AFAICT) is because of the change introduced in #2128129: Provide setting to change sidebar/content widths (which has long since been reverted). He was, rightfully so, concerned with the inability (or rather more difficulty) in managing the template/preprocessing inheritance.

That issue introduced a whole level of complexity around how a page/regions were constructed that made it really easy for settings (in the UI), but also really difficult for overrides (in code) to occur.

Considering that issue is what sparked this one and it has since been reverted, I'm having a really hard time justifying this issue's importance right now (we have bigger fish to fry). For the most part, this base-theme does to stay true to its roots to provide a fast and easy "out-of-the-box" experience with the ability to expand customization as needed. Are there some pain points, sure... but it hardly calls for saying it is "over-engineered" because it doesn't follow one specific use-case/workflow.

I'm not going to close this issue, but I will postpone it for 7.x-4.x so it can be discussed again at a later time.

Thanks for the info markcarver. That is a good way of looking at it. I didn't realize the target market was novice website developers.

They're not necessarily the "target market" per se, but the are a large part of why this project has become very successful over the years and I have to think about that is all.

@markcarver - my $0.02 - as a system builder your approach (especially w/ leveraging bootstrap wrappers like kalatheme) and lot's of settings rather than diving into code is a powerful addition. IMO there is often a disconnect where developer driven initiatives neglect system builders needs and system builders can't easily contribute the code needed for their "target market" so thanks for continuing to support the ui approach. Perhaps that is a driver of the strong activity.

On the flip slide another challenge is the lack of a stable release. System builders are less confident in maintaining a production system using patches and dev releases. Looking at the issue queue I think there is pain that could be resolved by more frequent releases rather than expecting people to manage patches. @markcarver - obviously you have been the rock-star contributor, and understand you need funded development. Any other creative ways to get more attention to release blockers or getting additional maintainers? I can't stress how important this is for system builders.

Sorry if off-topic / bloated-topic but wanted to make sure you heard from supporters too :)

Bootstrap is a very important up-to-date addition to the Drupal eco system since it brings some users in consideration to use Drupal who would simply like to use a very well known HTML/CSS Framework, which they know and which will probably stay long, together with a flexible CMS. To fullfill the awaitings of these users is hard, since the markup between Drupal core and Bootstrap differs a lot. To claim to make Bootstrap more core lean, would make the whole idea to make Bootstrap usable with Drupal kind of obsolete, since Bootstrap is as stabborn as Drupal core itself regarding HTML markup. Who ever tried to make Drupal core play nice with any HTML/CSS Framework out there knows how hard it is to keep the footprint of code small to achieve this. My props go to Mark and all the other maintainers who really worked hard to achieve this.

If I am not mistaken (by reading fastly thru the whole issue) there was already a proposed solution from Mark(?), which I would like to emphasize and agree with here: make some (more) things optional if required, to prevent that subthemers start to override the overrides while they try to get back to "Core-look" on some needed places. Funny thou, one example is this issue, I have just opened one two minutes ago: https://www.drupal.org/node/2522094

@diqidoq, thanks :)

----

@ckng, I forgot to mention in here that since #2447947: Allow dynamic #process and #pre_render hooks for elements has been committed to 7.x-3.x-dev, part of this issue should be a little easier to solve (at least for certain FAPI elements).

There is new documentation in bootstrap.api.php regarding these new dynamic hooks, specifically the following:

 * Implementations of this hook should check to see if the element has a
 * property named #bootstrap_ignore_process and check if it is set to TRUE.
 * If it is, the hook should immediately return with the unaltered element.

and

 * Implementations of this hook should check to see if the element has a
 * property named #bootstrap_ignore_pre_render and check if it is set to TRUE.
 * If it is, the hook should immediately return with the unaltered element.

This would allow you to go in, via something like a form_alter, and set #bootstrap_ignore_process or #bootstrap_ignore_pre_render to FALSE as needed.

This isn't an entirely perfect solution, but it is definitely a start.

I believe this issue can be closed.

There's really not a whole lot more we can do in 7.x without adding a ton of overhead IMO. This is partially due to the procedural hook based nature of the theme system.

In 8.x, this isn't really much of an issue now that this base theme implements a plugin system which very easily allows a sub-theme to literally override whatever the base theme implements.