Create a new, non-default core theme that includes and leverages either a rapid prototyping framework like Twitter Bootstrap, or a general front-end framework like Zurb Foundation.

By Audience

  • New to Drupal front end developers: Give an example of an existing front end framework integrating seamlessly with Drupal.
  • Developers who have a project that matches the use case of the chosen framework: Attract them to Drupal, give a base theme to get a quick start with.
  • Front end beginners (including new learners and developers that work primarily on the back end): Provide a theme to learn with using the framework's documentation and resources, or create a prototype or minimally viable product by using the framework's existing components.

Similar projects currently in contrib

Original issue by Sun:



  • Adopt the web tech best practices early, or earlier.


  • The Twitter Bootstrap front-end framework implements the most current, most sensible approaches to produce a consistent, well-crafted, and well-designed web site [output], leveraging HTML5, CSS3, latest ECMA, front-end libraries, and whatnot.
  • Bootstrap already implements the idea of a generic Theme Component Library (see also related core issues).
  • We can learn a lot by simply trying to integrate Bootstrap as a simple theme for Drupal. Don't re-invent the wheel.
  • The focus must be on "simple", because the Bootstrap framework is overly nitpicky about proper/compatible markup. The underlying case: Make our markup better.

Proposed solution

  1. Add a theme to Drupal core that is based on Bootstrap.

    Primary goal: Leverage and expose Bootstrap's components/features in Drupal, ideally with close to zero theme function overrides.

    There's absolutely nothing wrong with having it look and feel like the Bootstrap base theme experience, which is visible on countless of project websites. Bear in mind, the goal is not fancy — the goal is modern markup and web standards.

Related issues

Prior art


  1. 2012-10-15 Working theme/implementation + ready patch for Drupal core (requires license blocker to be resolved)

    Why this early? The primary purpose of this challenge is to identify markup, output, and shortcomings in Drupal that should be improved. Stuff like dropbuttons (quite) potentially need to be re-implemented to use proper markup. Ditto for other stuff like tabs, actions, etc. Changing/improved that stuff can be considered as "feature", so any improvements need to happen before feature freeze.

  2. 2012-12-01 Feature freeze.
#128 tweme.zip110.41 KBtonystar
Members fund testing for the Drupal project. Drupal Association Learn more


bensnyder’s picture

Sun - thanks for pushing this. Would anyone like to team up with me? We would need to do this in tandem with the work being done to integrate Twig.

bensnyder’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

I've added Prior art and also Deadlines to the issue summary. The provided reasoning hopefully explains why I asked for a time-frame of 1-2 weeks (given that 8 weeks remain in total).

sun’s picture

Issue summary: View changes

Updated issue summary.

RobLoach’s picture

This would be absolutely huge for Drupal.

bensnyder’s picture

The theme ecosystem would EXPLODE if TB was available in core.

bensnyder’s picture

Issue summary: View changes

Replaced an impolite word.

sun’s picture

I've clarified the Proposed solution.

webchick’s picture

Isn't this a no-go because of the license? :( AFAIK Apache Public License and GPL v2 are not compatible. http://www.gnu.org/licenses/license-list.html#apache2

EDIT: Oh, ok. It looks like according to https://github.com/twitter/bootstrap/issues/2054#issuecomment-9090952 that this has been re-opened for discussion as of an hour ago. Yay! Still, trying to get all contributors to Twitter Bootstrap to sign a CLA in time for our feature freeze sounds ... not likely to happen. :(

sun’s picture

@webchick: See issue summary.

cweagans’s picture

@sun, are you thinking that this should be a public-facing theme? Or an admin theme?

sun’s picture

@cweagans: In light of the primary purpose and goals, I don't really care. But yeah, I thought of a public-facing theme. Less special, less use-case specific. Just Drupal on Bootstrap steroids. (whereas "just" is relative and involves tons of work.)

cweagans’s picture

@bensnyder, I'd love to work with you on this. Jump on IRC at some point tonight or tomorrow and we can chat about it :)

A public-facing theme seems to be, in my mind, a better demonstration of how bootstrap is likely to be used, though if we're already changing up a bunch of markup to work nicely with Bootstrap, an admin theme wouldn't be too difficult to do.

bensnyder’s picture

@cweagans sweet. would probably be easier to plan over skype? hit me up @ benpsnyder

Et al - definitely start with a public-facing theme. PHPTemplate? Twig? Will the work being done on Twig hold us up?

c4rl’s picture

I am currently opposed to this proposition. Reasons follow.

1. It is problematic in principle that the stated Goal of this issue is very vague, and the stated Solution is very specific.

2. The Details listed are simply some nice-to-haves that Bootstrap provides. I don't see any real problems listed that integrating TB would solve. The justifications above could be applied to other front-end frameworks; I could imagine these justifications being used similarly to propose adding 960 to core a few years ago when 960 became popular.

3. There are enough problems with the existing Drupal theme system having *too much* in it that I am opposed to *adding* anything new that doesn't solve an existing issue until we have taken care of the existing issues of consistency and consolidation. Until things listed in #1788918: [GTD] [META] Prepare for Twig main engine core inclusion until December 1 are in the clear, it seems unwise to focus efforts on putting *more* into core theme API at this juncture especially something "overly nitpicky about proper/compatible markup." It's clear that having too much in the theme API has caused problems and frustration.

4. The existing projects on d.o that utilize TB have, at most, an install base around 2000 sites in aggregate, which is not nearly ubiquitous enough as to be a clear choice to include into core (compared to, for example, CCK or Views).

cweagans’s picture

Well, if nothing else, it will help us get a generic component library into core. If the markup for those components happens to be consistent with the markup for Twitter Bootstrap, then I see that as a good thing.

sign’s picture

Right now I am against this. Bootstrap is evolving very quickly and the version integrated into D8 will be already outdated when released I guess. Which might bring in frustration, for people who are used to twitter bootstrap and fully leveraging it (including JS functionality - not sure @sun if you want to add these too). So they might be thinking, oh, Drupal has twitter bootstrap, but then they will be like :-O and start from scratch.

But I am all up for standardizing the output. In fact we can take the bootstrap as an example, but I wouldn't market it as that Twitter Bootstrap has been integrated into Drupal. Willing to help with this. Doing this every day unfortunately on clients sites.

fubhy’s picture

Cleaning up and standardizing the output is always a very noble undertaking. Applying a widely accepted, external library in a theme and thereby identifying the bottlenecks in the current template and theme function implementations is also a good idea. However, building a core theme on top of something that is evolving as fast as Twitter Bootstrap is not. Additionaly I would hate to see a Twitter Bootstrap theme in core considering that there are much cleaner and lightweight solutions out there that just don't get that much attention as Bootstrap does because, well, they don't come from twitter. Take, for example, ZURB Foundation. While I usually don't use such libraries (or, if I do, just parts of them) my first resource would be Foundation - Not Bootstrap. First of all, it's built with SASS, secondly as mentioned before, it's much cleaner and lightweight. So you see, now we are arguing which framework is better - And, whichever framework we choose, people will complain.

So... Building a a theme on top of an external, highly optimized and best-practices Framework and then using that as a tool to identify the wtf's in the current templates/theme functions/css/js is a great idea. Keeping that in core afterwards is not :) (imo).

kpa’s picture

Hi people,

Have a look at www.ja.net. I implemented this earlier this year - and whilst it's not a perfect implementation, there are a number of hooks, some from http://drupal.org/sandbox/rerooting/1429486 which add necessary markup to render the elements in the correct 'twitter bootstrap' way.

I'm in the process of cleaning it up for another project at the moment, hopefully I can sandbox it by the end of the week if anyone's interested.

Points of note:
- It relies on Omega as well, which we'd want to get rid of. Given this - and how strongly the 960gs is set up, I've made some overrides for 'TwBs responsiveness', but it still largely uses the 960gs.
- My CSS is HUGE - I'm in the process of tidying this up as well.

I'd be interested in working on this if it becomes a viable option.

LewisNyman’s picture

This feels like a good exercise in exposing how difficult and painful our theming system is, but we already know that right?

  1. These frameworks are prototyping frameworks, they allow you to get something out of the box quickly, if they are good. They can also be a good resource for best practices. They should not and never will be a replacement for a 'designed solution'.
  2. These frameworks are very html dependant and picky, which means you'll spend all your time in the theming layer instead of in the front end, whether this is a good or bad thing I don't know, personally I think spending a long amount of time changing .tabs to .nav-tabs is crazy.

Having said that, the use case for a distribution of Drupal aimed at rapid prototyping and a minimum viable product is huge. I've been singing the praises of Drupal for tech start ups in London and the ability to create decent functionality and UI without writing code would be huge.


timmillwood’s picture

I think bootstrap is a great framework and with the creator moving to github (http://markdotto.com/2012/09/30/github-bound/), Twitter are moving bootstrap into it's own organisation on github.

This means that bootstrap becomes more of an independent open source project rather than a Twitter project.

I would love to see it in core.

bensnyder’s picture

@fubhy - /methinks me loves ZURB Foundation. Wow. Hadn't seen the recent 3.x release. They did a great job with that... and yes, much cleaner than TB... and... with SASS. (I hate having to use sass-twitter-bootstrap all the time.) Hmm.

/meneeds to think about this some more.

@lewisnyman spot on.

criz’s picture

I am not sure. Of course it would be awesome when Drupal would be shipping with a Twitter Bootstrap theme, on the other hand I see the issues like some of you:
- Up-2-dateness and core updating process: For example Bootstrap 2.0 needs jQuery 1.7+, as a consequence the twitter_bootstrap d7 theme is not working without jquery_update or similar. If Drupal core is not even able to ship the latest jQuery, I don't see a way for an up-2-date Bootstrap Framework.
- Though I like Twitter Bootstrap and it is probably one of the most adopted frameworks worldwide (e.g. also Joomla 3.0 now uses Twitter Bootstrap for the backend), it is right that there are some other frameworks that could be considered too.
- And yes, standardizing html and theme components is the way to go. But Twitter Bootstrap uses it's own markup and classes. Good (and similar) core theme components would help to adopt to Twitter Bootstrap markup I guess, but a lot of theming functions and overwrites would be needed anyway. See for example what d7 twitter_bootstrap theme is doing: http://drupalcode.org/project/twitter_bootstrap.git/tree/6f1ca9f41d04483...

In my opinion Drupal core should first try to make the work with state-of-the-art markup frameworks most convenient as possible. So that contributed base themes like http://drupal.org/project/twitter_bootstrap or http://drupal.org/sandbox/ishmaelsanchez/1332338 can provide good solutions and people can use it without jQuery issues or something like this.

But I fully agree with the idea to have a great Twitter Bootstrap Drupal 8 theme available, as early as possible. Only that I don't know if it should be in core (under this conditions), though it would be a great marketing gag when Drupal 8 would ship with a Twitter Bootstrap theme... ;)

On the other hand: Having a always most current Twitter Bootstrap theme in Drupal core, and with just the markup needed by the framework (without all the maybe-somebody-needs-it-sometimes-somehow-classes and a most lean html output as possible), THIS WOULD BE A DREAM! ... and would be a great best-practise showcase for other framework adoptions in contrib.

c4rl’s picture

Priority: Major » Normal

I'm changing the priority to Normal since it seems more appropriate for this issue.

Here's another thought I had about this, which is not a criticism of Bootstrap specifically, but just a thought on core themes in general. Most sites do not use a core theme, nor a singular contrib theme, because the diversity of design need is so wide. As a result of this, we ended up with several out-of-date themes in D6 core that had to be removed simply because Drupal had grown up and the vast majority of design attention was being put toward custom work in Drupal sites.

The theme layer differs considerably from modules in this way, in that the labor of a particular site's theme does not translate to other projects as flexibly as, say, fixing bugs that affect the modules of that particular site. And so, core modules improve and change because their improvement translates across all Drupal sites whereas core themes atrophy simply because people aren't using them.

Whilst I agree the intention of having a framework is a nice idea, we have to consider the practicality of this, especially given the timeline. I would like to see more effort put toward a solid contrib Bootstrap theme before further considering core inclusion.

fubhy’s picture

Okay.. So we got Stark, Bartik and Seven in core.

Stark being a really cool theme for development, testing, etc. because, well, it's basically empty.
Seven being the default admin theme because it's simple, although not as simple as Stark, optimized to work well with all the admin pages, looks good in the overlay and in general simply provides quite a nice backend look&feel.
Bartik being the arguably better-looking alternative to Stark basically when quickly setting up a website for a demo or for a simple personal blog.

We have to ask ourselves: How does a that twitter bootstrap(?) / foundation(?) / any other prototype based theme fit into core.

From my gut feeling I would say: Only as a replacement for Bartik. I am not sure if there is an issue for that yet, but giving D8 a new out-of-the-box face would not be a bad idea after all if you ask me. That way we would visually distinguish standard profile installs D7 vs. D8. At the same time, while implementing a new theme from scratch we would be able to dummy-test and validate our latest theming changes in D8 with a close look on the best practices shown by those prototyping frameworks.

Let's not put MORE themes in core. Maybe replace Bartik / Move Bartik back to contrib and put that new theme in? After all it's a new major version!

Really think about how much sense bootstrap actually makes. I think there are better alternatives...

Let's give D8 theming a test-spin and fix the issues as we go.

dcrocks’s picture

Really don't think this should get into core. There are alternative libraries, there is no actual theme being proposed to judge on its wow factor, and there is no evaluation as to whether drupal should choose ANY theme library as best practice for its users. Is this so great that drupal should lock itself into this library? Bartik was chosen from amongst alternatives for drupal 7. I don't know if there is a project to choose a best and new base theme for drupal 8. I think this should all be in contrib. It already is for drupal 7.
I know you wouldn't be able to get such a library into core after feature freeze. Maybe this should be redone as a request to add theme builder tool sets to core before feature freeze.

dcrocks’s picture

Actually, there is an issue, #1087784: Add new theme to Drupal 8.1.x or another minor version, but it seems dormant.

Snugug’s picture

I have very strong concerns with this proposal starting with the general premise and going straight through implementation. This is going to be a long post, so be prepared.

First, let start with the stated goal of this proposal: about the web tech best practices early, or earlier. This is something I actually agree with, but this goal is very very broad. What are we actually talking about? There are backend best practices, frontend best practices, JS best practices, CSS best practices. Best practices for responsive web design, best practices for static web development, best practices for web apps, best practices for brochure sites. What are we talking about? Based on the proposed solution, I assume the best practices you're concerned with are responsive web design and reusable CSS. If this is indeed the case, let me be the first to tell you that Bootstrap is not a best practice in Front End, it is a front end framework for back end developers. As a Drupal community, and as a front end community, we have access to great front end developers to deliver a properly best practice solution as opposed to using the Fad-ish Bootstrap. Please don't take this as a "Not Invented Here" thing, Bootstrap really doesn't implement best practices and we can do better.

Second, details. As goes the saying, the devil is in the details, and Bootstrap is Satan himself (excuse the hyperbole). While the first bullet claims that Bootstrap implements "the most current, most sensible approaches to produce a consistent, well-crafted, and well-designed web site [output], leveraging HTML5, CSS3, latest ECMA, front-end libraries, and whatnot", please allow me to explain how that is, in fact, wrong. I'm going to be going through the Bootstrap site heading by heading to explain why this statement is wrong.

Let's start with Bootstrap Scaffolding. The very very first thing that Bootstrap explains, in the very first example, is how to enable font size Less mixins. I'm going to get back to Less, but the fact that Bootstrap in its core is written in it should present a giant warning to any attempt to bring it into Core. Going down Scaffolding, they use Normalize, which I agree is the better way to go, but Reset vs Normalize is a design decision and as such isn't a best practice per se. Next, we move onto their grid. Their basic grid is a static grid, which is in fact not a best practice, is available only at 12 columns, which is again not a best practice, in fact it's a bad practice to constrain our designs to a grid not created for our design. The grids are static grids instead of fluid grids (which actually is a best practice) and below 767px (aka a Desktop first approach to device breakpoints, both of which have been rejected as best practices in favor of Mobile First and content based breakpoints). The grid system is a class based grid system, so all of the work we're doing to clean up the class system is going to go for not. In fact, class based grid systems are very rapidly being replaced by semantic, pure CSS grid systems which allow you to change your actual column count at different sizes without messing with your classes (this is the emerging best practice. See Zen Grids, Susy, or Singularity). And their entire default grid system is built in PX, not even EMs, which is the furthest thing from a modern bet practice. Next, let's take a look at their Responsive grid. Bootstrap itself is designed to not be responsive by default, meaning the default mentality going into Bootstrap is that of a static website. This is actually the opposite of a best practice. If you take a look at what they consider supported devices, they are all Desktop first, device based (and wrong at that) media queries with static grid layouts at 768px and up, which is, again, all sorts of not best practice. Oh, and they also set background color of body to white, which is neither a best or worst practice, just a strange one, and yet one more piece of CSS we need to override.

Next, let's take a look at Typography. The key to good typography is setting what's right for your font size, and requires lots of detail work. Their default is 14px/20px size/line height. Sizing fonts in PX is actually a worst practice; for accessibility, fonts should always be set in EMs. The rest of their typographic decisions are fairly basic and we don't need Bootstrap to handle. When we get to tables, while their table styles are interesting, they are not responsive and frankly, are a design decision. We've got lots and lots of tables in Drupal, we don't need use their designs. Their color coded rows for paragraphs and tables are all design decisions that we don't need bootstrap to deal with (and we deal with in Drupal already). Possibly the most compelling thing from Typography that Bootstrap offers to us is their Form stuff, which while mostly good, do make many design decisions for us that I'm not sure we want in Drupal core. This is especially true for their default buttons, which are all design decisions, some of which many of our designers won't agree with, which now is again even more CSS we need to override (this is going to be a reoccurring theme if the idea of adding Bootstrap is to add a Component Library). It's also hard to determine just how well these will work responsively because their site doesn't use fluid grids that we can really test using best practices with. When it comes to the iconography they use, the way it's implemented is totally inaccessible for many of their examples, and in fact doesn't even use best practices for font icons. Take a look at Symbolset for the current best practice icon font.

Next we move over to Components. Starting with their drop down menu, the basic one is, again, inaccessible with a tab index of -1. Their JS for their menus is not touch friendly, which makes it fairly useless for touch based mobile devices (again, not a best practice) and in fact, their examples for button drop down menus simply do not work on touch devices. The targets for their combo buttons are too small for touch devices. Most of what's on their site isn't optimized (or really usable) on Touch, a combination of JS and CSS issues. Skipping down a bit, their pagination isn't responsive, nor is their hero unit, search stuff, page header, or really most of their components (because of this, none of these components are things we should use). Their clearfix is fine though.

Now on to Javascript. First, modals not only don't work for small screen, their modal just straight is broken on iOS. Hell, it totally breaks if you're not on a landscape orientation! I can't begin to believe this is acceptable for a Drupal core theme. Likewise, their JS drop downs don't work well on touch. Their tooltips don't work for Touch, requiring you to actually click the links/item, a bad practice and broken practice. Popovers, too, have no concept of screen real-estate. Their carousel doesn't respond very well and doesn't have touch interactions. If you are looking for a good example of a proper, accessible, and progressively enhanced carousel, look at Flexslider.

So with all of these issues, I hope it's fairly clear Bootstrap is in fact not the modern awesome framework that it's described in the first bullet point. Let's now talk about bullet point 2, the Theme Component Library that Jacine has proposed. I think the Bootstrap solution misses the point that Jacine was trying to make; we need less css in Core and more standard HTML components with easy to hook into classes. Unfortunately, much of her demo is incomplete, so without her directly chiming in I can't speak to her full intents, but from conversations I've had with her and other front ends in Drupal, the real issue we have is unpredictable, non standard HTML output which is then hard to theme, not our inherit ability to actually theme something. To this extent, while I would really love to see a standard component library in Drupal, many many more of our complaints about the frontend, and in fact seemingly many of Jacine's complaints from that blog, are going to get remedied with the move to Twig. This is where resources should be going, to make sure that system rocks. If we combine that with a SMACSS approach to our core CSS and our CSS frontend best practices many of the CSS issues we hate in Drupal will potentially go away.

Now, a word on the Less CSS preprocessor and the implicit acceptance of it by introducing Twitter Bootstrap. In the world of CSS Preprocessors and the wider front end community, of the three major CSS Preprocessors, the majority of the top front end developers uses Sass, not Less, and in the Drupal community the preferred CSS Preprocessor is Sass as well. The implicit nod to Less that implementing Bootstrap runs counter to what is being used by the Drupal frontend community and the wider frontend community. We've actually had this discussion before over at Add a CSS Preprocessor to Core to no avail. Please take note though of the themers (beside myself) who prefer Sass: Jacine, John, Morten, Sebastian, Richard, Mason, Chris Ruppel, Lewis Nyman to name a few. After looking over all of the options, the current upgrade to D7 for d.o is being written in Sass. This is a Drupal best practice and rapidly becoming a frontend best practice, with people like Chris Coyier and Paul Irish championing it as their preferred CSS Preprocessor. This is something that should be considered whenever talking about a front end framework, and if we do decide to go with any front end framework that uses a CSS Preprocessor, we should only be looking at ones that are native to Sass and Compass.

1713 words later, I think I'm done. Hopefully this helps.

JacobSingh’s picture

Snugug's technical critique not-withstanding, I see a few really compelling reasons to make core's Admin theme based on bootstrap.

  • It looks awesome. Shut up, just because it is everywhere doesn't mean it isn't awesome.
  • Everything is built in. Every control you can think of, and there is a community adding to it.
  • It will be really quick to implement, much faster than starting from scratch. Yes it will. 2 weeks from psd to completion my ass.
  • Someone might think we are running node.js with super thrusters or Python/Twisted v2190 instead of crusty old PHP.

Okay, cons..

  • It won't be sprinkled in the newest pixie dust of standards (fad) compliance since it is kinda established already
  • Pulling in new updates may suck a little.
  • It's opinionated and a little limiting.

The last con is why I think it's *GREAT* for the default admin theme, but terrible for anything else.

k, 2c provided.
Anyone who is willing to put in work can TOTALLY DISREGARD my comment since I am not.

effulgentsia’s picture

I don't really know enough about the pros and cons of different front-end frameworks to comment meaningfully on whether the problems of adding Twitter bootstrap to core would outweigh the benefits. I just want to suggest two things though:

- Twig should not factor into the discussion. I think the problem space is entirely different, and a theme coded in PHPTemplate now can be converted to Twig later, after feature freeze, if basic Twig implementations land in core before then. Meanwhile, a problem space that this effort (or any type of generic component library) would hit on is #1484720: [Meta] Reduce the number of theme functions/templates, something the Twig effort would also love to see happen, but has not yet worked on in depth, so these two efforts would be each valuable on their own, compatible with each other, and should be done completely in parallel.

- If this isn't done in core, but rather as a sandbox / to-be-contrib theme, is it still possible to do it now, so that any improvements to the theme/render system figured out by the effort could still be submitted as standalone patches to core while there's still time?

fubhy’s picture

Thanks for the detailed review of Twitter Bootstrap @Snugug, you nailed it... very informative.

Please note everyone: After reading all the previous comments once more I think we can safely say that noone is opposed to reviving #1087784: Add new theme to Drupal 8.1.x or another minor version. Considering @Snugug's Front-end expertise and his detailed review of Twitter Bootstrap as well as the comments from various other renown themers (comments from mortendk on Twitter, etc.). We can safely say that we can actually do better than Twitter Bootstrap (no offense).

So I would still vote +1 for creating a new theme for D8 as a joint effort from everyone involved with theming. But let's use the expertise that we have in our community to actually properly investigate how such a theme should look instead of blindly going for a random framework just because it's currently 'hip'. :)

RobLoach’s picture

The biggest benefit Drupal would get out of a framework like Bootstrap/Foundation is the common markup and CSS base. The out-of-the-box responsive design makes its adoption attractive to the Mobile Initiative.

In the world of CSS Preprocessors and the wider front end community, of the three major CSS Preprocessors, the majority of the top front end developers uses Sass, not Less, and in the Drupal community the preferred CSS Preprocessor is Sass as well.

If you're looking for a LESS compiler for PHP, there's LESSPHP, which also integrates quite nicely with Assetic. Of course, we won't need to compile it ourselves as Bootstrap ships compiled copies of it for us. Leafo also has a SCSS compiler writen in PHP too, so either LESS or SASS/SCSS work fine if they were to be adopted by Drupal. LESS/SASS/SCSS all accomplish pretty much the same things. Despite the FUD, they all have the same goals, it just comes down to syntax.

Snugug’s picture

I would actually say that depends on what the goal of the Bootstrap theme is. If it's very simply a theme, then, as Sebastian just pointed out, we can do better, and we should revive that discussion. If the goal of Bootstrap, on the other hand, is to introduce the concept of a Component Library to Drupal Core, it has everything to do with Twig as it now walks into the "new theme system" talk.

Snugug’s picture

I would actually say that depends on what the goal of the Bootstrap theme is. If it's very simply a theme, then, as Sebastian just pointed out, we can do better, and we should revive that discussion. If the goal of Bootstrap, on the other hand, is to introduce the concept of a Component Library to Drupal Core, it has everything to do with Twig as it now walks into the "new theme system" talk.

RobLoach’s picture

Twig is simply a templating engine. What markup it outputs is up to us. We can format the markup however we want. Twig does not care whether or not we're using Foundation/Bootstrap. I may have misunderstood what you were saying...

Snugug’s picture

My understanding of the Twig initiative from DrupalCon Munich, as opposed to simply the engine itself, was much more broad in scope than simply writing a tempting engine and would wind up touching many other systems including the process/preprocess functions. If that is not correct, that is good to know, but also doesn't take away from the many shortcomings of Bootstrap.

tlattimore’s picture

Re #33: This is correct. The scope of the twig initiative is quite broad and much more that just dropping in a new template engine. It will be touching process/preprocess functions, as well as completely changing the current implementation of theme_* functions.

RobLoach’s picture

Yes, I understand that. But it's unrelated to Bootstrap/Foundation. Having a framework like Foundation/Bootstrap is completely front-end, while Twig/PHPTemplate is backend markup formatting... Rather unrelated topics.

Are you refering to having Twig compile the SASS/SCSS/LESS for us? Because Twig's integration with Assetic will let us do that. Likely not do that for Drupal 8 though.

Snugug’s picture

The reason I pointed to the Twig initiative was a question of what the purpose of this was. If it's simply a theme, I agree that Twig is irrelevant, but if it's really about a Component Library as the 2nd details bullet suggests, that's all Twig.

RobLoach’s picture

The reason I pointed to the Twig initiative was a question of what the purpose of this was. If it's simply a theme, I agree that Twig is irrelevant, but if it's really about a Component Library as the 2nd details bullet suggests, that's all Twig.

Ah, I understand where you were going now. Thanks for the clarification.

We can safely say that we can actually do better than Twitter Bootstrap (no offense).

Do we really need a new wheel? Proudly Found Elsewhere is already tagged. If it's missing something we need, then let's work with them to fix what it's missing. Either that or allow its extension to give us that opportunity.

Snugug’s picture

The "We can do better" isn't a "Not found here" thing, it's a this really isn't what we need thing. We need to examine what we want out of Bootstrap the solution.

If, what we want out, it better markup, it does not provide that. We should look to HTML5 Boilerplate, and we already have the HTML5 initiative in place for that. Bootstrap provides Bootstrap markup, which isn't what we want. We want best practice HTML5, and this is not it.

If it's responsive front end built on best practices, again Bootstrap falls flat. See my big post above. It's not simply a question of contributing back upstream to fix these issues, it's that it's actually easier and better for the Drupal community to do it the right way the first time.

If it's getting the idea of CSS Preprocessors into a Core theme, the front end community (both Drupal and wider) prefer Sass to Less when it comes to anything that's not Bootstrap. Additionally, saying that both are equivalent is functionally not true, with Less being far inferior. If we want to promote a CSS Preprocessor, we should be doing it with Sass, not Less, and there are plenty of "Proudly Found Elsewhere" in Sass for us to leverage.

If, though, it's about a Component Library system for Drupal, this theme is irrelevant, this should be a different topic, and again, we should look to what makes sense for us.

When it comes to frontend, "Proudly Found Elsewhere" isn't always a good thing, especially for many of the cutting edge things that move super quick. When it comes to CSS Frameworks, because of their need to confirm to general usecases, they tend not to follow best practices, or practices you would implement if you were building by hand. This is very much so the case with Bootstrap. Just because a lot of people use it doesn't mean it's the right solution. We shouldn't be turning away "Invented Here" solutions just because someone has done something else somewhere else. We should be findig the best solution to meet our needs, and Bootstrap is not that.

effulgentsia’s picture

My understanding of the Twig initiative from DrupalCon Munich, as opposed to simply the engine itself, was much more broad in scope than simply writing a tempting engine and would wind up touching many other systems including the process/preprocess functions.

The Twig initiative does intersect with some aspects of the theme system other than just the engine itself. For example, just as we submitted an Attributes class independent of Twig itself, now that that's landed, we may also submit a patch for removing process functions, which would also be independent of Twig. We still need to figure out how to turn preprocess functions from push to pull (i.e., preprocess variables only after the template uses it rather than spending those CPU cycles preparing variables that the template doesn't even output), and allow presentation-oriented variable manipulation more easily doable within the template itself so that easy things don't require the themer to do any PHP coding at all, but I don't see that as something that should be a dependency for Twitter bootstrap work, or something that would be hard to incorporate into Twitter bootstrap work after both things got figured out independently.

Related to a Theme Component Library, the major thing needed there is stuff like #1484720: [Meta] Reduce the number of theme functions/templates, and in general, better reuse/organization between a markup pattern (e.g., lists, containers, etc.) and their use cases in Drupal (e.g., book navigation, tasks, menu links, nodes, comments, blocks). One appeal of Twitter bootstrap is it already has this organization that we can model off of whether we use it directly or copy its ideas. At different times, some of the people working on the Twig initiative also tried to tackle this re-organization issue, but not much progress has been made on that, and there's no reason that work needs to be linked to Twig other than some of the people interested in that work are also interested in Twig. Regardless of how this Twitter bootstrap issue progresses, if anyone wants to breathe new life into that meta issue, that would be so awesome.

dasjo’s picture

If you're looking for a LESS compiler for PHP, there's LESSPHP, which also integrates quite nicely with Assetic. Of course, we won't need to compile it ourselves as Bootstrap ships compiled copies of it for us. Leafo also has a SCSS compiler writen in PHP too, so either LESS or SASS/SCSS work fine if they were to be adopted by Drupal. LESS/SASS/SCSS all accomplish pretty much the same things. Despite the FUD, they all have the same goals, it just comes down to syntax.

i'd strongly vote against using php-ports of SASS/LESS compilers as they tend to be outdated. better use the original versions of those tools, save bugs and keep up-to-date with such constantly evolving technologies.

chrisjlee’s picture

I normally don't voice my opinions that much in drupal core but i vehemently oppose this for the following reasons:

  1. Drupal core already has a lot of css; we should be moving toward reducing the css line count
  2. Adding a monolithic framework is costly and provides little benefit
  3. Adds a unnecessary dependancy
  4. Bootstrap belongs in contrib
drupleg’s picture

@snugug is right about everything he said. Please don't put twbootstrap in Drupal. I don't comment on many of these D8 issues, but this one is very important to me as a sitebuilder. A shared component library is a fine idea, twbootstrap ain't the answer. Zurb Foundation, or roll our own is the way to go. In the time allotted - Foundation is the best choice, plus Foundation is SASS, twbootstrap is LESS and inferior in the general consensus. I've been using Foundation over the past 6 months and have easily plugged-in the style components to several base themes config.rb including Zen, Aurora, Omega, and my final favorite AdaptiveTheme base, which the AT code is so fast and clean that I don't know why AT base isn't being considered for the new base theme. That's my 2 cents.

drupleg’s picture

Furthermore, Foundation also has 8 HTML templates available right now that someone can easily Twig-up a prototype in an afternoon - http://foundation.zurb.com/templates.php

Dries’s picture

One of my long time goals for Drupal is to foster a thriving themer community. I don’t think we are there yet, relative to our module developer community. I see a theme based on a strong front-end framework, like Twitter Bootstrap, in core as a step in the right direction. I'm impartial about whether we choose Twitter Bootstrap, Zurb, or another popular framework so let's just assume Twitter Bootstrap (TB) for the sake of this comment.

People shouldn’t need to go to Contrib to find out that Drupal works well with front-end frameworks.

I’d love to see a minimal implementation here. Specifically, let's add one new non-default base theme that is based on TB, or try and create a version of Bartik on TB. (We don't really have time to design a new theme from scratch.) It will be a model for others who want to use TB and Drupal. People who don’t like TB can just ignore this theme. Folks who want to use a newer version of TB are free to do that. While implementing, we might want to change some core markup to be TB friendly. We can make those changes in core or in the new theme. Lets just use best judgement there.

Before we do much more, we should reach out to caniszczyk and see if we can overcome the Licensing issue. I see this has already been started at https://github.com/twitter/bootstrap/issues/2054, so that is great.

Snugug’s picture

I'm very happy to hear that you're interested in fostering a thriving themer community. Unfortunately, I don't believe that TB, even as a non-default Core theme, would be the way to go about that.

Twitter Bootstrap is, colloquy, most commonly used by individuals who do not have the front end/themer talent to create something from scratch. It is for this very reason that those themers who do have that capability do not use Bootstrap and are generally against it as a proper theming tool; it's OK for prototyping, but never good for final product. To me, the common Bootstrap user's usecase, wanting a nice theme but not having the ability to make one, is the definition of what Contrib is for. While I can appreciate wanting to show off that Drupal can play nice with front end frameworks, I fear Bootstrap is the wrong framework to do it with, not only because of its poor Responsive support but because of the general lack of support from our existing front end community.

Truthfully though, all of the frameworks, be it Bootstrap, Zen, Skeleton, or others, are all designed to be backend agnostic. I don't understand the benefit in general of having a default theme built to a specific framework; it's all just CSS. The biggest issue with implementing frameworks with Drupal is the load of extra CSS we need to overcome from Core and Contrib modules, and the dirty class/HTML output we get, which is a focus of Twig to fix. I really, truly believe that the stigma around theming for Drupal is not that we can't use Zurb or Bootstrap with it, because very clearly we can, but rather that the output takes an almost Herculean effort to wrangle properly. Because of this, I do not believe that saying "Look! We've wrangled Bootstrap (or Zurb or Skeleton) into a Drupal base theme!" is not going to help foster the Drupal themer community, better core Markup and CSS is, and that's not going to come from building a Framework powered theme, that's going to come from having frontend experts like those working on the HTML5 and Twig initiatives fix the theme layer's output, something we can and should do in a CSS Framework agnostic way.

lightsurge’s picture

There definitely seems to be a lot of interest in a proper twitter bootstrap base theme for Drupal #1594508: Merge in other d.o Bootstrap projects and if all that effort had gone into one place I would definitely think that Drupal 8 should have a subtheme of that as it's default theme.. that's not come about though, it's all dissipated and only just in the process of merging.

If I was to pick out the most obvious great thing it's be the fixed header menu, where I find those on sites I really appreciate them, especially mobile.

For that reason at this stage I definitely think that if those awesome people working towards a theme for Drupal 8 could pick up on details like that I'll be really pleased, even if we don't end up with a base of bootstrap in its entirety.

lightsurge’s picture

When I say I think bootstrap would be a great default theme for 8.x, I mean by way that it's so beautifully well documented (partly down to the theme the documentation's on!), and it's such a brilliant start for people making a great site.

But it's not 'one to rule them all', the bootstrap examples look very bootstrappy-recognisable to me (http://builtwithbootstrap.tumblr.com/) and while they look great they look a very specific kind of great which seems to dissolve Drupal's individuality, yes as all the other sites built off same base themes might be, adaptive, omega etc, but these have had more investment on drupal.org, have grown with it, aren't yet in core and still look great. And they're more individual to Drupal.

The best thing in terms of themes is variety of which there's plenty to choose from on drupal.org and sadly no stable twitter bootstrap base ones on drupal.org right now.

But smash and grab what's good about it I say, without getting sued ;-)

cweagans’s picture

But it's not 'one to rule them all', the bootstrap examples look very bootstrappy-recognisable to me (http://builtwithbootstrap.tumblr.com/) and while they look great they look a very specific kind of great which seems to dissolve Drupal's individuality

Well, that might be a good thing. Drupal sites are usually easily identified. If we can prove that Drupal can make websites look like anything else on the web, then maybe front end devs will be more interested.

xtfer’s picture

I think, if you've actually tried to work with Bootstrap and Drupal, you will probably have serious concerns about this proposal. It's a nice look, for what its worth, but it's Twitter's look, and it doesnt match with Drupal without some work.

Ember is developing as a nice admin backend, and for the front-end, maybe if you are interested in a good twitter bootstrap base theme, you should focus on building one that works well in contrib first, or just making Stark a bit more attractive out of the box.

lightsurge’s picture

@#48 Yea... I see how by the act of forcing through a bootstrap theme it could batter Drupal into being able to take shapes it couldn't before. Sort of like a theme 'intervention'.

Snugug’s picture

It's this comment, and those like it, that concern me and lead me to believe those advocating for this as a solution don't actually spend much time with the larger frontend community. The front end that we're trying to attract is not the frontend that like Bootstrap, they are the ones laughing about the fact that tent.io, a startup Twitter competitor, is using Bootstrap. They're the one creating Built With Bootstrap, not as a showcase of good examples, but rather because building with bootstrap is an easy way out for design and therefore easily recognizable. They're the ones out there pushing what frontend means. Do we honestly believe that the people who decry "This site looks like Drupal" are going to turn and praise us because "This site looks like Bootstrap?". No. All we've done there is replace "Drupal" with "Bootstrap". While "This looks like Drupal" may be a blemish in the wider community, in part due to its overuse, in part due to its ease of recognition, and in part due to its flattening of design, Bootstrap, amongst frontend at large (now I'm including front end devs and designers here) is seen more as a scarlet letter than a job well done.

Innovative talent begets innovative talent, good design begets good design, best practices beget better ones. Showcasing that we know a fad CSS framework when we see one doesn't help bring talent in to Drupal.

We can always think about it in another way: is any of Drupal frontend thinking of jumping ship to Joomla! now that it ships with Bootstrap in its core? I think you'll find of the caliber we're looking to attract, and even amongst Drupal frontend as a whole, not a soul is moved by that advance. You may in fact find many have a lower opinion of the frontend decisions of the project now. I know I do.

RobW’s picture

Snugug's going hard here, but he makes some very valid points (especially about the caliber of front end developer Drupal is trying to attract).

I think Bootstrap has a lot of value as a base theme, as long as it's a base theme that aligns with Bootstrap's purpose. As Lightsurge pointed out, "these are prototyping frameworks; they allow you to get something out of the box quickly." Bootstrap describes itself in a similar fashion:

At Twitter, Bootstrap has quickly become one of our many go-to front-end tools when starting new applications and sites. This is because while it is very extensive, it’s flexible enough to work for many unique design needs.Today, you can use Bootstrap to throw together quick prototypes or guide the execution of more sophisticated designs and larger engineering efforts.

Once a product is mature enough to rate the extra development hours, Bootstrap is meant to be tweaked, revised, and replaced with project specific code until what you have left is a perfectly fitting custom css system. If this issue is about building a base theme for rapid prototyping that incorporates Bootstrap, that's great. If anyone is talking about using Bootstrap to define html and class structure and provide the canonical interface element library for all of Drupal, that would be a mistake. That's not what Bootstrap is for.

fubhy’s picture

One of my long time goals for Drupal is to foster a thriving themer community.

And that's why we should try to use the great expertise of our own, existing, front-end community. Blindly jumping on the TB train now that Joomla! adopted it and it's being moved to github is something that we would regret in the long run. @Snugug outlined several reasons why TB is a bad choice. I would like to see how Joomla! decided to use TB - Apparently (https://twitter.com/webchick/status/253671617790615552) Joomla! discussed that in private. We should probably contact them in order to find out how they came to that decision.

What we actually want is proper, quality markup and CSS. We won't get that by building a theme on top of TB. As @Snugug pointed out it doesn't even follow modern best practices. I am not bashing TB, it certainly has its niche but we certainly don't want to restrict ourselves to that niche.

Because of this, I do not believe that saying "Look! We've wrangled Bootstrap (or Zurb or Skeleton) into a Drupal base theme!" is not going to help foster the Drupal themer community, better core Markup and CSS is, and that's not going to come from building a Framework powered theme, that's going to come from having frontend experts like those working on the HTML5 and Twig initiatives fix the theme layer's output, something we can and should do in a CSS Framework agnostic way.

That pretty much nails it.

We don't really have time to design a new theme from scratch.

We don't have to do it before feature freeze. After all, a theme basically is somewhat isolated from the rest of the system and won't interfere with anything. So considering that we would actually have quite a few months left for such an undertaking. However, we might still be a bit late for creating a completely new design from scratch... Maybe.

Maybe we could foster a proper workflow/release cycle for themes in core. Out of my gut feeling I would always expect Stark (basically, a completely "empty" theme), an admin theme (currently Seven), the last versions "main" theme (for D8 that would be Bartik), plus a NEW main theme in each new major version of Drupal. That way we would basically have some kind of LTS for the previous main theme while moving forward with each major version. After all, a new design is always something exciting that will draw a lot of attention. Also, by building such a theme for each major version, we would be able to identify the flaws in the current system and perfection our underlying theme system and output in terms of the latest web standards.

Actually, I think that the effort of creating such a theme could happen outside of core with theme and template overrides right there until we are done. Porting whatever fixes we come up with to core and, at the same time, fixing the other (affected) core themes is a minor problem and won't take up much time.

People shouldn’t need to go to Contrib to find out that Drupal works well with front-end frameworks.

That is correct, however, we won't reach that goal by squeezing and battering Drupal into "Insert Framework Name Here". We will reach that goal by providing lean and clean output and base CSS that is Framework agnostic.

Anyways... what Snugug and I are trying to say here basically is: If we do this, we should do it right. We got the expertise in our community, thus we should leverage it.

drupleg’s picture

Dries said in post #44

Specifically, let's add one new non-default base theme that is based on TB

I think that's quite reasonable to include a Bootstrap theme as long as it is not the default theme. I think it would be a mistake to bend the core markup to accommodate the Bootstrap framework, or to have TB takeover the admin backend. TB isn't my personal choice for anything, but if it doesn't affect core and there are people eager to work on it - knock yourselves out Bootstrappers!

webchick’s picture

I have two things to say in this thread.

The first is that I don't actually believe we currently have a front-end community capable of defining our own "more betterer" standard UI patterns in core, as much as I would love to believe that was the case. Jacine tried to spear-head it first, she got completely burnt out since no one stepped up to help implement her ideas. Then the Drupal.org D7 port of Bluecheese got completely stalled out because the people who insisted on porting it using best practices like SASS and whatnot, which it turns out no one except for extremely busy people with no time to contribute to it know how it works. :\

Now, I'd love to be proven wrong on this, and that we do indeed have a strong kernel of front-end devs who would be ready and willing to take on "Twitter Bootstrap, but better, and for Drupal, and in time for feature freeze." Unfortunately, what I've seen so far from our front-end community is a lot of very strong opinions about we ought to do / not to do, but not a lot of code / long-term maintenance on that code. :\ That doesn't bode well for approaching this from a "NiH" stance. We've gotten a lot more leverage historically on choosing solutions that have a lot of critical mass behind them already and that non-experts can pick up easily (e.g. jQuery).

But please, do prove me wrong! I'd love to see our front-end community more deeply involved in Drupal core development, rather than just cursing at us when we invariably get it wrong. :)

The second is that I tried to inquire on Twitter as to how Joomla! got Bootstrap into their CMS, which is a GPLv2+ licensed thing like Drupal's. There's unfortunately no definitive reference to an "official" decision (which apparently happens behind closed doors :\), but opinions ranged from the + in GPLv2 is an "or" rather than an "and" (which seems dodgy to me... it removes the choice of the licensee to use GPLv2 if they so choose) to Twitter Bootstrap is "media", not "code", to "I dunno, ask so and so." :)

Amy Stephen, who seemed to be the most definitive source, pointed me at http://wordpress.org/news/2009/07/themes-are-gpl-too/ which was the SFLC's response to what qualifies as derivative works within WordPress. They say CSS/images are "media" (which is our stance too, and why businesses such as Top Notch Themes can exist, as long as their base theme w/ PHP code is GPL).

As you can see from that blog post, WordPress took a similar route we did, and declared all themes GPL in order to keep things simple. Even though Joomla!'s root LICENSE.txt file reads GPLv2, apparently if you go trawling through source code you can find individual files with different licenses. The thinking is that since JS/images/CSS never share the same memory space as PHP, they don't get "infected" with GPL. It's unclear to me how they reconcile Twitter Bootstrap markup generation from PHP, but hey, that's not my fight to fight. :)

Now, Drupal.org of course enforces a hard requirement of all files/code/etc. being uploaded here being GPLv2+, the same as Drupal, in order to eliminate any licensing questions. This is not a mandate from the SFLC/FSF, this is our own community's cultural rule, which Amy recommended we change to be more inline with industry standards. This rule could be changed, but that would be a much broader discussion, probably involving the SFLC and the DA and some other legal counsel.

So all of that said, IMO we have two options if we want to use Twitter Bootstrap (Zurb Foundation is MIT so no worries there, but Github also lists it as a Ruby project, which gives me pause):

1) Wait for upstream to relicense their code as MIT so we can re-license it as GPLv2+
2) Start an enormous bikeshed discussion on whether we should exempt CSS and images (and JS?) from GPLv2+ on Drupal.org.

I'd prefer to do #1, or choose a different front-end framework that's more compatibly-licensed, personally. #2 feels like an enormous distraction right now (and should not be discussed in this issue in any case).

dodorama’s picture

As Snugug pointed out in #25 most of the components are either inaccessible or plain broken on mobile (the modal, the dropdown, the navbar, etc.) I dont think anybody here is comfortable to bring broken code into core. What remains then? A not really flexible grid, a little bit of typography.
I haven't seen any major website developed with Bootstrap. And there's a reason for that. If Drupal front end developers can't agree on a framework that's because a framework isn't really appropriate for a project like Drupal and the code is usually not good enough to be included in core.
Bootstrap is great for prototyping not as good for production (and very difficult to customize). IMHO it belongs in contrib. if we need a theme that makes easy to prototype websites let's do it the Drupal way. What would be the use case of abootstrap based theme ? What are the advantages?

steveburge’s picture

As a heavy user of Drupal, Joomla and Bootstrap, I find this discussion fascinating and it brings a sense of deja vu. There was a lot of very similar back-and-forth in the Joomla community before the decision was made to adopt Bootstrap.

Some links:

One caveat is that they were trying to address a slightly different set of needs than those that Drupal has. For example, one need was a consistent admin UI. Like WordPress, many developers made their own admin UIs. Drupal doesn't have that problem as much, so using Bootstrap for the admin isn't such a concern.

@Webchick Twitter isn't the place to get good answers on these issues. I know Joomla took this licensing issue seriously and they got detailed answers from the Software Freedom Law Centre. Email one of your contacts on the Open Source Matters board and I'm sure they'll fill you in on the legal advice they got from the SFLC.

fubhy’s picture

Thanks for the links Steve.

I just got an e-mail response from Andrea Tarr of Joomla! after being redirected to her from Brian Teeman. This is the content of the e-mail:

That [Joomla! Twitter Bootstrap adoption] discussion took place in a few different places including on our developer google lists, at Joomla Days, in direct communication with third party developers and on the http://ux.joomla.org site. One of our main reasons for going for something like Bootstrap was to give the 3rd party developers and template (theme) developers a common language for marking up extensions. Bootstrap is actually a major subset of what we are calling JUI, which is a collection of common ui elements.

We consulted with our legal consultants about the license for Bootstrap. We would have preferred something that was directly gpl 2.0 compatible (the apache license of Bootstrap is compatible with 3.0, but not 2.0 or later). However, we do allow media to have licenses that aren't compatible with gpl 2.0. Therefore, we were able to go ahead with incorporating Bootstrap with the apache license. I believe that Bootstrap was also toying with the idea of releasing as MIT, though I might be remembering that incorrectly.


smileyj68’s picture

Hey folks, Jonathan from ZURB here. Cool to see Foundation coming up in the conversation here and, for our part, we'd love to see Foundation integration with Drupal. If there's anything we can do to help please just let us know - Foundation is in active development toward 3.2 and then 4, so if there's things we can include in those releases that simplify this for the community we'd like to hear it.

dodorama’s picture

As I said I'm not necessarily a big fan of frameworks but if I have to pick Foundation has my preference.
Personal preferences apart having the developers on board would mean a lot to me so that we can build something bigger together and take the chance to do more than just serve a theme based on a framework but leverage it for other initiatives as well (I'm thinking layout and responsive grid UI).
What about the accessibility of the components?

What about Sass/Less ? How would that integration work for drupal? A php port?

effulgentsia’s picture

Regardless of whether we have a TB theme in core or a ZF theme in core, we'd be missing a really important opportunity if D8 core ships with default markup, default CSS, or organization of theme functions / templates / render array types, that make creating a TB theme or ZF theme any harder than doing so would be for a non-Drupal site. We all know that Drupal theming isn't as easy as we could imagine it to be, and so our front-end community has only grown thanks to remarkable perseverence of front-end devs who stuck with it anyway. Frameworks present an opportunity to get not-yet-expert front-end developers making nice themes. Let's do what we can to minimize the barrier that Drupal imposes to people who want to use those frameworks. I'm not a front-end guy, so I have no concrete idea on how to do that, only generalities like "better default markup", "better default css", "more reuse and less duplication of markup patterns across bazillions of theme functions". I'd love to see specific issues opened for "change markup A to B" or "change CSS X to Y", or "change implementation of render element type foo to xyz", or "consolidate templates A, B, C, and D". And explanations in such issues for how that would get Drupal into better alignment with popular markup/css frameworks.

dodorama’s picture

I believe the markup has been improved a lot already in D8. We have full support for HTML5 now and responsive themes.
But the struggles of developing a theme for drupal are, in my opinion, because of the broad range of use cases that drupal covers as a framework/cms.
It's easier to develop a theme for Wordpress because it is more focused as a product. Your dealing with very specific needs. This is not necessarily a bad thing but that's how it is. I've been trying to develop a generic theme for Drupal many times but I always gave up and I now have a framework theme that I reuse which is tailored on the very specific customized profile/distribution that I built for my use case (personal portfolios).
In general, building themes for distributions rather than Drupal core seems to me a scenario for the future, unless the standard profile gains more focus as a product.
This is very important to understand for those who don't have front end experience with Drupal. It is not just that the front end community is lazy or the system too difficult for themers.

RobW’s picture

We'd be missing a really important opportunity if D8 core ships with default markup, default CSS, or organization of theme functions / templates / render array types, that make creating a TB theme or ZF theme any harder than doing so would be for a non-Drupal site... Let's do what we can to minimize the barrier that Drupal imposes to people who want to use those frameworks.


As a front end guy, I can say that the way these frameworks work is by defining re-usable html patterns (sometimes referred to as html objects) and applying a set of pre-defined classes to them. The biggest barrier that front end developers new to Drupal face, whether implimenting one of these frameworks or creating their own html/css framework (which is what SMACSS, OOCSS, and responsive design are all centered around, really) is the theme function. Put that *ish* in templates. Front end developers love template files -- we love writing our OCD markup and adding classes, data attributes, etc. directly, and have those files (that we understand and control) be the only thing that is creating markup on the site. I am ecstatic for twig. If we decide to become more adept at Drupal and become hybrid developers, we don't mind programmatically altering some of these values (preproccess woo), or learning how the render array works and how to use it.

As a front end guy that uses Drupal almost exclusively, I can say that the thing we hate most is spending 1/2 of our development hours removing "sensible" defaults from Drupal theme code (thank you, Mothership), or writing patches and hacking modules to pull all markup in template files so that we and the rest of our team can edit them. Actually, doing that for the last three years is how I learned to code in PHP, so there's some benefit. So what we don't want is Drupal as a whole deciding to add a canonical Drupal prototyping framework and bending all of it's code around that project's markup and classes without addressing the ease of editing concerns above.

Drupal's theme system at its core is really one of the best out there -- it has the ability to control every piece of markup in tiny semantic chunks, has a great template overriding and cascading process, and is hugely extensible. I love it. But the implementation of that system is often not the best. That's what needs to be fixed.

Noyz’s picture

+100 for Foundation in Core. It's a brilliant framework that would start to set the stage for a standard definition of classes - both from a responsive point of view as well as a feature POV (e.g. tabs, buttons, tables, etc.).

Snugug’s picture

RobW has put it just about perfectly, and his reasoning is precisely why I believe this story should be "Make Twig awesome" and "talk about a Component library for Contrib". Bootstrap doesn't belong in Core, nor do any frameworks. We want semantic, modern, unbloated, easy to override markup coming out of Core, not more crap for us to override. That's exactly what Twig is doing; we should close this topic and send all development resources over to Twig to make what frontend really needs a reality.

lightsurge’s picture

The typography in Zurb sometimes seems to go strangely small.. I notice the difference only by having waded through a dozen bootstrap themes and quite like the typography.

Then I looked at the examples in the Zurb foundation footer:


I know it's nitpicking but all those three examples which are the first three examples in the footer just look like some of the text should be bigger.. is it just me? In contrast I struggle to find similar characteristics in bootstrap, all the text tends to be quite readable:


cweagans’s picture

@Snugug, This issue is not about Twig. This issue is about adding another theme to core. If you don't like the theme, you don't have to enable it. No harm done. Please stop trying to shut down discussion here.

Snugug’s picture

See, I disagree this thread is about adding a theme to Drupal. I think the reasoning as given in the original post speaks to underlying issues. I'm arguing for the forest, not the trees.

As an aside, Zurb vs Bootstrap is, likewise, missing the forest for the trees IMO.

Snugug’s picture

As an aside, because Jacine's work on Component Libraries are specifically mentioned in the OP, a quote from Jacine herself:

FTR, @Snugug and @thefubhy are spot on in that thread.

cweagans’s picture

Well, the title of the issue is "Add a Twitter Bootstrap-based theme to Drupal core". That seems pretty well defined to me. While I appreciate your viewpoint, can I recommend that you open an issue identifying a plan of action to make the theme system more suitable for front end developers (and specifically, how that correlates with the efforts on the Twig conversion)?

RobW’s picture

To be fair, the conversation has drifted back and forth from adding another theme to core, to adding a css/prototyping framework as the basis of markup to core. I can see how opinions could flare, especially among front end developers who don't have the ability (or maybe time) to write core patches, and therefore see this as their only opportunity for input.

And to clarify my position, I think an optional bootstrap non-default theme would be an amazing thing to ship with core, as Dries suggests in #44. Maybe not so amazing that I'm going to work on it though ;).

DamienMcKenna’s picture

Given the fact that Bootstrap is currently incompatible with our community's stance on licenses, the fact that there's a lot of other front-end dev plumbing needing to be done, and the fact that our front-end development community are saying it sucks (to paraphrase), why is this even being considered? It sounds like a great contrib project, not something for core.

For inclusion in Drupal core any piece of functionality should have high standards and match the requirements & needs of the people who will be using it. If the JavaScript developers said a new library sucked would we try to push for it to be included? If a new API architecture sounded neat (OAuth 2 anyone) would we shove it in anyway or listen to the sound arguments that say it sucks?

DamienMcKenna’s picture

An additional thought: correct me if I'm wrong, but isn't a goal of Drupal 8 to resolve many long-standing problems by doing things right, by giving us powerful & well built functionality that many have been looking for? Adding functionality that our community's topical experts are saying is the wrong way of approaching the topic would go against this goal.

cweagans’s picture

If somebody wants to point me to this mysterious list of things that really need to be done to make the theme system not suck, please feel free. I'd love to help. I'm not sure why it has to be Twig OR this issue, or [that list of issues] OR this issue, but evidently, that's how it is.

It seems like every time I see an issue like this one, people get pissed off about the proposal because it's not "pure", people insist on building their own thing for the same reason, shut down discussion, and then nothing ever gets done because the people clamoring for the opportunity to build their own thing never do.

As I said: I'd love to help make Drupal better, but "the theme system sucks" is not actionable.

/me unfollows.

mdrummond’s picture

Everything that Snugug, fubhy and Damien McKenna said: +1.

I'd just like to also add that I also think it's unnecessary to create a core theme in Flash, just because it might look cool and would attract Flash developers to Drupal.

That's said in jest, but seriously, Drupal needs clean, standards-based code, with less CSS cruft, that is responsive and multi-device friendly out of the box. From everything that's been detailed about Bootstrap above, I don't understand the desire to have this in core. Create a contrib theme if you really like Bootstrap. Make a quick prototyping distribution that includes it, if that's the goal. But why put something with so many demonstrable problems in Core? Because Joomla did it?

Sure, Bootstrap "looks cool" now. But D8 won't be released for another year. And if D7 is an example, many won't upgrade to D8 for another year after that, when enough contrib modules are available. And then at that point those folks will see a core theme with a two-year old version of Bootstrap? Precisely because Bootstrap is easy for some to use, I would expect that the visual style of Bootstrap will feel like an overused fad at that point. Common design styles just don't stay fresh for all that long.

As a site builder and front end developer, I wouldn't find it at all attractive to have a Bootstrap theme in core. I'd much rather see efforts go into Twig and other initiatives, like Mobile and Layout, which will have a far bigger impact on making Drupal friendly to front end developers for years to come.

Code freeze is coming up quick. It seems strange to throw resources at a project like this, which front end developers don't want, when so much work is necessary on successfully completing initiatives that front end developers do want.

laura s’s picture

Commenting as one of those who's been too busy this past year to pitch in (boo), but has a strong interest and follows as much as she can, especially when it comes to Drupal's theming layer.... I find myself agreeing with @Snugug, @c4rl and others who oppose the broader proposal of incorporating Bootstrap into core.

As for making it into a core theme, my question is: What does Bootstrap as a core theme basis do that it can't do in contrib? What problem does Bootstrap solve? Is it more important than Twig?

Whether as a theme, a prototyping framework, or a cutting edge (in 2012) way of presenting content, wouldn't a Bootstrap endeavor thrive more in the free and fast-moving contrib world? As others have noted, core moves slowly, but the front-end world is evolving incredibly rapidly. The Drop is always moving, but FED is moving much quicker. By the time D8 comes out, we'll be talking in the FED world about a dozen new tools, frameworks, best practices, etc. The front-end world isn't going to wait for Drupal core.

c4rl’s picture

In the event cweagans didn't actually unfollow this issue and would in fact like to be pointed to some more pressing issues I think #1788918: [GTD] [META] Prepare for Twig main engine core inclusion until December 1 is a good start (as I mentioned way back in comment #12).

Any objections to marking this issue postponed or closed (won't fix)?

catch’s picture

None from me.

RobW’s picture

No preference on whether we close now or give it a day or two.

Here's a rough tl;dr summary, taking into account discussions on the twittersphere:

1. Most front end developers here are not in favor of core markup being specifically revised for Bootstrap, or for Bootstrap to be a requirement for core interface elements or default Drupal themes (Seven or the primary D8 admin theme, Bartik or the primary D8 front end theme).

2. Wider issues for the theme system all deserve their own issues, many of which exist.

3. A prototyping theme that includes Bootstrap could be included with core, as long as Bootstrap was sandboxed into that theme alone (i.e., unless you're using the Bootstrap theme, Bootstrap components aren't used in Drupal).

4. If you want to work on a non-required Bootstrap theme for core, great. If you want to work on the twig integration and core markup cleanup, great too. Most front end developers see the twig and core markup issues as higher priority.

webchick’s picture

I was informed that my comment in #55 could be misconstrued to say I disagree with or am dismissing the recurring premise from the prominent members of the Drupal front-end community that frameworks like Twitter Bootstrap are not what they want. I feel this is misrepresentative of my views, so let me try this from a different angle.

Let's start with a premise I think we can all agree on: Front-end code written by back-end developers frustrates the living hell out of front-end developers. :) Can we all agree to that? :D

If so, we're left with two options:

A) Grow a maintainer team around Drupal core's markup of front-end developers who take charge of ensuring that Drupal's markup is semantic, easy to override, and sensible. Jacine worked her ass off to do this as HTML5 initiative lead, and the results are very impressive. Drupal 8 core ships with native HTML5 output, we've removed many cases of "div-itis" in favour of semantic tags such as "article," theme functions that were 99% duplicative have in several cases been consolidated down to single ones, etc. However, Jacine has stepped away, and no one (and ideally, many more than one) has stepped in to fill this gap. So we're left with MAINTAINERS.txt listing two people as Markup maintainers, when in reality one is gone and the other is busy maintaining the other 900 subsystems in core.

B) Own up to the fact that we as backend developers who largely comprise the current Drupal core developer team will never write front-end code that doesn't make front-end developers miserable, and so rely on emulating a blueprint/template that was written by front-end developers to drive us. Once again, Jacine paved the way during her tenure as HTML5 initiative lead and developed a really solid start on this at http://jacine.net/post/19652705220/theme-system. But no one picked up where she left off. So in absence of leadership here, it's natural we turn to outside sources, even if they have their flaws, since they're definitely going to be better than what a bunch of back-end programmers can cook up.

The fact that we don't have A is what makes B compelling, from a core developer team perspective. If we were to solve the problem with A, then hell yeah, let's do it! But what we see in evidence here is not front-end developers banding together to solve A, but rather front-end developers banding together to yell at the well-meaning (and, granted, ultimately misguided) back-end developers for trying to do something better than the status quo. And I fear that if/when we merely bury this issue, what we'll be left with is just what we started with: Front-end code written by back-end developers, that frustrates the living hell out of front-end developers. :(

I do think that Snugug did a very good job in #25 of enumerating the reasons why Twitter Bootstrap is probably not the right choice for us, even given our goals of B. So if this issue is to be closed, what I would strongly suggest as a follow-up item to get some interested parties from this issue hacking on the markup, CSS, javascript, html5 and mobile queues, and then get those folks listed in MAINTAINERS.txt so we have leadership around core's markup once again. Such a team could then help educate the back-end developers on what they need, spin up issues and help to get them done, and become part of the core developer team, rather than feeling victims of it.

And then we'd end up with Drupal 8 markup written by front-end developers, for front-end developers and world domination is just a few clicks away. ;)

effulgentsia’s picture

For anyone interested in following / helping out on Twig related work, #1696786: Integrate Twig into core: Implementation issue is the current core patch for getting the first template (node.tpl.php) and the first theme function (theme_datetime) converted to twig templates, which is a key issue, since that's what sets up the proper Drupal / Twig engine glue code to enable follow-up core patches to convert the other dozens of templates and hundreds of functions.

Meanwhile, those conversions have already been happening in a sandbox. There's plenty left, so dig into that sandbox's issue queue. The more that's done in parallel while the engine work is being reviewed in the core queue, the faster follow up core patches can be moved through the process, since it'll just be generating patches from the sandbox and posting them to the core queue.

If the Twig work goes smoothly, and our expectations about performance are borne out, we'll no longer have the theme function / template dichotomy, it'll all be twig templates, addressing one of the points in #63.

But, we'll have a couple hundred twig templates, and each contrib module will add more (as has been the case for theme functions / php templates in D5, D6, and D7). Making it tedious to customize every single piece of markup for a site with a known list of modules, and impossible to create a theme that customizes every single piece of markup for an open-ended set of contrib modules (as has been the case with D5, D6, and D7). To address this issue, we need a theme component library, so that for all but edge cases, modules stop adding new templates, and reuse existing ones. If you can help with that, looks like the Theme Component Library tag is where the action is. This work does not need to be blocked on Twig. It needs vision of how to organize reusable markup patterns, and work to implement that vision and move it through the core patch process. I would have expected Twitter Bootstrap and/or Zurb Foundation to provide us a leg up in creating this Theme Component Library. If that's true, let's use/copy what makes sense. If that's not true, then I look forward to seeing what Drupal's front-end community can come up with in its place.

chx’s picture

This is going to be a chx comment, so some disclaimers apply: one, these are my thoughts only noone else's. Two, try to (i know this is a futile request) take heed of my thoughts not my wording of them.

  1. At least for reasons listed in #25, there should be no reason to continue this discussion (it's strong enough that we can put aside the problem that legally we can't). So why do we? But let's presume we go with Zurb Foundation, we have help from them in #59. yay!
  2. Not wanting to critique jmburnz, absolutely not, but the design initiative disappeared. That's more a state of the Drupal community which severely lacks designers. So, we add a Foundation and then fairies riding on unicorns deliver a theme. Is this the plan?
  3. As for adding SASS to core, I can't help myself but link to this awesome page and quote:

    How do I install this?
    Um... are you stupid or something? Just attackclone the grit repo pushmerge, then rubygem the lymphnode js shawarma module – and presto!

    Anyone arguing for including SASS in core, consider yourself enlisted for supporting Ruby installs on the machines of frontend developers. Mac people, form the queue at door #1, thanks, windows people at door #2. Why there is noone at #2? hey!

jessebeach’s picture

Agreed laura s, great point.

Snugug’s picture

So lots of comments on the above, gonna dive in kinda last to first:

chx, to your point about Sass. Yes, adding a Sass powered anything anywhere in Core is going to be met with the Ruby challenge, and as those of us who love Sass have come to agree with you, it's no easy feat to convince Frontend or new developers that Ruby now needs to be part of their workflow. With that said, it's not insurmountable; there are lots of GUIs for Mac, Windows, and Linux to compile Sass, and you can do command line on Windows via Ruby Installer. Additionally (and this is specifically not meant to be a plug for my Drupal work, rather for the documentation I've done with regard to Sass), in the Readme PDF that comes w/my Aurora theme I've got install instructions for all 3 platforms plus IIRC links to GUI compiling apps for all platforms. With all this said, I believe this is a separate topic of discussion and one we don't need to have here.

effulgentsia, I can truly appreciate the want of a Theme Component Library but I truly believe, considering the time constraints, the massive amount of IA and coding that would need to go into it to get it right, and the fact that most of Frontend who know the D8 theme layer well enough to effectively pull it off are currently working on Twig, I strongly believe this is something that we need to vet out in Contrib first (or hold off on releasing D8 until we can get both Twig and a fully realized TCL into Core, plus I'd argue Blocks Everywhere is a big part of this too). I believe something that would make this closer to a reality in Contrib is #474684: Allow themes to declare dependencies on modules, which I had done some work on, but due to the fact that Core moves faster than I have time to catch up and that I don't totally grok the graph stuff used for the Module page, is not finished yet. Again, this is something to be discussed elsewhere.

Additionally, while "a couple hundred twig templates" sounds daunting on the outset, the reason we'll have that many is so that frontend can have the fine graine control over the markup that we've always wanted. That's the tradeoff. Many, many of those won't ever need to be touched, and it won't effectively be more work to customize every nook and cranny than it is now; same amount of pieces, just presented in a different way. This really should be a non-issue.

As for a CSS Framework providing us a leg up in the Theme Component Library, this seems to be a misunderstanding of the actual wants of frontend and of what CSS Frameworks provide. They do not provide markup but rather, in the worst of cases, assume very specific markup. At best, they provide styling that can be applied in a markup agnostic way (in fact, that's the sign of a good CSS Framework, that it makes no assumptions about your markup). Additionally, the last thing Frontend wants is more CSS to override or hack out of their theme. Any Component Library we build should be for markup only; no CSS in sight. It can include SMACSS style classes with easy ways of hooking in to make changes to classes/IDs/markup if needed/wanted, but it should not include CSS. It should be a frontend solution, not a sitebuilder solution.

webchick, I'm not entirely sure we don't have A, I just happen to think (from what I saw in Munich anyway) that most of the people who would fall into A are busy with Twig. If we're lacking resources to simply ensure that our HTML output is up to snuff, that's something that should be easily remedied, and I'll make a point of looking over Core's templates to make sure everything HTML5 happy. Again, to the point above, while I like the idea of a Theme Component Library, I don't think frontend has the time or resources to do it for D8 given the current known unknowns and the time frame we have. That being said, if there are backend developers who want to help with suss out the IA and implementation with direction given by frontend, that makes it more do-able, but again, I don't think it's going to happen for D8 and it could probably benefit from time in Contrib to work through issues. You're right in saying frontend doesn't have the raw numbers to get stuff done in Core like backend does and because of this, I strongly believe that frontend's time should be used where we believe it's most effective and if backend wants to implement a frontend solution, they should make a point of trying to pull current frontend in instead of making assumptions about what frontend would like or what's best for them. IIRC, that's how Twig came about to begin with.

Finally, to answer c4rl's objections question, and baring in mind webchick's and chx's comments, I'd like to see this marked closed (won't fix).

AmyStephen’s picture

Steve -

Angie asked for a link to the Joomla discussion on licensing related to inclusion of Twitter Bootstrap in 3.0. I know Joomla leadership discussed this issue (and I believe the SFLC was consulted), but the discussion was between leadership team members was not public, it was private, and therefore a link is not available to share with Angie.

My response to Angie was consistent with the response provided by Andy. In my opinion, open discussion of those topics is preferred to private emails as many of us need to be aware of the issues related to code we write and submit for use by our communities.

It's understood (I lived through the Joomla GPL talks) that licensing discussions can be difficult, but Angie and my discussion was unemotional and not 'religious', it was simply an exchange of our knowledge about the specifics of this issue as that issue related to projects in which we participate.

I agree, BTW, with your conclusion about the difference between the benefits of Twitter Bootstrap for Joomla versus Drupal. Not a big surprise as I tend to agree with you most of the time. ;-)


KrisBulman’s picture

Pretty cool that Zurb has offered support, if anything comes out of that I hope at least a Zurb contrib prototyping theme does.

I think there's enough documentation around Sass installation around that anyone who calls themselves a frontend developer should be able to tackle, not to mention the growing number of GUI apps out there for getting around the ruby problem (scout, compass.app, etc). I know it wasn't the point of chx's comment, but I'd gladly help anyone on linux, windows or mac get up and going with Sass & Compass. :)

I don't see much of a point for Sass being included in core though, except for maybe the benefit of core devs making module updates easier. And especially not a php compiler, which runs the risk of quickly being outdated.

However, if there was a good base theme solution in core modeled against something like Zen with a nice "starterkit" option to build out a subtheme from, I see great advantage of providing a handy inclusion of well written Sass files, along with some hand adjusted CSS that new themers could choose between.

effulgentsia made some great points in #81 around a theme component library, thanks for the tag! I could definitely see a benefit of a core style guide to help with the organization of reusable markup patterns.

chx’s picture

Status: Active » Closed (won't fix)

Based on #77/#78 and #84, this story is over.

pcoffey’s picture

http://basethe.me is my implementation of Twitter Bootstrap. I think we should all participate in a project like basethe.me, and not worry about putting one in core. there are licensing issues with putting Twitter Bootstrap in core, I believe.

dasjo’s picture

#88 also has a project application awaiting review: #1713614: Base Building Blocks

timmillwood’s picture

The main reason I would like to see a framework such as bootstrap in core is to resolve the issue of Drupalisms.

We could remove 90% of the core module's CSS and replace with bootstrap.css. Then all forms and other page elements will look good (and the same) across the site and any contrib modules will be able to follow the same design patterns.

When a frontend dev builds out the site's custom theme many elements such as the login form are left unchanged making the site look very much like Drupal. Would it not be better to make these elements look like Bootstrap?

DamienMcKenna’s picture

@timmillwood: That sounds like a great idea for contrib projects during D8 and then consider something for core for D9.

moshe weitzman’s picture

Status: Closed (won't fix) » Active

Er, Dries has said that he wants this for D8. He explained why, and how (a non-default, new theme). I encourage someone to implement what he said let the Dries and catch decide. It is pretty clear that we have no consensus even among the committers and thats OK.

jwilson3’s picture

Title: Add a Twitter Bootstrap-based theme to Drupal core » Add a new, non-default framework-based theme to Drupal core

Update issue title to relate the impartiality to the chosen framework emphasized by Dries.

Two things stand out in my mind:

* There is still not a lot of consensus on the target audience for this addition. Is it existing front end drupal devs? Is it to attract new front end devs? Is it to make the life of existing/new backend devs easier?

* There is still not a lot of consensus on whether Twitter Bootstrap or Zerb Foundation or X would best suit the needs of the target audience. Lots of votes for TB and for ZF, but also a couple very valid points against each. We have buy-in from a ZF developer, but TB is ubiquitous. Its a toss up to me.

UPDATE: also note that one person who's actually developed a twitter bootstrap theme for drupal still believes it is something for Contrib space, which sounds like it counts for something.

DamienMcKenna’s picture

As I mentioned on twitter, be careful of adding something in haste just so that it can be seen to have something. There's not a lot of time remaining prior to the feature freeze, many front-end developers are working on getting Twig into core, adding something that many of the target audience don't want out of a sense of haste would be the wrong thing to do.

Picking a framework-based theme needs to come from the front-end developers, helping them to identify their needs, then identifying something that matches their needs, is stable and GPL2-compatible; unless these goals are met we'll be doing a disservice to the people the functionality is purported to be for.

So, starting from square one: what are the needs that a framework-based theme would need to fulfill? Clean HTML5 output? Responsive layout? Easy to work with? Which of them are GPL2-compatible?

bleen’s picture

@moshe ... isn't it kindof a lot to ask for someone to create an entire (core-worthy) theme first and THEN to let Dries+Catch+Community decide wether its something that we should be working on in core?

I agree with chx that this issue should be closed unless the community AND the committers do come to some consensus that this is worthwhile to have in core.

And for the record, for several of the reasons pointed out by @snugug as well as @laura s's excellent observations in #76 I think this effort would be much better suited for contrib.

catch’s picture

webchick’s picture

Just to clarify, and maybe this is some of the disconnect...

"* There is still not a lot of consensus on the target audience for this addition. Is it existing front end drupal devs? Is it to attract new front end devs? Is it to make the life of existing/new backend devs easier?"

This addition would help the following audiences:

a) Back-end developers who couldn't make a decent-looking theme to save their souls.
b) Junior front-end developers who know their way around but not all the advanced stuff like responsive, WCAG, etc.
c) People already familiar with TB / Zurb who do not know Drupal's theme system yet.

It is definitely NOT for the following audience:

d) Highly experienced front-end developers, especially those who know their way around Drupal's theming system and how to get the markup they want out of it.

There is a huge representation of d) in this thread, which explains the enormous pushback that you're seeing. It also explains why it's compelling to Dries, since there are a lot more of a, b, and c than there are d.

DamienMcKenna’s picture

@webchick: Thank you for clarifying. I would, however, suggest that we have input from group d to help identify the best option, they'll be the ones best able to recommend the best option.

Also, for the question "which theming framework is suitable for including in Drupal core" it should also be acceptable that for D8 the answer is "nothing".

webchick’s picture

And FTR, I'm not opposed to using a framework in an optional core theme ("Stark - Zurb version" or whatever). I think that's a relatively low-risk way to introduce it, and it could always be swapped/augmented in later releases (probably even stable releases, given the direction proposed in #1787222-18: [meta] Strategy for updating vendor JS libraries within a major stable version) for the next hottt framework, if applicable. You have to realize that "There's a contrib for that!" is probably the worst answer you can give someone with zero Drupal experience. :\

However, I am definitely not convinced that it's a good idea though to go as far as the issue summary suggests and start modeling core's default markup after one of these frameworks, unless there's a clear winner out there. On those points, Sam et al are exactly right. We don't want to bake in the particulars of framework X into core's *.tpl.phps (or *.twigs ;)) unless it's something completely ubiquitous and all front-end developers agree on it, and from what I have observed there is no such thing. :D

It would be interesting though to get a similar technical run-down as #25 on Zurb Foundation. It's MIT, so we can use it without license concerns. The project lead is offering to help assist us as well.

c4rl’s picture

A clarification: As a member of audience (d) mentioned in #97, I am also very familiar with the current problems that the theme system has, and can say that my pushback is more based on trying to focus effort on fixing the existing problems and not bringing on board new equipment that does not necessarily solve existing problems and potentially causes new problems. My opposition to the proposition is not material to the object of the proposition, but rather affected by the existing environment (i.e. the state of core theme system in D7).

The core theming system we currently have has come about due to a very organic process of "Let's add X to core because X seems like a good idea" and after several years, there are too many options, too many APIs, not enough consistency. Additions made in haste have not proven virtuous. This current proposition feels like one of those moments, and after many years of saying "Yes" it's time to say "Let's wait."

Core has a valance attached to it. A newcomer might think: "If it's part of core, it must be good." Thus, if something is to be added, let it be something proven and robust. Contrib is a great proving ground.

With regard to core, while adding a front-end framework potentially helps audiences (a), (b), and (c), focusing efforts on fixing existing problems helps audiences (a), (b), (c), *and* (d).

c4rl’s picture

You have to realize that "There's a contrib for that!" is probably the worst answer you can give someone with zero Drupal experience.

I must say I disagree. When I first started using Drupal and took my first steps checking out the contrib space, it really opened my eyes to the dynamic and multi-faceted nature of Open Source. Contrib is what makes for a thriving community, IMHO.

Plenty of successful projects have come of age in contrib (Views, anyone?), and the first steps one takes to developing their own project will likely come about in a contrib or sandbox project. An advantage of which being when you want to create something, it won't be subject to 100+ comment discussion. :)

mjohnq3’s picture

I didn't see this mentioned here, and I haven't looked at it yet, but there is an active sandbox project for a Zurb Foundation 3.0 based theme - http://drupal.org/sandbox/ishmaelsanchez/1332338

laura s’s picture


We could remove 90% of the core module's CSS and replace with bootstrap.css.

Oh no, I hope not! Battling core css assumptions is something every themer faces in just about every project, and replacing it with betterer css isn't the solution. If we want OOTB pretty css in core, let it ALL live in Pretty Theme(TM) and let the rest of core be clean and free of presentational assumptions.


You have to realize that "There's a contrib for that!" is probably the worst answer you can give someone with zero Drupal experience.

That sounds like a problem with welcome wagon and culture, not with core. Is there an overarching goal of trying to make core into The Friendly Gigundo Monster That Won't Scare N00bs? The appeal of Drupal, as I see it, lies in its flexibility and extensibility via contrib.

Analogy: Nobody buys a smartphone and expects it to have all the apps they will ever want -- everyone understands that adding apps is expected. Can't we assume and cultivate the same understanding for people adopting Drupal, get them up to what us "old timers" have known and understood and embraced for years?

DamienMcKenna’s picture


You have to realize that "There's a contrib for that!" is probably the worst answer you can give someone with zero Drupal experience.

You'll have to excuse me if I pretend you didn't say that.

Core can't be expected to cover everything, that path is laden with gold-colored bricks.

webchick’s picture

LOL I see that comment did not make a proper translation from my head to my fingers, so just ignore it. :) The point is, the default experience core offers matters. It's the same reason c4rl and others are understandably nervous about picking the wrong framework here, and especially as making Drupal core's default markup conform to it. It's also the same reason Dries and others advocating for those not in category D) feel strongly about offering it as an option out of the box.

RobW’s picture

So we don't keep on saying the same things, can we all agree that:

  1. Integrating a 3rd party css framework (Bootstrap, Zurb, etc.) into core default markup (what pops out if you have an empty theme directory and an info file) is off the table, at least in this issue.
  2. This issue is about choosing a css (prototyping) framework to create a non-default base theme with, to show new/ new to D8 Drupal users that Drupal's markup can be altered for any front end purposes, give an example of how that can be done, and give those who want to use the framework for their project (a rapid prototype, minimally viable product, or something that looks good because they're learning/ not super proficient with css) a good base theme to start with.

If so I'll write a new issue summary so people don't get the wrong idea from the current one.

Crell’s picture

If the end result of this discussion is "just another core theme that just so happens to use Bootstrap/Zurb/Zen Grids/Whatever to prove that it can be done", build it in a sandbox and submit it later. Don't work directly in core for that. Since that's not new *features* I could even see that post-1 December. If it doesn't get in, fine, we have D8's first contrib them ready to go.

The idea that having a major-CSS-framework-based-theme in core that is self-contained to just that theme somehow makes Drupal automatically friendlier toward CSSers is, I think, silly. If someone wants to use such a base system they should certainly be able to do so (as one of those backenders who couldn't design a theme himself to save his life, I can see where I'd find it useful). But that wouldn't mean they know Drupal, just that they know they could use Bootstrap with Drupal. As they say on Twitter:

"Oh, hey, this theme uses Bootstrap so now I know how to theme for Drupal" --No one, ever

Putting another theme in core prematurely only makes more work for the Twig conversion folks, and slowing *that* down is the worst possible thing we could do, especially with less than 2 months to feature freeze.

markabur’s picture

#88 shows what it takes to use Twitter Bootstrap in D7. It's worth a look. It does a lot of contortions to bend Drupal's html to fit with TB's css. I don't know if it is a good demo of how easily Drupal's output can be tweaked to fit a framework; however, it does show that (a) it's possible, and (b) it's possible without hacking core.

I never actually heard of Twitter Bootstrap before this issue, and in general I'm unfamiliar with the world of premade themes (my projects always have custom ones), but I can see the attraction: if your CMS emits Bootstrap-compatible HTML, then you can simply download a premade stylesheet from a site such as http://bootswatch.com and restyle your whole site without any coding effort at all.

I have no idea if TB stylesheets are easy to create, or if the TB layout system is flexible enough to be used for custom theming, or if its CSS is a hassle to override, but I don't think any of those things matter if the main goal is to make it possible in Drupal to use a theme from Bootswatch.com (or whoever).

With this in mind, I tried making a subtheme of #88, like so:

name = Cyborg
description = A BaseBuildingBlocks subtheme
core = 7.x
base theme = BaseBuildingBlocks
stylesheets[screen][] = bootstrap.min.css

...and included the "Cyborg" bootstrap.min.css file from Bootswatch. I did get some subtheme-related errors about missing tpl files, but overall it worked fairly well -- enough at least to see the potential.

Considering that subtheming is pretty advanced stuff, and the person who downloads a theme from Bootswatch is probably not an advanced themer, I feel like subtheming is a bad fit as a general approach to Twitter Bootstrap in Drupal.

I think that ideally the theme would have a filefield so you can upload the bootstrap.min.css file you've downloaded from wherever, and *bam* your site is restyled. I wonder if this would be a way around the licensing issues -- what if the Drupal TB theme is just a compatibility layer and doesn't actually contain bootstrap.css until a user uploads it? (Though I guess we still have to include the standard icons, and possibly the javascript.)

DamienMcKenna’s picture

Status: Active » Postponed

How about we postpone this, let everyone focus on a) finishing the twig support for the code freeze and b) work on some example code in separate sandboxes, and reconvene later on to see what's worth considering?

DamienMcKenna’s picture

Issue summary: View changes

Updated issue summary.

RobW’s picture

Issue summary: View changes

revise with current state of issue

pcoffey’s picture

Can you make an issue on github for the errors you found while using Base Building Blocks as a parent theme? I'm trying to get all the kinks worked out. :)

Are there others on board with a filefield upload of the bootstrap.min.css file? The main problem with this is it would make it difficult for you to edit Bootstrap's less files. I was thinking about using a grunt file for less compiling and everything, but I never considered having users upload their own bootstrap stuff. Is that something others would want?

Also, Base Building Blocks does a lot of work to make it easy for people to theme drupal. It makes it easy to make content-type, and node ID based template files, adds the Chrome Frame and IE edge as an option, includes a set of default media queries to encourage responsive design, has a really nice Bootstrap administration menu, includes cool stuff like Font Awesome, Modernizr, and HTML5 Boilerplate. It has been a helpful tool for me. But I'd really like to make it better, so is it possible that you guys could hit me up with some ideas? I'm working on building a new version of http://basethe.me, with better documentation, and I'm even working on adding some new features, like automatically generated Apple Icons, more retina (hi-res) image help, google tools, some default administration blocks, and a better role-based admin menu. but it would be really helpful for people to submit ideas and collaborate. It's a pretty good start I think, and I like it a lot better than Omega, or Adaptive Themes, but we could make it into something that is awesome. Just hit up the github and lets collab on it!

pcoffey’s picture

See #110. :)

lightsurge’s picture

I love Base Building Blocks apart from that it doesn't provide an end-user top navbar, only an admin navbar. And even the admin navbar is not sticky by default.

That seems a real shame to me, because the sticky top navbar is a big selling point for twitter bootstrap, as I find it looks great and improves usability on both desktops and tablets/smartphones. And I've seen in a few places these menus being touted as a big improvement of user experience, and it seems to take that best practice into account. Here's one:


In the lullabot bootstrap fork of drupal.org/project/twitter_bootstrap I have such a navbar I can utilize ootb without any coding.


It would be good to see the best bits of all three going into the existing bootstrap theme project on drupal.org.


As Snugug pointed out in #25 most of the components are either inaccessible or plain broken on mobile (the modal, the dropdown, the navbar, etc.) I dont think anybody here is comfortable to bring broken code into core.

I honestly haven't had this experience at all with bootstrap. The navbar worked differently on mobile, rather than sticking links across the bar it mimicked a smartphone 'settings' icon in the top right which then dropped down to show the menu contents... which seems like a neat idea to me! It avoids the alternative of having device spanning pills that users have to scroll past before getting to any actual content. Didn't try the modal though.

As far as Zurb goes, looks great as well although it'd be nice if like bootstrap we had some kind of example of it being used with Drupal.

moshe weitzman’s picture

Status: Postponed » Active

Please don't bully people into working on projects that are important to you, and working outside the core issue queue. I understand that some folks think that Twig is more important than this issue. Thats fine, they should work over at #1696786: Integrate Twig into core: Implementation issue. Everyone scratches their own itch. If we get the Twig engine into D8, I will personally convert this theme to it.

Snugug’s picture

Status: Active » Closed (duplicate)


The issue a bunch of us have with this is that, despite the fact Dries wants this, it's not something that Drupal Frontend thinks is beneficial to Drupal and doesn't seem to actually solve the problems presented. That's why Frontend is directing people toward Twig. Saying that we shouldn't be directing people to the actual Twig issues needed to accomplish Twig and instead pointing them to Core issues that require Twig finished seems silly to me; putting the cart before the horse so to speak. The real work on Twig is being done outside the Core issue queue (as VDC was) and therefore IMO it's totally fine to point people there.

If, however, you'd truly like to stay in the Core issue queue, and you'd like to solve the actual underlying issues that brought this issue to light, what we should be pointing people to is #1804488: [meta] Introduce a Theme Component Library. Moreover, considering this thread is actually now a duplicate of #1087784: Add new theme to Drupal 8.1.x or another minor version (another Core issue), shouldn't we bring the conversation back over there, mark this as Closed (Duplicate), and move on? Actually, come to think of it, I'm going to be a good Drupal citizen and do just that.

pcoffey’s picture

I created the navbar as an admin bar only, because it's easy for users to create their own navbars. I'll make it sticky though, good idea!

moshe weitzman’s picture

Status: Closed (duplicate) » Active

That thread has no Summary, no activity, no plan. This one has all of those things, including approval from Dries. Further, that one is about a pretty design, whereas this one is about adding a prototyping and tech demonstration theme. The design is not a critical component. These are not dupes IMO. Once we have a Theme Component Library, we can close this issue.

Snugug’s picture

Status: Active » Closed (won't fix)

Once we have a Theme Component Library, we can close this issue.

That, to me, sounds like one of two things: either marking this as postponed until #1804488: [meta] Introduce a Theme Component Library is complete for us to close it then, or closed (won't fix) with the understanding that #1804488: [meta] Introduce a Theme Component Library takes precedence over this, makes this irrelevant, and is more useful to Drupal as a whole. That quote says basically one and only one thing to me: this shouldn't be active.

RobLoach’s picture

Status: Closed (won't fix) » Postponed

So let's post-pone this discussion then? Would be unfortunate to lose the opportunity to work with other communities.

lightsurge’s picture

#115 @pcoffey

I'm guessing you mean just adding navbars via markup? That's not exactly what I meant, I meant users adding a non-admin menu navbar through the core menu system without having to write any script. It doesn't look that trivial to me to for end users to add bootstrap navbars that integrate with the menu module eg.


and in your theme it doesn't look like you had a particular easy time either:


Seems there's a lot of disdain for this sort of thing to go in 8.x right now, though, which is over my head, but for what it's worth (which is probably very little, really), I figure all themes have to make certain contortions to make them work, so that's not out of the ordinary.. this one would create plenty of contortions, but if the theme component library is intended to alleviate those contortions, what's wrong with having another more varied working example in core of the contortions that need to be alleviated? Once they are those contortions can just be removed? And if the theme component library doesn't make it into 8.x, having this sort of theme in core could help along interest in developing the theme component library in contrib, in order to remove unwieldy code?

Don't know if the answer to that might still be 'no, it's still better in contrib', but part of the release of a product, to non-techies anyway, is (perhaps unfortunately) also about what's visibly new rather than just what's more streamlined. I know that's a pain because the less immediately visible stuff is generally harder to do and a bigger achievement... but if someone's wanting to work on this to such tight deadlines and will make it core-polished in that time, I don't see what harm it can do... especially since most of the argument against seems to be about the effort being better placed elsewhere, if that's not going to happen anyway and instead this effort just gets frustrated, I don't see the point in that. I'd rather have a new theme in core instead, I don't see how that would be the end of the world.

If the group behind this issue don't need the help of those that think other projects are more important, rather than postponing this why not let them create a patch, and if still passionate about it being detrimental, give it a grilling review instead? :)

I would put this back active but I'm a bit scared (and don't really have the conviction of my understanding!).. and the to-ing and fro-ing seems to have got a bit silly.

effulgentsia’s picture

If the group behind this issue don't need the help of those that think other projects are more important, rather than postponing this why not let them create a patch

+1. Regardless of the status of this issue, what I think is non-controversial is that a TB base theme and a Zurb Foundation base theme being available (ignoring for the moment whether it's in core or not) when D8 ships would be appreciated by lots of people, and could greatly help adoption of Drupal. So I highly encourage people who want to make this happen and have the needed time and skills to contribute to organize and do so. Looks like there are already a couple overlapping repositories where this is underway, which is fine, but if folks here can agree on a canonical one or two and link them in this issue's summary, that might help channel energies better. Once there's a concrete implementation that enough people are excited about, I see no reason not to at that time re-open this issue for whether to add it to core or not, and meanwhile, if in the process of creating this, problems with core's markup, css, or theme system are identified, please submit those issues to the core queue.

pcoffey’s picture

I condensed all navbar-related functions into a re-useable function, so by printing BaseBuildingBlocks_build_navbar('menu-name'), you will print a navbar of the name passed in.

Concerning putting bootstrap into Drupal as core, I don't think it's a good idea. It's easy enough to build a bootstrap theme and add it to your site.
If Drupal is going to make any changes related to the theming system, it would only make sense for them to make the theming layer easier to use and more (easily) pliable so that we could build bootstrap themes easier, but adding a theme in there that does the fancy footwork for you, well, there's no reason to have that in core.

lightsurge’s picture

I condensed all navbar-related functions into a re-useable function, so by printing BaseBuildingBlocks_build_navbar('menu-name'), you will print a navbar of the name passed in.

Brilliant, thanks!

It's no big deal for me whether this is in contrib or core, but I don't deny the 'saleability' logic. Drupal theming revolution aside, we already have Bartik/Garland, the look of which I agree has probably become synonymous with Drupal, and the traits of Drupal's theming evolution naturally spider off into contrib as well. Which is fine, but like I say there might be some benefit in having a theme that bears none of the traits that specifically betray a Drupal theme, in order to broaden out the range of Drupal's initial stock themes. Sort of like 'here's a Drupal theme example (default and with pride), and here's a mainstream, non Drupal-centric, theme example, Drupal can do both'. As you've proved :)

jwilson3’s picture

I condensed all navbar-related functions into a re-useable function, so by printing BaseBuildingBlocks_build_navbar('menu-name'), you will print a navbar of the name passed in.

Not to derail, but just a side note of where things are going:

Lots of the theme functions eg, for generating menu lists, is already being considered... Meditating on this, its almost a great example of where expanded use of template suggestions could work on theme functions in *specific regions* via template inheritance. like...

// this code doesn't work today, but maybe it could, one day ?
mytheme_item_list__menu__region_navbar() {
// adjust the html of this specific menu as necessary for the custom TB navbar.

UPDATE: Here's a link to RobW's comment about template inheritance via theme suggestions. Amazing work there.

lightsurge’s picture

Another sidenote, I've been championing bootstrap's fixed menus on mobile, so thought I ought to point out I'm in error there, it's not supported.


This appears to have become relatively stable on jquery mobile (with the expectation that it'll still look miserable on certain devices) with just graceful fallback to static positioning where position:fixed is known unsupported:


but it's no surprise it'll take longer for desktop/mobile responsive frameworks to follow suit. Crud :(

pcoffey’s picture

That's pretty easy to do with a little css...

lightsurge’s picture

@pcoffey so long as you only apply that css for devices that support it, I ended up using the blacklist function in jquery mobile.

pcoffey’s picture

Checkout the @media queries in Base Building Blocks app.less file. :)

tonystar’s picture

110.41 KB

I've just created Tweme - alternative responsive theme based on Twitter Bootstrap.

It contains much less lines of code than twitter_bootstrap theme does, but also integrates basic theme elements and even provides automatic built-in ScrollSpy navigation for content region.


May be it could be a good candidate for core theme in the future.

Crell’s picture

It looks like we're past the 15 October deadline mentioned in the issue summary, and there's still no resolution on the licensing front (per the github issue linked above). That means this issue still cannot move forward, legally.

I think that torpedoes this issue, and also blocks contrib themes, too.

cweagans’s picture

Status: Postponed » Closed (won't fix)


tonystar’s picture

So, correct me if I'm wrong. Could we use Twitter Bootstrap in contrib themes?
I mean if TB will not be in the package and user should download it separately.

hixster’s picture

Should be correct - isn't that how the Twitter Bootstrap theme deals with this already?

wundo’s picture

Yes it's.
The user has to manually download bootstrap files when he installs the theme.

sun’s picture

It is sad to see that almost no one read the issue summary, and literally no one understood the actual purpose of this proposal. Neither themers nor developers.

Both groups will continue to complain, and whine, hard, in the future.

Both groups will continue to re-invent fancy wheels, to introduce new Drupalisms.

But yet, either group does not care for any other, and fails to see the actual problem space.

You forgot about usability. You forgot about design. You forgot about common sense.

You forgot about countless of currently existing issues with more than 100+ comments, each, which are trying hard to make sense of patterns and utterly fail to do so. Because they do not know better. Because they are lacking guidance. Because they fail to see beyond the horizon of Drupal. Because they fail to see that there are a plethora of things that everyone and the world knows about and takes for a given. Just not Drupal. They have to re-invent — each and every effin' wheel — all over again.

That's the stuff you will have to deal with. All of you.

Almost all of the nay-sayers are not involved in any of those issues. It is beyond my understanding why you even commented here.

All I know is that you made sure to allow yourself to continue the whining and complaining. I'd remind you of this issue, but you do not participate in any of the other issues and thus you don't try to solve any of Drupal's actual problems either way.

You're scratching your own itch. That's all you do. And you're smart enough to think the world is flat.

You successfully prevented Drupal core to advance. See you again in 2016. And don't forget to wear this badge.

c4rl’s picture

@sun I understand that you are frustrated. Despite this, comment #134 is provocative, overly dramatic, and criticizes of the participation of others. It doesn't add value or clarify anything about this issue, nor does it encourage others to support the issue proposition. I would encourage that you review the Drupal Code of Conduct. http://drupal.org/dcoc

Furthermore, you haven't participated in the issue comments since the day the issue was posted, which indicates to me a lack of effort on your part to clarify or explain the proposal better in order to assist those who did not understand the "actual purpose of this proposal." In the future, I would encourage that you participate more to dispel others' misunderstanding.

With regard to the actual issue itself, I think a stronger presence of a ubiquitous Bootstrap-driven contrib theme would likely garner more support for inclusion in core in the future (Drupal 9, perhaps).

DamienMcKenna’s picture

@sun: We read the *original* issue summary and disagreed with it based on the merits of the *original* request, i.e. the people who had actually examined the Bootstrap theme thought it sucked. Per @crell in #129, the requisite analysis was not done to identify the best option, thus no action was taken.

sun’s picture

Understood. Please also understand that I can't be everywhere, and also, that I'm actively listening to concerns, and that I do not propose any changes without prior in-depth consideration, unless otherwise stated. That said:

Let me turn it around:

TB would have helped to provide web/design/UX guidance that's hard to find for a lot of issues. Since we won't be able to learn from it directly, we will do so indirectly.

Let me abuse this issue to reference other issues that are struggling with common concepts and patterns. I'll try to keep you posted, but can't promise to hit 'em all.

The tour starts with: #1238484-116: [docs update] Ability to mark the form buttons to be of a specific type (so that they can be styled differently)

Additionally, make sure to frequently check and follow the Needs Themer Review queue. Issues will get tagged with that. Changes lacking reviews ultimately will get committed, regardless of themer review.

sun’s picture

Issue tags: +Web Design Standards

Even better.

moshe weitzman’s picture

FYI, the license issue is resolved. TB has moved to the MIT License which we can relicense as GPL in our repo. See https://github.com/twitter/bootstrap/issues/2054.

Would be great if someone picked this back up. Hopefully the Twig folks can just do their own thing and let folks work on what they think is interesting.

moshe weitzman’s picture

Status: Closed (won't fix) » Active

Reopening since license issue is resolved.

cweagans’s picture

Status: Active » Closed (won't fix)

TB hasn't relicened yet, as far as I can tell.

Also, I think the reason that this was won't fixed was the level of pissing and moaning about how Twitter Bootstrap wasn't "the best" and how frontend developers hate it. Personally, I think this should still happen, but seeing how we're only a few days away from Feature Freeze, I don't see how it can.

tim.plunkett’s picture

Status: Closed (won't fix) » Active


Let's let others decide on what they want to work on, now that it's legally feasible.

cweagans’s picture

Status: Active » Postponed

Am I missing something? The license still isn't changed. There has been no movement. We can't do this yet, so if won't fix doesn't work for you, then postponed.

I'm assuming that you guys are seeing the GPLv2 license link at the bottom. That's unrelated to Bootstrap licensing - that's for lessphp

dodorama’s picture

Status: Postponed » Closed (won't fix)

This issue was marked as a Won't fix because way beyond the Oct 15th deadline established in the issue summary.
Given that and the animated discussion that it created, I think it is starting to be rude to keep re-opening it.

Bootstrap is awesome and everything but it's a huge, complex framework and it's irrational to believe that it can be integrated 4 days before feature freeze. Those who still believe and want to keep this going need to break this in smaller, actionable issues, create consensus and being mindful about the frontend community.

Crell’s picture

Per that thread, cweagans is correct. Bootstrap is still not legal to include in Drupal core.

Looking to Bootstrap for design suggestions is all well and good, but that can happen in other issues. This issue is still legally not possible, so cannot move forward. Any other "moaning and whining" is irrelevant.

lightsurge’s picture

I think people may be getting distracted by the last comment in the github thread quoted, which relates to lessphp being gplv2 compatible and therefore not a blocker to twitter bootstrap being relicensed.

I say this because when I initially saw that comment, I briefly got excited that bootstrap had become compatible, but that's not the case.

amaree’s picture

This is a great move... however I feel that one template is not enough... Joomla 3 is out and it has bootstrap integrated into the backend as well as front end I have right now a complete responsive admin interface to give to clients from Joomla3 and they have also gone the way of including admin UI components so extension developers do not have to create there own HTML/CSS etc they can use core calls? I am concerned that Drupal is touting mobile friendliness but it will only be half implemented?

DamienMcKenna’s picture

@amaree: You don't need Bootstrap to have a responsive admin theme, there's other work going on to make the admin interface fully mobile friendly.

LewisNyman’s picture

@amaree, One of the aims of the Mobile Initiative is not just to implement a responsive admin theme, it's to make a great mobile UX. Simply integrating a responsive framework does not guarantee a useable experience. The work we are doing in Spark and the Mobile initiative got way beyond simply unfloating everything.

But you do make a good point about a more robust admin UI framework, providing enough components so contib developers don't need to write any CSS would result in a better and more consistent experience.

charlie charles’s picture

I thought this was a good article
why not to use bootstrap theme

5 Reason Not To Use Bootstrap


Everyone saying at moment sass is
better than less

sass vs less



Bootstrap only use's less while
Omega use's sass already

Twitter Bootstrap 3 vs Foundation 4 – Which One Should You Use?


Foundation 4 offer better features than bootstrap 3

charlie charles’s picture

Issue summary: View changes


JohnAlbin’s picture

Given that Drupal 8's new semantic versioning makes it possible to add a new base theme in a later 8.[1,2,3,…].0 release, we could add a new hot-framework-of-the-moment base theme to Drupal 8.1.0 without changing any APIs.

Given the contentious conversation in the comments above about specific frameworks and whether or not it would be the default theme implementation, let's create a new, clean issue to continue the discussion.

See #2289619: Add a new framework base theme to Drupal core

sonicthoughts’s picture

ok - 2 years after this discussion began and 1%+ of the web is now using Twitter Bootstrap. Technical arguments aside, it is a great bridge to attract non-drupal devs and allow system builders to move far without involving developers.

giorgio79’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Closed (won't fix) » Active

Maybe for 8.1?
Bootstrap is now relicensed! https://github.com/twbs/bootstrap/issues/2054

Just like the argument was made at many other places, eg

  • Drupal should not be in the business of creating a testing framework but use phpunit
  • Drupal should not be in the business of creating a low level stuff but use symfony

Drupal should not be in the business of creating front end frameworks. Perhaps 2-3 core themes based on bootstrap, foundation etc would be great and that's it.

bill richardson’s picture

IMHO is is unreasonable to expect core to maintain any additional themes -- contrib will provide themes based on Bootstrap or whichever frontend framework is popular NOW! or in the future.
The changes made by the consensus banana team will make it easier for contrib to achieve this.

Joomla was raised as an example -- they only maintain two themes ( admin / frontend ) , and even though bootstrap is used in Joomla core most of the Joomla template shops have designed their own frontend framework to build the themes that they sell ( ie. not bootstrap -- T3, Warp, Gantry5, etc ).

joelpittet’s picture

Status: Active » Closed (won't fix)

Agree with Bill 100%

markcarver’s picture

Version: 8.1.x-dev » 8.0.x-dev

I do not agree at all. However, I'm only closing this issue (to its original status) because (edit: heh Joel beat me to it) there is another open issue about this #2289619: Add a new framework base theme to Drupal core. I will post my reply there.