[Meta] Port bluecheese to Drupal 7

any guidelines to get the files ? Would like to have a look at it.
(EMPTY) http://drupalcode.org/project/bluecheese.git

We want to keep the theme as clean as possible, so we don't have a mess to upgrade. Anything we can shift to be more Drupal-7-like should be done. We want to minimize the actual time we are maintaining Drupal 6 and 7 branches.

I vomit every time I see or hear the name of this theme. Use it? never, makes me vomit to read the name.
IMO,, I think a name change is in order when porting is done.

The best way to help out is dev sites, http://drupal.org/node/1018084, which is how most Drupal.org improvements have been done recently.

Before jumping into Omega, I want to be sure that's a good idea. It looks like some big sites are using it, which is encouraging. I also like the idea getting some basic responsive functionality at the same time. However, we want to minimize the effort it takes to bring over the old styles.

@dbeall, #4: Here you go Dave :P

I'm actually against using a base theme like omega. It's not like we lack skills and knowledge to create a custom solution. And this is a custom solution.

The problem with base themes is that they add a lot of overhead that we may not even need. They also make a lot of design decisions for us. We need to define our own responsive break points instead of inheriting a default set of break points. That's not good design.

Responsive design is not a tick box problem, it's a design process.

I have the same concerns as lewisnyman. I talked to the Omega maintainers at DrupalCon and one immediately said they needed to work on front-end performance before going to Drupal.org, and to give them a few weeks for the next release or two. They seem very competent and motivated. I want to wait and see what happens.

For maintainership, we may have skills, but we do lack time. This issue queue is full and I'm the only one who has been committing recently, and I'm not a themer. No consistent contributors have been taking on the small tasks. Our infrastructure and access hasn't been great in the past, but we are doing better than ever with http://drupal.org/make-drupalorg-awesome and real dev sites to work on. Even if the D7 effort doesn't bring consistent contributors, we still need the burst of effort to get this done.

We do want to keep the theme simple. We don't have any custom page layouts in the theme layer, so we can skip delta. Offloading the basics to a base theme means less custom work to maintain. But, if the base theme gets in the way, we could end up fighting it. I can't say that either route is definitely good or bad today.

Look, Omega is easy to maintain, it comes with a lot of stuff that we can use to get a Drupal 7 version of bluecheese running quickly, and lastly, we should not try to reinvent the wheel. If there's stuff in Omega that we don't need, we can turn it off. That's what makes it really nice - it doesn't make the assumption that you're going to use everything.

Design is not about reinventing the wheel. It is about delivering the most appropriate solution for the problem at hand.

Every wasted kilobyte we add to the front end is more wasted time for every mobile and desktop user. We can't make the front end heavier than it is now. We'd be taking one step forward and two steps back.

I'd like to understand the logic where a more bloated and redundant code base is easier to maintain? If we are going to turning off most of the features anyway what is the point of using this base theme?

I'd rather we took our time doing it right then rushing something out and making poorly informed choices that might actually harm the mobile user experience.

Slapping a couple of media queries on something does not make it responsive. Making something responsive does not make it a good user experience.

Here's the thing: Drupal.org is a gigantic mass of code specifically built for Drupal.org. That's a really bad thing because Drupal.org is not using the tools that the community has provided, and we're duplicating a lot of effort. I can understand the desire to not use a base theme, but I think in this case, it's a bad decision. We need to optimize for developer time and NOT CPU/network time. Network connections are getting faster and cheaper.

If we can leverage the code that's already written, then we have less Drupal.org-isms to worry about, and ANYBODY that's familiar with the Omega theme can jump in and start working quickly.

Omega has already been accepted by many large companies, including Acquia, Maxim, Maclife, MaximumPC and GuitarWorld. If we (Drupal.org) set a precedent of ignoring the tools that are available to the community and instead prefer to build our own, then how can we really complain about, for instance, duplicate modules?

I suspect that you've never actually played with Omega and are just complaining because it's a base theme. If that's the case, then I'd ask that you spend some time developing a theme with Omega so that you can make an informed argument.

I wasn't making an argument for development time here. This is a design decision.

We need to optimize for developer time and NOT CPU/network time. Network connections are getting faster and cheaper.

Personally I believe that we should be optimising Drupal.org for the people using it, not the people who are making it. Considering we are meant to be optimising for mobile I'm surprised you think network connections are getting faster and cheaper. On mobile they are slow and expensive.

By all means let's no recreate the whole world from scratch. Fluid grid system? Pull it in. CSS normalize? Yep. Should we disable some of the default Drupal core css files? Totally.

Pointing to a few big sites that use Omega doesn't prove anything. How many of those examples are responsive? One. How many examples do responsive well? None.

I've played with Omega. I'm not saying it's not quick to get up and running but if anyone thinks they can "enable responsive design" by changing a couple of form options is missing the point. I've counted about five breakpoints for the home page header alone.

I agree with @lewisnyman that this is a design decision and @drumm that the base theme will likely end up getting in the way. This has been my experience. Base themes are not always a win, and if they are a win it's definitely not automatic. Ultimately, I think what @lewisnyman is saying in #16 is the best way to go about this.

I don't have anything against Omega, but by making it a dependency you make those contributing have to learn Omega-isms and then mess with them before they can move on and get the task at hand done. Since Bluecheese already exists for D6, and was completed not so long ago, wouldn't changing to use Omega be a big deal architecture wise? I don't know, but I'm guessing the structure of Bluecheese is pretty different than Omega. Base themes also have the luxury of changing dramatically from one major version to the next, which could have a negative impact on this effort. I guess the better question to ask here is what is it about Omega that makes it the right decision for implementing BlueCheese?

That's my 2 cents.

The Omega roadmap is well-defined. 4.x _will_ introduce significant changes but 4.x is not likely to be released until D8. So concern that sweeping changes will occur soon and cause issues in D7 is unwarranted.

I'm not saying that sweeping changes will definitely occur, just that it is a possibility to consider, and one that would not be an issue at all if there was no base theme. I'm not really arguing for or against Omega in all honesty. I'm really just saying that having a base theme complicates things, and that those complications should be considered as part the the decision making process here. You cannot guarantee the roadmap of Omega or any other base theme. Things are rapidly changing in the front end community. Personally, I wouldn't want to see Omega maintainers have to worry about factoring Drupal.org in their implementation either.

I can't speak to architectural changes, because I haven't seen the Bluecheese theme, but the bottom line is that I'm not convinced that a base theme (no matter which one it is) would be beneficial for the d.o. design. Ultimately, I think this decision should be up to those that will work on and maintain the theme.

listen up building a site like d.o on omega/adaptive/mothership whatever is imho a really bad idea
All basethemes have its fans & thats all good n sweet, but tbh D.O need a solution thats not based on this months flavour & can be build by a dosent of different frontend developers taste.

I think Jacine hit the nail on the head:

Ultimately, I think this decision should be up to those that will work on and maintain the theme.

If I were to get involved I'd probably be against using a base theme for d.o, but unless I actually start to work on this, my opinion shouldn't matter as much.

For now, the only person who's stepped up to create and maintain the D7 bluecheese theme is banghouse, and he wants to use Omega. Omega also has the benefit of more people than banghouse knowing how it works. Unless there's another group of people willing to step up, I'm not sure I see a compelling reason to go our own way on this.

@webchick IMO (based on years of experience of having to work with base themes even when it made no sense) a theme that uses a base theme is harder to maintain than a theme without in most cases, and not right for every situation. In this situation, you also should to think about future contributors, that may or may not be familiar with Omega. It may not be compelling to you guys, that's cool. Just here because I was asked to give my opinion on the matter, and I've done that, so I can leave now.

@banghouse Kudos to you for stepping up to help with this.

kthxbye :)

Yeah, I hear that. Not using a base theme for the D6 version of Bluecheese didn't seem to result in more contributors, unfortunately. :( I'm not saying that using a base theme will, either. I genuinely don't have a preference/stake in this race here, other than a general desire to empower the do-ocracy. :)

Ultimately, I think this decision should be up to those that will work on and maintain the theme.

Yeah, but people thinking about taking this task might be waiting on a final decision on this matter before they step up to it. So, depending on if we decide to use a base theme or not or even if a specific base theme or another should be used, we are either "inviting" volunteers or "chasing them away". It's a chicken/egg thing I say :/

For now, the only person who's stepped up to create and maintain the D7 bluecheese theme is banghouse, and he wants to use Omega. ...

No offense intended, but we should be recruiting people that accept to work on this (or any) task after they've accepted the decisions made on how to get this task done. We shouldn't be accepting (or even considering if you ask me) "offers" to work on a task only if certain "demands" "specifications" laid down by the assignee are met. It just seems wrong to me.

This is volunteer work and people offering to do things are allowed to freely change their mind (usual reason being Real Life™ taking over) and quit. This is not done gracefully in every case and doing things a specific way may limit our options to find replacement maintainers if this ever happens.

If we are to use a base theme, then we'd better include one in core and make sure that it is maintained (including it in core kinda "forces" us to put more effort in that task). If Omega or any other theme has made great breakthroughs in specific areas that we deem to be candidates for inclusion, then their code is available right there for us to check and perhaps "borrow" these specific parts (instead of spending time redoing things). Consider this as adopting certain best practices. We don't necessarily need to use the whole code in bulk though. Also, the maintainers of these themes are there to help us incorporate this or that feature in our core base theme whenever this need arises or even to become (co)maintainers if they have the will and time.

I kinda agree with what klonos is saying in 26. I'd like to point out that some people showed desire to make Bluecheese adaptive earlier: #1435260: I want a drupal.org development site for making bluecheese adaptive, #951114: Support all screen sizes and already have a dev site for that. So there may be indeed more people with desire to work on Bluecheese, which are waiting now because it is not clear whether we are making D6 Bluecheese adaptive or only D7 and how exactly we are rewriting Bluecheese to D7.

So I think first thing we need to do is reach consensus on - are we making D6 Bluecheese adaptive or if we go straight for D7 version. Presumably the latter is an answer, then we can close those other issues and invite all interested people over here to discuss how exactly to work on D7 Bluecheese.

Personally I support those who are against using base theme and echo all their concerns.

We want to do both. Make it adaptive/responsive and port it to D7. We have a sprint in Portland April 23 - 27 at which time we're going to attempt to get a metric butt-load of this upgrade work done, including (hopefully) the theme. I really don't want to make this an arms race of "whichever team gets it done first wins" but we absolutely have to have a decision by that date, and really basically by next week because that dictates who we fly in to help with the theme (if anyone).

I see enough nay-sayers here to form up a team, but see no team being formed and no work being done. I also see no commitment from the nay-sayers that they are planning to maintain the theme over the long term. Both of which make the custom theme route pretty risky from where I sit. Happy to be proven wrong.

Oh, and in terms of responsive or adaptive before/after D7, since porting to D7 essentially requires re-writing the theme anyway due to all the various render API stuff, I figured it made sense to couple those two things together. But I would tend to leave that decision up to the people doing the actual work on what they think is best.

Yeah, but people thinking about taking this task might be waiting on a final decision on this matter before they step up to it. So, depending on if we decide to use a base theme or not or even if a specific base theme or another should be used, we are either "inviting" volunteers or "chasing them away". It's a chicken/egg thing I say :/

No, banghouse has been working on the theme and has continued to work on the theme. You just think people have been waiting on a decision :)

No offense intended, but we should be recruiting people that accept to work on this (or any) task after they've accepted the decisions made on how to get this task done. We shouldn't be accepting (or even considering if you ask me) "offers" to work on a task only if certain "demands" "specifications" laid down by the assignee are met. It just seems wrong to me.

To be quite frank, this statement really upset me. What it really boils down to is that if you are going to do the work, then you can choose how it gets done unless there's a compelling reason to do it differently. So far, there have just been nebulous, unsubstantiated statements about how base themes reduce performance and they're harder to maintain and that they're just "bad". In my opinion, these claims would have a lot more validity if they were backed up with numbers/benchmarks.

Making Drupal.org responsive is not a requirement for the Drupal 7 upgrade. Adding requirements like that is scope creep and will delay the launch. Once we have a basic upgrade working well, we will launch that.

If we are able to get some foundations to do more responsive work later, that's great. If the basic upgrade is working well, and something else is blocking, then it makes sense to spend some time on making pages responsive. Using Omega won't make our site responsive just by using it; we have to put work into deciding what is really important on each page and how to present it on other screen sizes.

#951114: Support all screen sizes should stay a separate issue. Hopefully this issue will be a big help, but if any trade-offs need to be made, they should favor a basic upgrade until that is done.

I understand, but we're going to have to rebuild the theme anyways. Doing that with Omega will make it easier to support all screen sizes, even on a very basic level. We can improve the support for smaller screens over time, but if we don't make it responsive as part of the upgrade to 7, I fear that it will never get done.

I'm going to throw my hat in and say we absolutely should not be using Omega. We are a smart enough bunch to be able to roll media queries on own own, not to mention the fact that Omega is a super heavy, not to mention adaptive theme and if we want a true responsive design, we need to design Bluecheese to be responsive, not stick in a few device media queries and call it a day.
Omega has done a great job of brining the buzzword of responsive to the Drupal community, but it is a bad responsive base theme. If we're going to make D.O responsive, we should do itright. We should start with a mobile first design approach, not just DOM order, with clean, semantic HTML5 markup (which Omega is sorely lacking), an eye toward overall useably, and break points where our content dictates where they need to be, not where devices widths change because, and I cannot stress this enough:

RESPONSIVE DESIGN is about a website looking its best REGARDLESS OF THE DEVICE it is viewed on, and by its very nature of its adaptive solution, Omega is BUILT TO SPECIFIC DEVICES

.

A proper, device independent responsive design starts with a fluid grid, doesn't care about current device sizes, and moves content around based on when that content no longer fits correctly on screen. Responsive design is design, it's a process, and it's hard. If it were easy, this wouldn't be a discussion. If we are looking to make bluecheese responsive, I'd say eschew any base theme that makes any assumption about your break points unless you're able to get it to generate content based breakpoints (meaning break points based on your individual site's content, not based on a device) and roll our. If we want aid in building a fluid grid or handling our media queries, look into using Sass+Compass (Sass head, gem install sass --pre) with media query mixins and a Compass fluid grid extension like Susy, maybe coupled with Modular Scale

Once again, if you want to do the work, then you can decide how it's done. Benchmarks or GTFO.

@cweagans, #30:

To be quite frank, this statement really upset me.

Sorry for that, but -as I said- there was no bad intention on my behalf. Perhaps it's not what I said, but the words I chose to express my opinion.

So far, there have just been nebulous, unsubstantiated statements about how base themes reduce performance and they're harder to maintain...

It's not the possible performance hit. It ain't even about how hard it might be for base themes to be maintained. It's a matter of how hard we'll be able to find new (co)maintainers when/if the need arises. Quite a few of us already mentioned the fact that in order to be able to join in as a (co)maintainer or take over in case one decides to quit, one will have to either already know or get to learn one extra thing. That limits the possible candidate maintainers to only those either having previous experience with sub-theming and specifically with Omega (or whichever one we choose in the end), or to those willing to spend time/effort learning. You have to admit that the "pull" of people already familiar with plain-(good)-old theming is definitely larger - in fact it most likely includes those familiar with sub-theming and those familiar with Omega. Is that statement substantiated enough?

In fact, calling our statements "nebulous" and "unsubstantiated" simple because we seem to be seeing things from a different angle might be equally upsetting to some of us.

The bottom line is we are faced with two options here. The way I see it these are we either "simply" do a straight port of the existing theme to D7 (I've done that relatively easily for almost all of my sites in the past year and a half and I am no guru) or we do additional work to convert it to a sub-theme of a base theme we choose. The second seems like a rewrite to me, but I have to admit that I have no actual in-practice experience with sub-theming. I simply have a basic understanding of how it works and only played around with Adaptive a bit.

We seriously need to keep in mind that this issue here is part of the effort to port d.o to D7. I understand that a lot of people here are in favor of doing a complete rewrite of the theme for D7 in order to add "hot" features such as HTML5 etc and they are very excited about it too. This is really nice (and all), but if this is to slow down the whole process of porting d.o to D7 though, then I say let's better do a quick/dirty port and let's then fix it or add things we need/like in a separate "Make bluecheese responsive" issue. Hell let's leave the rewrite for later on and switch to it once it's been done. IMO it's what d.o does for us that's important. If this looks "pretty" or is responsive on our mobile devices should come second - by far. To that end, we should make sure that we have a rough D7 port ready so we can for example test the D7 port of Project. Don't you people agree?

@banghouse, #35: Sorry Joel, again I'm sorry if I seem to have used "ugly" words to express my opinion.

...I've only committed to work on the Bluecheese port to D7.

It is my understanding (as you can probably see from my post above) that a port to D7 means to simply make the necessary changes in order for the theme to work in D7. What you offered to do seemed most like a rewrite of the theme as a sub-them for Omega 7.x - not a port the way I see it.

In fact, calling our statements "nebulous" and "unsubstantiated" simple because we seem to be seeing things from a different angle might be equally upsetting to some of us.

No. Read the entire sentence. "nebulous, unsubstantiated statements about how base themes reduce performance and they're harder to maintain". There have been claims that using a base theme reduces performance, which is nebulous and unsubstantiated. There have been claims that they're harder to maintain, which is nebulous and unsubstantiated. There are at least 21521 people that know how to maintain an Omega subtheme, as opposed to the five or six that know how Bluecheese 6.x works currently. I realize that it's just a normal Drupal theme, but people look at it and say, "huh, I haven't really played with this, so I'm not going to try to fix things."

Quite a few of us already mentioned the fact that in order to be able to join in as a (co)maintainer or take over in case one decides to quit, one will have to either already know or get to learn one extra thing.

There are plenty of people that know how Omega works, and god forbid we have to learn something. Why should we force contributors to learn another Drupal.org-ism? Why not ask them to learn how Omega works so that they can use it on their own projects as well as help with Drupal.org?

Bottom line: If banghouse can do a port of bluecheese to Drupal 7 as an omega subtheme, then who the hell are you to say that it's not good enough because it uses a base theme?

If banghouse can do a port of bluecheese to Drupal 7 as an omega subtheme, then who the hell are you to say that it's not good enough because it uses a base theme?

For the record, Colleen Carroll and I offered to code up the original bluecheese as a Zen sub-theme, but were turned down. So, Cameron, don't take it so personally.

To be clear, I'm not upset about not being able to use Omega. I'm upset that 1) we're not using existing community tools for Drupal.org, and are instead opting to rebuild it ourselves for the sake of "performance" and "maintainability" (for some definition thereof), and 2) a contributor has offered to do the port as an Omega subtheme - to port Bluecheese to Drupal 7 - but his work is being turned down simply because it's built on a subtheme.

There are two things that I really hate: 1) Singe use code, and 2) Wasting other contributors' time.

banghouse's work hasn't been turned down. I haven't reviewed it yet, but it is the best we have. If we get something significantly better or find significant issues, we need to do something different; but that hasn't happened yet. Anyone able to commit to helping in any direction is welcome to help out, http://drupal.org/node/1018084.

Picking up on Neil's and Webchick's comments:

Steven Jones and myself have already offered to commit time to make Bluecheese responsive: #1435260: I want a drupal.org development site for making bluecheese adaptive

We've even begun work on it: http://responsive-drupal.redesign.devdrupal.org

I see this environment as more of a proof of concept or exploratory design phase before we completely rebuild the theme for Drupal 7 anyway. I'm willing and able to see this phase through and I'm happy to fly over to Portland if it means getting shit done.

If anyone else is happy to join me in some responsive exploration then give Neil a shout.

I'd also like to mention that there is a lot of updated documentation for Omega: http://drupal.org/node/819164

Ok, so to summarize, we need a D7-compatible, mobile-first theme on our www.drupal.org site for at least the next two years until D8 is ready to go live. True, we aren't going to work on adaptive|responsive implementation efforts during this initial D7 site upgrade, but we're going to have a mobile-first theme on this site by the end of 2012 so we might as well lay a strong, smooth, flat foundation for it right now.

The two arguments I'm hearing against using a mobile-first base theme for the Bluecheese D7 upgrade on drupal.org are that "It's too big", and "It's too slow".

Let's put the first one out to pasture right now by simply realizing that a theme can't be "too big" unless it's either so vast it can't be understood by the average themer or it simply won't fit onto the storage medium. I think we have enough disk space on d.o to store any one of the themes in our contrib theme repos, so that's a non-issue, and if it is, I'll loan Drumm and Narayan one of my spare USB memory sticks. ;) If a theme is too big to be understood, then that's a problem, but I've never met any two themers|designers who agreed 100% on all implementation details of any theme or who felt that a certain theme 'did everything right', so this cannot be judged as a case of "I don't like the way it does x because my way is better".

Please discuss the above.

That brings us to the "It's too slow" argument. I'm going to require some benchmarks that prove our contrib base themes are unusably slower than a custom-rolled, mobile-first theme that does 100% of what we need in terms of the next two year's worth of drupal.org mobile browsing habits on the 4200 different devices in existence by 2014. If we can't prove (with hard data) that rolling a custom theme onto d.o that handles all of our mobile-first needs is speedier than a base theme which we know handles mobile-first, then this "It's too slow" argument has to be put to bed too.

Please discuss the above.

One last thought, which doesn't really need discussion before this sprint but is good to think about anyway, is what @gabor mentioned above in regards to code duplication. When our custom theme is done, two years from now, how much code and functionality of a contrib base theme will it be duplicating? 80%? 90%. and will *any* of those necessary improvement efforts which are made in order to keep up with the pace of mobile technology ever make it back to the community? Think about it.

I will be available in IRC (or ping me in IRC for a Skype call if you'd like) for the next 48 to 72 hours to discuss *any* opinions or *any* details of our new d.o mobile-first theme. Taking all comers, but I'll need to have a decision on this by Monday the 23rd at noon so the Bluecheese Team can move forward unimpeded. Deal?

I think I am reasonably qualified to make a comment here, being the maintainer of a the most popular responsive mobile first base theme for Drupal 7 and having a fair amount of experience and insight into this subject. I also know how Drupal.org works and I wrote the HTML Guidelines for Bluecheese the first time around.

Caveat. I am extremely weary of posting in this issue. I have, for want of a better explanation, been rebuffed on a previous occasion and told I had "an ulterior motive" when I first posted an issue to the Omega queue some 6 months ago regarding its performance issues. That made me very sad and I walked away from trying to help that project solve a very real set of issues. I care far more about Drupal users and Drupal.org than I do about any one project, be it my own or not, get to know me personally and you will know this. OK, moving on.

I agree with many things Senpai is saying above - a base theme can never be too big in terms of code weight. I tend to think the too big arguments are misnomers for "too complicated" and "doing to much". There is also the temptation for complexity and feature sets to be misconstrued with performance, or lack there of. This is somewhat of a myth, although I would concede its entirely possible to destroy performance in the front end, however its also possible to support large feature sets and not sacrifice performance. However, performance is a complex subject and I am going to explore this in some depth.

Some of the commenter's have presented the roll-your-own vs framework debate citing the bespoke nature of Drupal.org as a case for the former. drumm and several others have pointed out the the lack of contributors and clearly Senpai is making it known that time is a factor here, we need to weigh these into the mix as they are important factors in the decision making process.

Performance issues - this is a deep subject and particularly so when discussing the front end and mobile because we are not just talking about execution time and memory footprint.

There are, at least, two sets of performance issues when building themes - back-end performance which in essence means execution time and memory usage, and front-end performance - meaning the performance of the generated output - that which is sent to the browser - its total weight, method (link vs import, media attributes etc) and the nature of this data. Principally I am talking about HTML, CSS and JS and/or other required files.

To be clear this is not about server network bandwidth, in terms of what is incurred by the server/host, but rather in terms of what is being downloaded by the client. I am sure D.O can handle enormous amounts of bandwidth and this is unlikely to be a great issue, within reason. The issue here is with the client network and device, and what they need to handle. This impacts cost (the data transfer cost in financial terms) and user experience - the two big issues in mobile and front end performance.

I want to diverge for one second here to discuss my current project - its for a Japanese tech and the biggest gaming social network site in Asia. The dev on this project is not unlike core - every line of code is reviewed. I was raked over the coals last week for introducing one line of CSS that declared a new font family. Performance is the top priority, we need to support the various mobile networks in Japan and reducing the total code weight in the front end is of utmost importance, so as to provide the optimal experience for all users regardless of device or network.

This I believe is where we need to be looking at "performance" when discussing base themes, with just as much, if not more focus than raw execution time.

We need to be acutely aware of the proliferation of low powered, dare I say "crappy" mobile devices and that these devices are slow, in terms of page rendering. Remember, mobile first is not "mega powerful iPhone first", its "low-fi, not much memory, crappy processor first". All the indicators are pointing at a big increase in the number of these low-fi devices, think of this as the "10 buck kindle in every kids pocket and one in mums handbag" type of scenario. This point is highly relevant, if we are to stay relevant, and at least appear to have some understanding of the broader issues facing modern web development and the mobile space.

So whats my point?

• We have a time to market issue, and resourcing issues.
• We have deep concerns that a base theme is doing too much and could just get in the way.

Here is my take on this, first:

If you need to substantially override what that base theme is doing in order to get performant and scalable output then there is no point in using that base theme. There is likely another that does the job you need out-of-the-box.

This would drive my principal objection to using a theme that embedded classes in the markup and that, out of the box, adds redundant wrapping markup because we don't need it, nor do our users want it - they want a fast D.O, as fast and as low cost as possible (remember the data charges I mentioned earlier).

And secondly:

Out of the box mobile support needs to really mean mobile first, in every sense of, especially in terms of performance. If the base theme allows non-supporting browsers to download files it cannot use this is an unnecessary performance hit for both ends of the network.

Be aware that this is exactly what one of the currently proposed themes does.

The argument that we can override the base themes output fails the time to market and resourcing issues, and adds an additional layer of code checks into the mix. It does not make sense to use a theme that fails the basic requirements out of the box. This I believe is what drives the decision making of the roll-your-owners. However, I do not actually fully support that position and will follow up in another installment. Suffice to say, for now, that:

The more DOM elements, the slower the page renders. The bigger the download the greater the implicit impact on UX and financial cost, i.e. what the end user must incur as a total cost of using the site. Yes we are talking about small amounts of data here, however, do we want a D.O that is world class, that reflects all that we can be, or one that fails basic best practice in this field and does not serve the best interests of a great many of its users?

I will conclude here, for now, there are other issues at play, not least of which is back-end performance which I have not addressed at all in this comment. Since this is getting very long, in conclusion:

Be aware that Drupal is not just for developed nations. Low power mobile phone usage is ubiquitous in most sub-Saharan African nations, whereas computer ownership is the lowest in the world - people access the web on their phones. Data charges and speed count doubly so for these users.

Please consider these issues when we consider a Drupal.org for for all devices, for all users. Clean, concise output is as much a requirement of the web today as it ever has been, its a best practice that should not, and as I have argued, cannot be ignored.

So, as part of the sprint I'm working on getting a work 7.x version of Bluecheese.
Just to note this is a pure Drupal 7 core install. Fresh DB.
My steps so far have been; changing the info file version 7.x, integration html.tpl.php to stop multiple tags.

Here are the errors I get printed:

• Notice: Undefined index: right in bluecheese_preprocess_page() (line 7 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/template.php).
• Warning: Illegal offset type in unset in drupal_get_messages() (line 1791 of /Users/Lewis/drupal 7/drupal/includes/bootstrap.inc).
• Warning: Illegal offset type in isset or empty in drupal_get_messages() (line 1793 of /Users/Lewis/drupal 7/drupal/includes/bootstrap.inc).
• Notice: Undefined variable: nav_header in include() (line 8 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: drupalorg_logo_link in include() (line 14 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: mission in include() (line 15 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: search_box in include() (line 21 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: nav_masthead in include() (line 27 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: is_drupalorg_front in include() (line 38 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: nav_content in include() (line 62 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: content_top in include() (line 86 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: help in include() (line 94 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: content in include() (line 96 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: right in include() (line 104 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: content_bottom in include() (line 112 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: nav_footer in include() (line 122 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: footer_message in include() (line 129 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: closure in include() (line 138 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined index: right in bluecheese_preprocess_page() (line 7 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/template.php).
• Warning: Illegal offset type in unset in drupal_get_messages() (line 1791 of /Users/Lewis/drupal 7/drupal/includes/bootstrap.inc).
• Warning: Illegal offset type in isset or empty in drupal_get_messages() (line 1793 of /Users/Lewis/drupal 7/drupal/includes/bootstrap.inc).
• Notice: Undefined variable: nav_header in include() (line 8 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: drupalorg_logo_link in include() (line 14 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: mission in include() (line 15 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: search_box in include() (line 21 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: nav_masthead in include() (line 27 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: is_drupalorg_front in include() (line 38 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: nav_content in include() (line 62 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: content_top in include() (line 86 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: help in include() (line 94 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: content in include() (line 96 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: right in include() (line 104 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: content_bottom in include() (line 112 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: nav_footer in include() (line 122 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: footer_message in include() (line 129 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).
• Notice: Undefined variable: closure in include() (line 138 of /Users/Lewis/drupal 7/drupal/sites/all/themes/bluecheese/page.tpl.php).

@lewisnyman tell me if I can somehow help you remotely. I started converting Bluecheese couple of days ago also, but unfortunately had little time, so not much ahead of you, just fixed part of the errors you list.

Well, I'm glad the discussion in 44/45 happened. Looks like we're just going to drag along Drupal.org-specific code for another couple of years.

If somebody wants to approach this task in a more sanity-friendly way, please contact me directly. I'd love to help with that, but I will absolutely not, under any circumstances, do anything with another custom theme.

/me unfollows this issue.

My understanding is the Bluecheese team is prototyping both approaches in order to make a determination on which one to go with based on actual data.

Huh. How did I miss tagging this? :)

Adding the 'bluecheese' tag.

Upgrade Sprint Day 1 report:
@webchick is correct. The report from day 1 of the upgrade sprint is that this team of three is pursuing both approaches. With team lead approval, @lewisnyman is continuing with the beginnings of his custom theme 1-to-1 port begun in comment #42 and estimating the level of effort to complete. @banghouse and @rupl are working today on the feasibility of integrating the already-started Omega subtheme into the actual drupal.org D7 codebase to see how big of a job it will be.

More info tomorrow.

I can't believe so many people are saying the custom code will drag us down!!! Doesn't all contributed code start life out as someone's custom code?

Besides, the theme itself doesn't hold most of the custom code; the drupalorg_* modules do. The theme has to integrate with these customizations and there's no base theme that will just magically solve that challenge. The customizations will have to be dealt with. The question was mainly "do we port the current integration forward" versus "Do we re-implement customizations using a new method [with a base theme]"

This list of modules is what you need to be looking at if you're worrying about customizations:

• blocks_and_nodes
• drupalorg
• drupalorg_crosssite
• drupalorg_git_gateway
• drupalorg_git_varnish
• drupalorg_handbook
• drupalorg_metrics
• drupalorg_news
• drupalorg_order_facet
• drupalorg_project
• drupalorg_search
• drupalorg_versioncontrol
• drupalorg_case_studies
• drupalorg_change_notice
• drupalorg_grid
• drupalorg_marketplace
• drupalorg_packaging_whitelist

You can download these modules here: http://drupal.org/project/drupalorg. The bottom five in the list are custom Features, but they are still available within the drupalorg project.

The sprinters in Portland are trying our hardest to figure out the best method in an objective manner. We have themers on both sides of the fence. So we are finding the way forward by collecting data and looking at the results. We're admittedly having to take this data and compare it against the perceived opportunity cost in terms of time-to-build and general level of effort, which is unavoidably biased to some degree. We hope the combined preferences of our team will provide balanced consensus. Onward, ho!

Ok, EOD status:

@banghouse is cranking out Omega theming work. Rawk! We'd gladly post the actual code but the d.o infra team prefers not to host the code publicly in order to reduce people piggybacking on d.o branding. Anyone who wishes to see it is welcome to contact us in #drupal-infrastructure and we'll set you up.

@lewisnyman has inspected many popular base themes, so that we might be able to borrow features from one or another as we build the theme. Please comment, add, remove, etc: http://groups.drupal.org/node/226833

I have finished doing the initial frontend profiling. It was essentially a tie between the custom code and the Omega prototype, mostly due to the minimal design of d.o. I continued on to integrate basic frontend improvements within @banghouse's new theme: moving JS to the footer and integrating Modernizr.

I also slogged through some of the drupalorg code posted above searching for theme-specific integration points. We'd LOOOVE your help on the drupalorg code (yes, you!). @webchick would high-five you or something! Seriously though, drupalorg is a huge component which needs some helping hands.

Go here to get started on upgrading the 7.x-3.x branch: http://drupal.org/project/drupalorg

I can't believe so many people are saying the custom code will drag us down!!! Doesn't all contributed code start life out as someone's custom code?

The problem is not that things are custom. The problem is that the custom things are specific to Drupal.org and nobody other than the Drupal.org maintainers/contributors ever look at that custom code. Contributed code starts out as custom code, but is then abstracted and released for use by anybody, and that's the step that we haven't taken with the Drupal.org customizations. It has to happen incrementally, but using a base theme for Bluecheese is a good first step.

Just to update my comment from yesterday... @webchick has helped me reduce the list of customization issues. The list is smaller than I thought yesterday. Hooray! Here they are (using drupalorg 7.x-3.x):

$ pwd
...sites/all/modules/drupalorg
$ grep -rn "theme('drupal" .

./drupalorg_handbook/drupalorg_handbook.module:37:        $node->extra_footer = theme('drupalorg_handbook_footer_line');
./drupalorg_handbook/drupalorg_handbook.module:125:  return theme('drupalorg_handbook_contributors', $created, $modified, $contributors, $edit_link);
./drupalorg_handbook/drupalorg_handbook.module:322:                'content' => theme('drupalorg_handbook_meta_sidebar', $about),
./drupalorg/drupalorg.module:429:  return theme('drupalorg_home');
./drupalorg/drupalorg.module:478:    $output = theme('drupalorg_map_pin', array('homepage-pin', 'homepage-pin-commit', 'homepage-pin-west', 'drupalcon'), variable_get('drupalcon_latitude', 41.836944), variable_get('drupalcon_longitude', -87.684444), variable_get('drupalcon_message', '<a href="http://chicago2011.drupal.org/">DrupalCon Chicago</a><br />March 7‐10 2011'));
./drupalorg/drupalorg.module:514:      $output .= theme('drupalorg_map_pin', array('homepage-pin', 'homepage-pin-' . $row->type, 'homepage-pin-' . ($row->longitude > 0 ? 'east' : 'west')), $row->latitude, $row->longitude, t('!name @verb<br />!page', array('!name' => theme('username', $row), '@verb' => $row->verb, '!page' => $row->link)));
./drupalorg/drupalorg.module:534:  return theme('drupalorg_start');
./drupalorg/drupalorg.module:562:  return theme('drupalorg_download');
./drupalorg/drupalorg.module:629:  return theme('drupalorg_community');
./drupalorg/drupalorg.module:646:    $variables['recent_activity'] = theme('drupalorg_recent_activity', tracker2_query(variable_get('drupalorg_recent_activity_pager', 10)));
./drupalorg/drupalorg.module:654:  return theme('drupalorg_getting_involved');
./drupalorg/drupalorg.module:1393:            $content['column_3']['map']['#value'] .= theme('drupalorg_map_pin', array('pin'), $account->latitude, $account->longitude);
./drupalorg_project/drupalorg_project.module:1046:  return theme('drupalorg_project_meta_data', $info, $modified);
./drupalorg_search/drupalorg_search.module:445:  $output = theme('drupalorg_search_help_results', $results);

This stuff mainly involves hardcoded content that sits in the theme, so that the content with the most traffic is not causing I/O on DB

Re-titling and tagging.

With Sass+Compass and Susy implementation, I'm happy to help with this and train those who need help learning the stack.

@Snugug:

We are a smart enough bunch to be able to roll media queries on [our] own

I won't use Drupal because I am smart enough to write PHP myself.

Here's the definitive blog post outlining the choice to keep Bluecheese as a custom theme and implement Sass+Compass+Susy support for our future mobile-first needs: http://groups.drupal.org/node/236988

Tagging for Sprint 6.

So...

We were going to just port Bluecheese to D7 by throwing Omega on there and doing some light CSS styling. The people involved in this thread blew up over it. So instead we went some fancy, custom SASS-y way. And now everyone who knows about that is way too busy to help us complete the port. :(

So how about one of the people who was adamant about going the custom route contact Senpai and see how you can help? :D Thanks.

Also, FWIW, that Omega 4.x version with the nice front-end performance fixes that we thought would be too out of reach for the D7 port of Drupal.org now has a nice alpha1 release.

Mind you, I don't think it's worth abandoning the work that's been done so far on the current D7 port for Omega, at least not yet. But if there isn't some movement on this SASSy D7 port soon, then the Omega option is going to start looking a lot more attractive.

Angie, the other issue with Omega is that the site-building process is very different from the block system that d.o currently uses. The code that banghouse wrote back in March was not a 1:1 drop-in replacement for the then-freshly-ported D7 bluecheese, otherwise we would have gotten it running on d.o in the three days we spent trying :)

Also, the Sass work we're doing now has been specifically scoped to be "unimpressive" if you will, because we made nothing responsive. However, it opens the door to possibilities down the road that are simply not possible with any contrib theme out of the box. So the same problems would crop up no matter what theme we choose.

I've just been chatting with @Senpai in our bluecheese skype channel and have reminded everyone that I'm always available to help with any of the odd VCS issues that we encounter in the course of development. That seems to be a blocker pretty often so I've raised my hand to be the go-to guy on that. I totally owe @drumm a bluecheese doc page too ^_^

Also from skype, I'm hearing that we have one (or potentially two) new waves of volunteers coming from various sprints. I am always standing by to remove tech blockers from d.o themers so that they can focus on theming.

Banghouse, I'm sorry to hear about your bad experience, thank you for filling everyone in on what has derailed the Bluecheese port. I'm newly aware of this issue because of Webchick's recent tweet. Simply stated - I'm a hardcore front-end developer and skilled sitebuilder. I'm proficient with SASS and use it daily for all of my sites.

However, as Banghouse mentioned - I think d.o would have a larger pool of contributors to this port, and the ongoing maintenance, if Omega is used. As well, Omega 4 has SASSy goodness baked in too. After reading the original discussion, http://groups.drupal.org/node/236988, Zen is a great choice too. Either of these would be better, and more understandable for new contributors to jump in, rather than starting from scratch with a fully-custom/roll our own SASS theme from this point moving forward in my opinion. Is there an official Bluecheese repo anywhere with starter code yet?

Thanks,
--Tony

@Jeff Burnz: I'm sorry you had that experience reporting issues on the Omega issue queue :( I've replied to the other user on the issue in question, hopefully he'll behave better in future.

This seriously needs an issue summary. Tagging.

Ok, so @banghouse is out, and I completely understand his position here and I want to thank him publicly for all the work he's put in as a team lead in upgrading the drupal.org theme so far. THANK YOU!

The reality going forward is that I'm going to need @rupl, @lewisnyman, and @snugug to step up and finish the "new Bluecheese contributor docs" and get them published as handbook page(s), and I need it ASAP this coming week because there's now a canoe full of people seemingly interested in helping out with our d.o theme and they need to know why and how it's built the way it is, what it does, how to modd it, things like that.

How much of the bluecheese port is done? (rough estimate.)

Even if the answer is 0%, the worst thing that could happen at this point in the project is revisiting our decisions of how we're going to build the theme. Any change in the "custom theme + Sass + Susy" decision means we would have to revisit the entire decision process. I'd really, really want to avoid going down that road (regardless that Zen might do well during a re-evaluation.) I'm 99% sure we can get drum up enough volunteers to finish the custom/sass/susy-version of Bluecheese for drupal.org. So let's do it!

At the end of last week, I asked Joel for links to docs learning to contribute to bluecheese. As soon as the new docs are written that Joel asked for, I'm going to write up a blog post to promote the need for bluecheese builders and maintainers. Go team!

I'm putting time into Bluecheese Sass docs this morning in addition to some ongoing d.o maintenance. Right now the following users can push updates: @lewisnyman, @Snugug, @jhodgdon, and @Senpai -- I'd be happy to add others.

I think for the most part there isn't a whole lot of documentation to be written. I'm going to do a once-over on the existing partials, which are direct copy/pasta from the old CSS. Any new features we build could use nesting and all that jazz, but it's not *necessary* to complete the work and get d.o ported. It would definitely be nice for future maintenance.

We've already added a couple pieces of documentation to Bluecheese itself, and I'll add some notes about using Compass on d.o infra. I made some changes recently to remove Sass cache busting (Sass appends ?13309459873 to the end of image URLs) so if anyone sees that happening let me know and I'll get it fixed.

John, regarding maintainers: All of my involvement lately has been working with @drumm to co-maintain the D7 theme. It's a slightly complicated review workflow and you must be comfy with SSH, bzr, and Jenkins to help maintain bluecheese. It's a separate activity from theming so I'm happy to share that load and continue reviewing work.

adding summary

Updated issue summary to reflect status as of 2012-10-08. Added lists of issues so people can quickly jump to one and work on it. Added links to get people started if they want to contribute.

More information added to "Get Involved"

Updated issue summary.

Added link to all Bluecheese issues.

Updating Roadmap

This is now the [META] issue that contains the work-in-progress punchlist, so the ' Issue summary initiative' tag is not needed.

Closed ol tag

Reducing Announcement page priority

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updating issue summary.

adding tag

adding 1823988

adding 1645790

Adding #1820270

Moving done issues down

update, adding follow button issue

.

.

.

.

.

adding 1549728

update

.

.

.

.

adding 1833280

.

.

.

adding 1821570

.

.

.

moving up

.

adding 1836254

.

.

.

adding 1580272

The theme is now running on association.drupal.org and api.drupal.org. The open issues at https://drupal.org/project/issues/search?status[]=Open&issue_tags_op=and... are much more useful than a meta issue.