Twenty Eleven theme for Wordpress 3.2

Jeff Burnz's picture

Anyone spotted the demo for the Twenty Eleven theme for Wordpress 3.2 -

I think its worth us tearing this apart and looking at the ideas they have bought in, I've only played with it briefly and its pretty nice actually. That said my initial impression was not so favorable (omg this is lame), however the more I play around with and uncover its various features the more I like it.

WP and Joomla themes are huge on "short codes", this theme uses them also - basically users can insert a class into something, for example on an unordered list to enable some cool list icons, or on blockquotes, such as

Maybe we could include short codes in the new Drupal 8 theme?


Unless I'm missing something,

isaacfreeman's picture

Unless I'm missing something, short codes seem similar to tokens, which are in core for Drupal 7.


Jeff Burnz's picture

I just found this project -

Bit like tokens more like an Input Filter on steroids (e.g. they can include attributes), this makes them much more powerful than say Markdown or simple tokens that insert something dynamic.

We would be able to do something like this to style a list with nice icons:

[list class="star-icons"]
list item
list item
list item

If I get i t right, tokens

farsaid's picture

If I get i t right, tokens are PHP based, while "short codes" in this case are based on CSS, which are more web designer friendly. CSS is for presentation, not for content.
That said, I would prefer coding my own CSS and incorporate it in a theme more easily instead of having the possibility to use only pre-made classes ...they're confusing at times, or they simply don't do what you expect them to do. Or they do it differently from what you thougth (so you still have to edit them anyway), making the work harder ...sometimes you find yourself learning premade classes instead of focusing on real CSS knowledge.
I see this in a lot of CSS frameworks, it's plenty of pre-made classes. But I personally don't think it's the right way to go. I prefer to use my CSS skills and build my own ...this helps me keeping it light without having loads of code unused. And this way you learn and use real CSS!

WordPress Shortcodes

senortim's picture

WordPress shortcodes are not just for formatting. Perhaps you are just referring to the Twenty-Eleven theme, which I haven't seen yet. But shortcodes in general are for including the results of PHP code. Kind of like Drupal hooks if I understand things right.

That said, it would be very cool if Drupal did have shortcodes that would allow end-users to include blocks or views without giving them access to the PHP module. I'll have to check out that project Jeff found, but it would be sweet if this were part of Drupal core; I, for one, think that it's weird that Drupal has us add blocks to some virtual page, then configure the blocks to appear one place or another. Injecting blocks within content makes more sense to me for many uses.

Drupal Filters

metzlerd's picture

Drupal has extensible markup via input filters. The views_insert module can be used to embed views. There used to be an insert_block module, but it never took off for some reason. It would be relatively easy to roll some such functionality into a shortcodes module or another. Our community appears to just be a bit too divided on whether this is actually a good idea to see it really take off.

The issue isn't he ability to do markup, but rather agreement on which markup should be packaged into core or not.

I've used the insert_views strategy on some sites, and am rolling something similar for my own report writing module.

Instead of teaching clients a

LewisNyman's picture

Instead of teaching clients a new syntax. We should really be implementing these additional classes using a wysiwyg interface.

They can be, in fact in WP

Jeff Burnz's picture

They can be, in fact in WP they are primarily designed to work with TinyMCE afaict, and the Shortcodes Drupal project does as well.

If I had a dollar for every time someone said "dont teach a new syntax"... meanwhile other systems just get on with it and gives users what they want and need. Drupal can keep staring at its asshole for a few more years while the world passes us by.

The functionality to add

LewisNyman's picture

The functionality to add classes to elements already exists in CKEditor.

Skinr is another example of a this kind of functionality applied else where.

Not just CKEditor

SKrossa's picture

The ability to add classes to elements is built into the Wysiwyg module ( and can be used with at least the TinyMCE and CKEditor libraries, and I would assume any other supported editor library that has the feature.

You're right Jeff, for

farsaid's picture

You're right Jeff, for clients it can be useful, especially through a wysiwyg interface ...better than nothing!
But I don't think we should stop at this solution. Drupal can do it better, also for designers/developers.
So maybe we can have two ways of doing it:
1. for unexperienced users/clients through wysiwyg, using premade classes (which might be included in the code using a switch of some sort or something)
2. for designers/developers through css embedding/editing modules (for building your own CSS classes to be used also through wysiwyg for clients)

I'm loving the css3 they put

kirei's picture

I'm loving the css3 they put into it. The next core theme should include a lot of that. Really progress the design out of the box.



Jeff Burnz's picture

@lewisnyman, farsaid - in the context of our core themes I'm more or less thinking along the lines of pre-made CSS classes. The problem here is you need full html filter to pull this off - not something all organizations are willing to hand out to their authors. So, we could use the filter system as metzlerd alludes to above to allow users to easily wrap content in shortcodes instead - if users can use WYSIWYG to do this, so much the better. I'm not saying we need to have such a module in core, but if such a module exists (looks like it does), then we could build in support for it.

So how this works - the [token] is converted into markup with a class or classes. If you know the classes you can use them directly (no problem, we can easily abstract these into a separate stylesheet and document them), but you don't need to know them - because you can use the shortcode module with WYSIWYG to get the same thing without needing access to full html.

@kirei - yeah, totally rocking, something we'll definitely be doing plenty of also.

Don't need full HTML filter for CSS classes

SKrossa's picture

@Jeff Burnz - You don't need to give users full HTML filter in order to let them add css classes. The Wysiwyg filter module ( lets you permit css classes (using standard HTML markup) without the full HTML security risk. Also see Jen Lampton's wysiwyg editors site ( for a good guide to configuring Wysiwyg filter module to work with the Wysiwyg module. (It can be used without a Wysiwyg editor, too.)

Given the existence & features of both the Wysiwyg & Wysiwyg filter modules, it seems to me that using short codes to allow users to add css classes (pre-made or otherwise, using a wysiwyg editor or otherwise) is a more complicated solution for an already solved problem.

With regard to themes having some pre-made css classes specifically intended for content contributors/editors to use in general text fields, I think this is a fine idea. The Wysiwyg module already permits specifying a css file to use in the editor, so having themers make a habit of creating a wysiwyg.css file to make it easier for site builders and/or end users to identify the relevant styles the theme uses (without all the ones that shouldn't be used by end users cluttering things up) would be really helpful.

TBH I'm not really sold on white listing

Jeff Burnz's picture

TBH I'm not really sold on the white list + allow users to write raw markup into documents, it has to be easier to setup and use. Expecting users to know HTML is a huge ask and not everyone wants to use an editor, or will for that matter. I think if the user can do something like wrap a list in [list, stars][/list] or something similar its a lot easier to use and just "works".

Take a look at this screenshot -

That is just way beyond many users who need something much simpler to setup and use. So no, I don't see those modules as representing a solution (the filter module is not maintained afaict, no D7 port and a change in ownership is pending). From what I recall HTML Lawed module can do this sort of thing as well, although its even more complex to set up and does this whole white list thing. If the user can simply add a filter to a format its a lot easier to setup.

If using a wysiwyg editor, it

SKrossa's picture

If using a wysiwyg editor, it doesn't matter what the markup looks like for ease of use -- the end user won't see it.

And if not using a wysiwyg editor -- well, I wouldn't recommend that if you want end users to be able to easily format their text using CSS classes but you don't think they can handle html markup. [If you just want them to be able to format without CSS, there is the Markdown filter module and there are also various modules that let you use wiki syntax (if you really must ;-) and the like]

For the site builder, yes, currently setting up a good wysiwyg editing environment is a huge pain -- whether or not you use the Wysiwyg filter module. For that matter, though easier, setting up an editing environment without any rich text editor isn't all that fun, either. (Though setup did improve in Drupal 7.)

But the problem that needs solving there is making setting the interconnect between filters, editors, etc. easier, and making "starter" configurations easier to create and import to sites. After all, a short codes system is also going to need configuration to define what is allowed and what is not, and what codes correspond to what CSS, etc.

Note, btw, that a syntax of [list, stars][/list] would involve not just CSS but also HTML element tags. A list cannot be done with CSS alone -- or rather, it can be but to do so is evil (not accessible & SEO unfriendly) and not to be encouraged.

In sum, I'm still not seeing how a short codes system would be any easier or better for either end user or site builder than current options, and so worth putting effort into rather than improving the ease of configuration of the existing approaches?

Just occurred to me (duh!)

SKrossa's picture

Just occurred to me (duh!) that we're discussing this in the context of Drupal 8 -- isn't a rich text editor going to be included in core in Drupal 8? Or is that just a nasty rumor designed to get our hopes up...?

I think, at the end of the

Jeff Burnz's picture

I think, at the end of the day, you are missing the point entirely. The point is to bring in ideas and concepts that other systems are using - by system I mean "ecosystem". Why? To lower the cognitive overhead of those trying out Drupal who have previous experience with WP or Joomla.

So far almost everyone is missing this point and instead focusing on debating implementations. We need to stop discussing implementation and look closely at the actual theme and what sorts of IDEAS and CONCEPTS its employing. This is getting way off topic.

Note, btw, that a syntax of [list, stars][/list] would involve not just CSS but also HTML element tags.

I would have thought that was obvious and did not need to be explicitly stated.

I kind of have to laugh about

senortim's picture

I kind of have to laugh about this one. The cognitive overhead of Drupal for those with WP (like me) and Joomla experience probably has less to do with what people have talked about in this thread and much more to do with two things: 1) a huge difference in how data is served by the core (big chunks of HTML in Drupal) and thus much greater difficulty skinning sites via CSS, and 2) the lack of any clear path to the best set of modules. In the case of WP, at least, all it takes to create different looks at data is a couple of small changes to how records are returned -- pretty easy for anyone with more than a few weeks of PHP experience. In the case of Drupal, one has to have spent quite a bit of time using and experimenting with different modules to get what's needed. In my case, what I could have used more than anything else was a clear guide to the best modules, and to have those modules be well documented.

That said, people are wanting to use Drupal because of its power and scalability, and are probably (like me) willing to put up with a steeper learning curve to get it.

So while I still am unsure where this thread is going, I'll say that I think a huge number of moving WP users would benefit most from: 1) a really great starter theme that incorporates a strong set of features and is very flexible for styling (a la Zen), 2) a very clear recipe of essential modules (Views, CTools, etc.) that helps them skip the painful process of trying to decipher differences between modules (especially when some are clearly considered essential within the Drupal community), and 3) a theme that makes it easy to have much less experienced users (say those with general proficiency in Microsoft Word) be able to create and edit posts.

My apologies for this post, Jeff. I think this isn't at all what you're trying to address. But it is a serious issue if the goal is to attract web designers from the WP and Joomla worlds.


Jeff Burnz's picture

it is a serious issue if the goal is to attract web designers from the WP and Joomla worlds...

Yeah, I have spoken to a lot of WP and Joomla users (I just spent 3 months working with one of the top Joomla theme shops). That said shortcodes/pre loaded classes etc are only one bit of the new WP theme, a lot of other interesting things in that theme as well.

I agree that we seem to be

SKrossa's picture

I agree that we seem to be missing each others points.

In your original post you emphasized "short codes":

WP and Joomla themes are huge on "short codes", this theme uses them also - basically users can insert a class into something…

Maybe we could include short codes in the new Drupal 8 theme?

I agree that debating implementations at this stage is probably not the most productive approach. But short codes —especially ones along the lines of your example [list, stars][/list]— are an implementation. (I note, btw, that the Twenty Eleven WP theme pull quote example linked to gives this syntax <blockquote class="pull alignright">Your quote here</blockquote> ;-)

It seems to me —and correct me if I'm still misunderstanding— that the idea/concept of interest here is not short codes, but rather themes (in particular the Drupal 8 theme) including CSS classes specifically intended for end users to use in general text, preferably with core/contributed module mechanism(s) to make it easy (but still secure) for users to invoke said classes. As I already posted, I think this is a great idea (and not a new idea to the Drupal ecosystem, though a really good easy implementation is still needed).

But what makes it a great idea has nothing to do with lowering "the cognitive overhead of those trying out Drupal who have previous experience with WP or Joomla." Rather, it is great because —if implemented well— it would help all users, including those who have no CMS or web content creation experience at all, to format/style their content elegantly and in harmony with their chosen theme's design.

I'm all for raiding WP and Joomla for good ideas that will help all users, but strongly opposed to looking for ideas whose primary virtue is that users of another CMS are used to it. Catering to what other CMS users are used to because they're used to it is really not a path we want to go down for a whole host of reasons. (Catering to what people in general, not just CMS users, are used to is a different matter. Hence, wysiwyg because the general computer-using public is used to word processors…)

With regard to:

I would have thought that was obvious and did not need to be explicitly stated.

Sorry—I was confused by the emphasis on short codes as a way to insert a class in your original post, and thought it worth clarifying that the examples you were using were not just about inserting classes.


Jeff Burnz's picture

Meh. I cited shortcodes as one interesting aspect, I was really hoping some intelligent and insightful people would pick out some other interesting things as well.

A few design thoughts

Andy Britton's picture

So back on topic, a few things I've been thinking of if this is included as a feature of the new D8 theme, more design related thoughts:

Is this something designers will be expected to include in submissions for the D8 theme or will a "generic" set of styles be put together by the team theming the selected design?

If designers can produce these "shortcodes" in a design submission can they expand on the norm by using tilable patterns/textures if the goal is to make content more attractive?

What would be the main elements that would be styled, how if at all possible can we add our own spin to what other systems are currently doing?


Jeff Burnz's picture

Been thinking about this a bit myself, maybe we can discuss this over the course of Design Camp Berlin - that will be a great venue to discuss these types of issues.

Thats what I usually do with my projects

alexrayu's picture

Thats what I usually do with my projects. Define classes with certain styling with css and reuse. We already have such classes in Drupal - like .clearfix class. When carried from project to project, these become a powerful tool to ease up things for clients. Say, they know, that they can create a paragraph with class .quote, and it will be styles nicely as a quote in the text.