Opened 14 years ago
Closed 14 years ago
#17198 closed task (blessed) (fixed)
New theme for 3.next -- Twenty Eleven
Reported by: | matt | Owned by: | |
---|---|---|---|
Milestone: | 3.2 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
It's been a few years since we did this (#9015) but let's track the effort for the Twenty Eleven theme, hopefully making 3.2, here.
Main goals besides what we've already done in Twenty Ten:
- To be different from Twenty Ten, aesthetically.
- Is a good showcase of WP's headline features.
- Clean, fast to load, and with best-practice markup.
Nice to have, but optional, improvements:
- Ability to have random rotating headers. (Core improvement to custom header functionality, see #17240.)
- Color and layout options.
- More post formats. (Currently supports Asides, Links, and Galleries.)
- CMS-style slider home page option.
Some people will prefer the design of Twenty Ten, which is still excellent, over Twenty Eleven, but that's okay. We'll have something new next year.
Attachments (15)
Change History (132)
#2
follow-ups:
↓ 13
↓ 36
@
14 years ago
Cross-referencing the commit:
matt in [17669]
Importing Duster theme, first pass at a candidate for twentyeleven theme.
Nice to have, but optional, improvements it'd be nice to have:
- Ability to have random rotating headers. (Core improvement to custom header functionality.)
- Color and layout options.
- More post formats. (Currently supporst Asides, Links, and Galleries.)
- CMS-style slider home page option.
Welcome, TwentyEleven n?\195?\169e Duster. :) Track at #17198.
#3
follow-up:
↓ 7
@
14 years ago
Line endings should be svn:eol-style native, so \r\n or similar shouldn't matter. We should make the text files have Windows-style endings though, if they don't already.
#7
in reply to:
↑ 3
@
14 years ago
Replying to matt:
Line endings should be svn:eol-style native, so \r\n or similar shouldn't matter. We should make the text files have Windows-style endings though, if they don't already.
I set svn:eol-style on the files - I suspect you may want to change it from native on readme and license based on this comment?
#11
@
14 years ago
- Cc michael@… added
I submitted this patch which has been picked up for 3.2 which should fix the notice issues in TwentyEleven: #16761
#13
in reply to:
↑ 2
@
14 years ago
Replying to dd32:
Nice to have, but optional, improvements it'd be nice to have:
- CMS-style slider home page option.
What exactly are you looking for here? Something like on http://www.fiftyandfifty.org/ or like http://xavisys.com or ???
#21
@
14 years ago
17672.html-id.diff adds conditional ids for IE6 and IE8 for users who will be using Twenty Eleven as a parent theme and may have use for those ids (an id for IE7 was already present in Duster).
#23
@
14 years ago
17198.showcase.2.diff adds full loop functionality back to the $featured
query since we can't rely on sticky posts being available (may be trashed) and ensures all loop actions are fired correctly, while avoiding invoking it at all when no stickies are set.
Also makes better use of $feature_class
and uses the native current post counter in the $recent
query.
#25
@
14 years ago
3.2 is marked as EOL for IE6 (for the admin), however themes (front end) should still support it so they have best compatibility. There are still people that are stuck in IE6. For them the admin would have limited functionality but the front end site should work.
#28
@
14 years ago
17672.status-quote-formats.diff adds support for Status and Quote format display, excludes those formats from the Showcase Recent Posts, and adds them to the posts included in the custom "Ephemera" widget. It also adds CSS section headers for each Format and the 404 styles in style.css.
@
14 years ago
Allows the /twentyeleven/ directory to be added, for anyone using the WordPress Beta Tester plugin, and updating nightly.
#31
@
14 years ago
I was hoping the above patch would solve the /twentyeleven/ directory being included in any updates used from within your dashboard, if you used say the WordPress Beta Tester plugin. Turns out I already had the theme there, after I uploaded it myself. But I'm finding that /twentyeleven/ isn't included when I went from 3.1.1 to 3.2-bleeding, so I can't try it out online!
#32
follow-up:
↓ 33
@
14 years ago
I was hoping the above patch would solve the /twentyeleven/ directory being included
I'll take care of that tomorrow
#33
in reply to:
↑ 32
@
14 years ago
Replying to dd32:
I was hoping the above patch would solve the /twentyeleven/ directory being included
I'll take care of that tomorrow
Cool, thanks. Obviously a little more work needed than adding a line of code? ;)
#34
follow-ups:
↓ 35
↓ 49
@
14 years ago
Adding that line should've done it. However, it should be fine as '3.2', and it also needs to be set in the file -during- the 3.1.x -> 3.2 update, ie. within the update zip. There may be other things at play here though, so I'll check it during testing.
@
14 years ago
Minor style fixes (overflow) for international blogs and replacing em dash with the proper CSS value for the entity.
#47
@
14 years ago
(In [17721]) Twenty Eleven: functions.php cleanup and introduction of theme options; see #17198
- Cleanup functions.php, adding comments and function_exists() checks following Twenty Ten's example
- Theme option for choosing an alternate (dark) color scheme. It currently only loads a placeholder CSS file with dark styles to follow.
- Theme option for selecting a link color that loads an internal style block for resetting link colors. An updated style.css will follow to take advantage of this.
- Theme options for selecting an alternate layout. Adds a class to the body element. An updated style.css will follow to take advantage of this.
#48
follow-up:
↓ 49
@
14 years ago
Can we set a default
case for the switch
statement in the twentyeleven_comment()
function? It would be as simple as moving the first check down to the bottom and changing the case
to:
default :
Currently, this function handles the comment
, trackback
, and pingback
comment types. All other comment types are skipped. By default, WordPress core functionality handles custom comment types just fine.
This is also an issue in the TwentyTen theme and now many, many themes being submitted to the theme repository because so many theme authors just copy/paste code from the default WordPress theme.
#49
in reply to:
↑ 48
;
follow-ups:
↓ 52
↓ 54
@
14 years ago
Replying to greenshady:
Can we set a
default
case for theswitch
statement in thetwentyeleven_comment()
function?
Makes sense to me, plus it's a good practice in programming in general to have a default case for switch statements. Patch looks good, thanks Justin.
#52
@
14 years ago
Related to Twenty Eleven (but should work with any theme), I added a patch for #17240 that will load a random image from the theme's registered header images.
Note: Twenty Eleven only has one header image right now (more coming soon), so test it out with Twenty Ten.
#53
follow-up:
↓ 55
@
14 years ago
- Description modified (diff)
- Summary changed from New theme for 3.next -- TwentyEleven to New theme for 3.next -- Twenty Eleven
#57
@
14 years ago
(In [17733]) Rewrite of Twenty Eleven theme-options.php. Including:
- Full inline documentation.
- Enqueue scripts/styles on admin_enqueue_scripts and use hook_suffix rather than GET[page]
- Add filters to twentyeleven_color_schemes(), twentyeleven_layouts(), which necessitates adding a thumbnail URL value here, rather than generating them in the form.
- Add a twentyeleven_default_theme_options filter.
- Remove manual check for REQUEST[settings-updated], instead using settings_errors(), since we're using options.php.
- Abstract out the default link color, rather than hardcoding it in certain places.
- Use checked().
- Rename some variables and functions for clarity.
- Remove unnecessary functions twentyeleven_current_layout() and twentyeleven_current_color_scheme(), as we already have twentyeleven_get_theme_options().
- Add a twentyeleven_color_schemes action to allow for enqueueing custom color schemes.
- Add a twentyeleven_layout_classes filter, to allow filtering what gets sent back to body_class().
- Hook into wp_enqueue_scripts rather than wp_print_styles for enqueueing the color stylesheet.
- Rewrite the register_setting() callback to start from scratch with an empty array. Improve the link_color logic.
- Use submit_button().
- Use esc_attr() rather than esc_attr_e() for non-translations.
TODO:
- Implement settings sections/fields logic to allow extension of the options page.
- Consider re-doing this in a class. It'll be cleaner.
- Store a DB version so we can do an add_option(), rather than calling get_option() with defaults.
see #17198.
#58
@
14 years ago
(In [17734]) Twenty Eleven:
- Use add_option(), rather than get_option() with defaults, to prevent notoption queries.
- Add twentyeleven_theme_options_validate filter, that way one doesn't need to add a filter to sanitize_option_\$option to allow more options in.
- Some inline doc modifications and additions.
see #17198.
#64
@
14 years ago
(In [17740]) Rename twentyeleven_color_schemes hook to twentyeleven_enqueue_color_scheme, so its purpose is clear. Also rename twentyeleven_color_styles() to twentyeleven_enqueue_color_scheme(), and twentyeleven_link_color() (which sounds like a getter) to twentyeleven_print_link_color_style(). Some tidying in twentyeleven_layout_classes(). see #17198.
#66
in reply to:
↑ 60
;
follow-up:
↓ 67
@
14 years ago
Replying to nacin:
Fix up the color picker JS. Use a separate color swatch rather than the input background. While cool, it doesn't have suffficient contrast.
Farbtastic has the contrast built in, but we were calling it wrong. I'll fix it up — the color change on the input element is the intended interaction, and much cleaner and simpler than the extra swatch.
#67
in reply to:
↑ 66
;
follow-up:
↓ 69
@
14 years ago
Replying to lancewillett:
Farbtastic has the contrast built in, but we were calling it wrong. I'll fix it up — the color change on the input element is the intended interaction, and much cleaner and simpler than the extra swatch.
I'd be interested to see a patch. I've seen that behavior before, but it's not what we do elsewhere in core, and I don't think it would be sufficiently high-contrast per accessibility standards. To be honest I found it annoying and tough to read even when using light colors with the black text.
@
14 years ago
Sample of how to implement the color contrast with farbtastic on the input element directly
#69
in reply to:
↑ 67
;
follow-up:
↓ 70
@
14 years ago
Replying to nacin:
it's not what we do elsewhere in core, and I don't think it would be sufficiently high-contrast per accessibility standards.
(Idea of how I'd do it on the input element is in "farbtastic-color-input.diff" patch — purely as an example.)
Good points, Nacin. Looking at Background color chooser and Header text color chooser it makes sense to match the same UI and interaction. That means we'll need to use a button instead of text link for the "Select a color" action.
Talking it over with Ian, he likes the swatch, too. But suggests we make it a link so it would also open the color selector.
#70
in reply to:
↑ 69
@
14 years ago
Replying to lancewillett:
Looking at Background color chooser and Header text color chooser it makes sense to match the same UI and interaction.
Actually, Background uses a text link. We'll need to patch that up, too.
#76
@
14 years ago
(In [17761]) Twenty Eleven: style.css cleanup and Showcase template improvements, props matveb - see #17198
- Add full support for the featured slider powered by JS (except auto-slide)
- Change the title hover state of large stickies to white
- Prevent plain text posts from being displayed transparently over images
- Update slider featured image size to 500x300
- Add comment blocks to showcase.php
#35
in reply to:
↑ 34
@
14 years ago
Replying to iandstewart:
Twenty Eleven: Post Format headings [...]
Not sure if it's up for discussion, but I'm not sure what I think of them?
Yeah, fair enough, I like that we're trying to make it look a lot different from TwentyTen, but I feel they're just out of place within TwentyEleven. Would having icons, or similar, not make for a better change?
#36
@
14 years ago
- Cc heymrpro@… added
Small but vexing question: the Theme Options Admin Screen in Twenty Eleven has only two generic links in the contextual help tab... Does the theme-options file in the theme folder in wp-content call something in wp-admin that could be fixed to apply to all themes that have theme options? (Like Background and Header do) I think it would be easier, but less optimal to add help tab content in the Twenty Eleven file itself.
And, yes, this screen provides highly obvious options, but we could say it changes colors and layout and then come up with a few nuggets/links for people who wanted to make more such changes, go under the hood, use the theme editor, modify some CSS, create a child theme...
#42
@
14 years ago
The patch above corrects the inline documentation for calling the Post Format, and creating seperate templates within a Child Theme! (s/loop/content/)
#46
in reply to:
↑ 68
;
follow-up:
↓ 48
@
14 years ago
Replying to iandstewart:
(In [17752]) Twenty Eleven: First pass at styles to support the theme option for alternate layouts; See #17198
Support for alternate layouts is not complite, missing some layouts:
- sidbar-content-sidebar (the most important layout)
- sidbar-sidebar-content
- content-sidbar-sidebar
function twentyeleven_layouts() { $layout_options = array( 'content' => array( 'value' => 'content', 'label' => __( 'One-column, no Sidebar', 'twentyeleven' ), 'thumbnail' => get_template_directory_uri() . '/inc/images/content.png', ), 'content-sidebar' => array( 'value' => 'content-sidebar', 'label' => __( 'Content on left, Sidebar on right', 'twentyeleven' ), 'thumbnail' => get_template_directory_uri() . '/inc/images/content-sidebar.png', ), 'sidebar-content' => array( 'value' => 'sidebar-content', 'label' => __( 'Content on right, Sidebar on left', 'twentyeleven' ), 'thumbnail' => get_template_directory_uri() . '/inc/images/sidebar-content.png', ), 'sidebar-content-sidebar' => array( 'value' => 'sidebar-content-sidebar', 'label' => __( 'Content on center, two Sidbars', 'twentyeleven' ), 'thumbnail' => get_template_directory_uri() . '/inc/images/sidebar-content-sidebar.png', ), 'content-sidebar-sidebar' => array( 'value' => 'content-sidebar-sidebar', 'label' => __( 'Content on left, two Sidebar on right', 'twentyeleven' ), 'thumbnail' => get_template_directory_uri() . '/inc/images/content-sidebar-sidebar.png', ), 'sidebar-sidebar-content' => array( 'value' => 'sidebar-sidebar-content', 'label' => __( 'Content on right, two Sidebar on left', 'twentyeleven' ), 'thumbnail' => get_template_directory_uri() . '/inc/images/sidebar-sidebar-content.png', ), ); return apply_filters( 'twentyeleven_layouts', $layout_options ); }
#48
in reply to:
↑ 46
;
follow-up:
↓ 49
@
14 years ago
Replying to ramiy:
Support for alternate layouts is not complite, missing some layouts:
Twenty Eleven has a single sidebar, so the layouts you mentioned aren't applicable.
#49
in reply to:
↑ 34
;
follow-ups:
↓ 52
↓ 54
@
14 years ago
Replying to iandstewart:
In [17788]:
Hi @iandstewart! I'm not sure how to submit a patch.. So, I'll comment here. Please make the post format headings ready for i18n. Example:
<h2 class="entry-format"><?php _e( 'Aside', 'twentyeleven' ); ?></h2>
Thanks!
#50
follow-up:
↓ 53
@
14 years ago
This is more of a design preference. Is there an option to keep the sidebar active on single.php instead of having it no longer there? I've never been crazy about the look of the default one-column width/centering in Twenty Ten and it seems to be carrying over to Twenty Eleven. I'd suggest just keeping the widgets on single.php by default.
#51
@
14 years ago
When header text is disabled, the search is over the navigation, doesn't look good: http://d.pr/z0c1
#52
in reply to:
↑ 49
@
14 years ago
Replying to nickbohle:
I'm not sure how to submit a patch.
It's fun and easy. See http://codex.wordpress.org/Reporting_Bugs#Patching_Bugs and we suggest also following along at http://patcheswelcome.wordpress.com/.
#53
in reply to:
↑ 50
;
follow-up:
↓ 55
@
14 years ago
Replying to jason@…:
This is more of a design preference. Is there an option to keep the sidebar active on single.php instead of having it no longer there?
There isn't an option on posts for including a sidebar in Twenty Eleven but there is an optional custom page template for pages that includes a sidebar.
#54
in reply to:
↑ 49
@
14 years ago
Replying to nickbohle:
Please make the post format headings ready for i18n.
Can do and will do. Thanks for noticing they were missing.
#55
in reply to:
↑ 53
;
follow-up:
↓ 56
@
14 years ago
Replying to iandstewart:
There isn't an option on posts for including a sidebar in Twenty Eleven but there is an optional custom page template for pages that includes a sidebar.
So I guess that's pretty definitive to leave off widgets on single.php? While aesthetically pleasing I think it may be too brazen for most WordPress users to suddenly lose one of the most crucial WP content areas on post pages. It's easy enough for me to put it back in as a developer but I think it will be a turnoff to regular bloggers if there's no easy/non-code option to choose whether to display widgets on posts. So much important stuff happens in widgets (ads, widget context, secondary navigations etc.). I think widgets are just as important on post pages as anywhere else (actually I'd argue they can be even more important on post pages for some cases). Just some food for thought. I love the theme and will use it and just put the sidebar back in for my child themes. But I'm just making this suggestion to save me, other developers and bloggers a little time as I can't think of any theme I'd make for a client that wouldn't utilize a sidebar on post pages. If the majority agrees with me I'm happy to adjust the single.php template and modify the CSS and contribute that in the appropriate place :-)
#56
in reply to:
↑ 55
@
14 years ago
Replying to jason@…:
Replying to iandstewart:
There isn't an option on posts for including a sidebar in Twenty Eleven but there is an optional custom page template for pages that includes a sidebar.
While aesthetically pleasing I think it may be too brazen for most WordPress users to suddenly lose one of the most crucial WP content areas on post pages.
Twenty Eleven, like Twenty Ten, has footer widget areas that appear above the footer on every page, post. Essential widgets could live there if they always need to appear.
#57
@
14 years ago
I'm taking a more design practical approach. If you're selling ads on your blog, putting them in the footer is just not going to cut it. I really feel pulling the sidebar from the single.php is going to be a deal-breaker for non-developer bloggers. If there's a good rationale for taking it out by default I'm all ears.
#59
follow-up:
↓ 60
@
14 years ago
There's also been a discussion to change "Theme Options" to "Colors & Layout".
#60
in reply to:
↑ 59
;
follow-ups:
↓ 66
↓ 67
@
14 years ago
Replying to nacin:
There's also been a discussion to change "Theme Options" to "Colors & Layout".
Not a future-proof idea. What would you call it if more options were to be added in the future?
"Theme Options" is the standard label, and it's what core calls them (see "edit_theme_options" capability, for example.)
#61
follow-up:
↓ 64
@
14 years ago
Replying to jason@…:
[...] If there's a good rationale for taking it out by default I'm all ears.
Part of the rationale for it was to put the content and comments on prime focus, while also allowing for layout flexibility when creating said content: see http://twentyelevendemo.wordpress.com/a-parent-page/
#62
@
14 years ago
Added #17359 for allowing tags for features introduced to Twenty Ten (and still enabled in Twenty Eleven).
#64
in reply to:
↑ 61
@
14 years ago
Replying to matveb:
Part of the rationale for it was to put the content and comments on prime focus, while also allowing for layout flexibility when creating said content: see http://twentyelevendemo.wordpress.com/a-parent-page/
I see. I hadn't tried out those types of blockquotes and images. It is quite elegant. I think allowing users to have a choice of template in the admin for single.php may still be the best bet. I already use a plugin for this so I guess I'll just have to bundle that with sites I deliver for clients.
#67
in reply to:
↑ 60
;
follow-up:
↓ 69
@
14 years ago
Replying to lancewillett:
"Theme Options" is the standard label, and it's what core calls them (see "edit_theme_options" capability, for example.)
Most if not all Settings in core are handled with *option* functions. A number of plugins provide links to their Settings. Just looking for consistency.
Fix wrong html5.js path in header.php