The Jalapeno MDB D7 Theme

Changed title to make it obvious this is a D7 theme.

Thankies sreynen

Thanks sarah__p

The thinking behind including is that it is a feature, such as uploading a logo, that is widely wanted. Eaton, who created the Noggin module states that it was intended to be within Bartik but was not in time to get it through, so it seemed logical that something that would have gone in a core theme had there been more time "could" reside in a theme.

And thanks for spotting the missing " ... that appearance screen has been bugging me for ages, completely missed that!

New version of .info file uploaded to git to fix broken html.

I understand what Jeff is saying about duplication, but would consider this not to be that straightforward. There is a big difference (in my mind, which has been known to be wrong!) between functionality being within a theme and a module.

There would be no problem releasing a theme that has layout functionality baked in, an example could be http://drupal.org/project/equalheights which is a feature in most of the popular base themes. My opinion is that yes, duplication is bad, but not if the purpose is specifically targeted. Drupal doesn't need 2 Noggin modules, but I see no conflict in the user choice to either use a theme with this rolled in or choose another and install a module.

I know I'm being picky but I think this feature within a theme would be a popular choice.

Is there a handbook for this kind of thing, I don't want to mark this as needs review again to get shot down :D

As an aside I just remembered that this functionality is already being used by themes, apart from a raft of D5/D6 themes that use the theme-settings-api module, there is specifically http://drupal.org/project/mayo that has this within it's theme settings.

So technically, the functionality is already out there, it's the implementation that would come into question. I notified Eaton prior to submitting the theme for review and he didn't appear to mind the code being reused.

Setting back to "needs review" so people know to look at my ramblings.

Thanks I hadn't seen that particular thread, it seems to read though as if it was a time constraint and that pushing it to a D8 feature request was simply the outcome of that. I would love this to be a core feature, definable through a themes info file.

It just seems weird that something that "should" be a theme feature, is only allowed through a contrib module. This sounds like it may stand a good chance of being in D8 as quite a lot of the work is done now.

I don't see how including a font api within theme settings and being able to customise the theme with an uploaded image differ. There are modules for both these and examples of them being used directly within themes. Both functions are design alterations, which firmly comes under a theme layer remit, but I can see the benefit of allowing the usage within a theme setting and with a module.

The specifically targeted purpose is to allow the background to be changed, which is the same as Noggin, but then why are fonts not directed to use the module counterparts for font selection?

Thanks sreynen.

As an added point, the eventual plan was the apply the technique wider throughout the theme and have multiple elements that are changeable, which is why having the variable makes more sense. A simple use case could be adding multiple background images to elements. (eg. having a div with a gradient background that has a fixed bottom shadow). These are CSS3 features I would have liked to use, but they are not widely supported in many browsers yet.

I haven't had time to develop this idea as yet, but it's on my list.

It does mean the theme suffers from a little divitis to achieve the effects but there is no stable way to get it without that. And the thinking behind it being there in the first place is that it provides the functionality for people such as non-coder designers that would like have the option without touching any code.

It's not as if I'm trying attempting to squeeze a mini-views interface into the theme settings page, which would in my opinion, be the job of a contrib module. This is simply using the functionality of a module without that dependency. I honestly don't see what is wrong with allowing users the ability to have one less module to install.

To swing the usage round, as in comment #11, would you consider removing the equal height functionality from the AT theme just because that is available as a module? Probably not, because it's useful to the theme and within the theme.

I don't see the point in having a powerful theme layer if all the good functionality isn't allowed because there is a module (currently in limbo due to no solid maintainer). It's like saying to the world, "hey, come use Drupal it can do X, Y and Z, but only if you do it this way"... and that way isn't the most user friendly or logical.

I understand that this in terms of module vs module duplication would be a clear cut, black and white issue, but a theme isn't a module. And it does look a bit like those already having full project status can bake in whatever they want, whenever they want. I've pointed to similar functionality in use, given examples of similar scenarios that this discussion could be relevant to, and if a decision comes back from sreynen's request for additional reviewers that I should remove the functionality I'll abide by that - not happily but will abide.

This is an issue though that IS going to come up time and time again, especially if the drive to get more theme contributors is successful. Anyone coming to Drupal from outside the ecosystem, will look at a thread like this and quickly run away for fear of not being able to build a theme that is comparative in comparison to what they can do elsewhere.

Thanks zzolo, your input is very much appreciated. Before I remove the functionality I would be grateful if you could clarify one thing on the duplication issue.

Is it the actual code duplication that is the problem or the functionality that the code provides?

The reason I ask this is that I would really like to be able to have this within themes, if it's the duplication of the Noggin code that is the issue then would it be ok to find a different way to achieve this? Alternatively, if it is the functionality that is the issue, then it highlights a larger issue that goes beyond the examples I've listed (Mayo, equal height js etc).

I've been a quiet member of the community for a couple of years now and appreciate all the hard and thankless work that gets put in, I understand I've laboured this point quite a bit but I think the clarification will help me going forward, and maybe even help if such discussions raise their heads again.

Thanks Jeff, that does explain the problem a bit clearer. I do get that module duplication is a real issue and I do understand that. What I'm failing to grok though is the distinction between code duplication and functionality duplication - particularly in relation to Modules vs themes. Module vs module is clear cut, it either does the same thing or not. Module vs theme brings the twist of implementation into the picture.

If the rule in place is that duplication of "code" is not allowed than I totally get that, but if it's the functionality that's called into question then it points to a "one way to do it" model, which a) limits contributions & b) calls into question established maintainers not following the rules & c) doesn't allow for reuse of code that is gpl'd.

So, to get this moving forward, I'm going to remove the code that provides the functionality, leaving it as a "future feature" that doesn't step on the duplication issue. Once this is removed I'll whack the issue back to needs review.

Is there a discussion going on that I could stick my 2cents into about this topic though, mainly the module vs theme functionality? If not, where would be the best place to start what could potentially turn ugly?

Thanks all for your input and explanations.

Right, have removed the functionality, uploaded revised version to git and amended the project description on the sandbox project page. I can't edit the description within this issue, so that needs ignoring or editing if someone has rights to do so.

And switched back to "needs review"

What's next on the review list then?

I know there's a specific thread discussing ways to improve the review process, so I'll cross post this over there. There's a definite need for a basic checklist so that both reviewers and reviewee's can see what has been done. That would ease a few frustrations in the process.

An obvious BUMP.

It's a special day, not only is Lenny Kravitz 47, Helena Bonham Carter 45, and even Al Jolson would have been 125 - but a more special day ensues...

This theme's 1 month anniversary of being in the Project Application queue... Happy Birthday Jalapeno!