Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#21951 closed enhancement (fixed)

Twenty Twelve: add post_type_archive_title to archive.php

Reported by: thomask's profile thomask Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords: has-patch
Focuses: Cc:

Description

Archive.php template (twenty twelve, but if i remember it right, it is in twenty eleven as well) shows also (custom) post type archives, but their definition is missing so there is no title for it.

Solution - add

elseif ( is_post_type_archive() ) {
						printf( __( 'Archives: %s', 'twentytwelve' ), '<span>' . post_type_archive_title( '', false ) . '</span>' );
					} 

at around row 33 (i do not know how to create diffs, sorry)

P.S.: i am not english, so maybe you will found someting better then just Archives: %s

Attachments (3)

21951.twentytwelve.diff (757 bytes) - added by DrewAPicture 11 years ago.
Twenty Twelve
21951.twentytwelve.2.diff (967 bytes) - added by obenland 11 years ago.
21951.diff (8.8 KB) - added by nacin 11 years ago.

Download all attachments as: .zip

Change History (39)

@DrewAPicture
11 years ago

Twenty Twelve

#1 @DrewAPicture
11 years ago

  • Cc xoodrew@… added
  • Keywords has-patch added
  • Summary changed from missing post_type_archive_title from archive.php to Twenty Twelve: Missing post_type_archive_title from archive.php

Replying to thomask:

at around row 33 (i do not know how to create diffs, sorry)

You can find information about how to create patches in the handbook

21951.twentytwelve.diff covers Twenty Twelve.

#2 @obenland
11 years ago

  • Milestone changed from Awaiting Review to 3.5
  • Severity changed from trivial to normal
  • Type changed from defect (bug) to enhancement

Tried to also include custom taxonomy archives. Is there a better way to get the taxonomy name than what I came up with? @nacin probably won't like it. :)

I find "Portfolio Archives:" has a better ring to it than "Archives: Portfolio". What do you think?

Version 0, edited 11 years ago by obenland (next)

#3 @SergeyBiryukov
11 years ago

Perhaps the colon at the end of '%1$s Archives:' in 21951.twentytwelve.2.diff is not needed ("Blog Archives" doesn't have it).

#4 follow-up: @lancewillett
11 years ago

I vote not to add this to Twenty Twelve. I've not seen is_post_type_archive() used in a theme before.

#5 in reply to: ↑ 4 @DrewAPicture
11 years ago

Replying to lancewillett:

I vote not to add this to Twenty Twelve.

I think in the vein of promoting the extension of Twenty Twelve, including a title -- albeit a general one -- for custom post type archives is an easy step toward that goal. Sure, I can add one when I make my child theme but it feels so much better to see that I've already got an "archive" for my post types out of the box.

I've not seen is_post_type_archive() used in a theme before.

Never too late to start :)

@nacin
11 years ago

#6 follow-up: @nacin
11 years ago

So, archive.php can be used in a number of situations: authors, dates, categories, tags, other taxonomies, and post type archives.

There's already an author.php. There is also a lot of conditional code in archive.php for dates, categories, and tags. Thus, "Blog Archives" would only apply for custom taxonomies and post type archives. In that case, a generic "Archives" (rather than "Blog Archives") seems sufficient.

But when you look at it, wouldn't it be cleaner if Twenty Twelve had a date.php, category.php, and tag.php? I'm thinking about the approach a user would take, trying to customize their theme, probably from the theme editor, without knowing a thing about WordPress. (Been there, many years ago.) I'd rather leverage the existing hierarchy than fill up a catchall template with conditionals. Then archive.php is just a weak container for custom taxonomies and post type archives.

I'm just playing around here, but 21951.diff.

#7 @nacin
11 years ago

Worth noting that Twenty Twelve *does* have one other taxonomy that "Archives: " + single_term_name would support, which is post formats. As in, /type/image.

#8 follow-up: @lancewillett
11 years ago

At the beginning of Twenty Twelve development we decided to simplify it over Twenty Eleven, so removed all those extra term archive templates.

I'd rather not add them back now, especially a few days before freeze.

#9 in reply to: ↑ 8 ; follow-up: @nacin
11 years ago

Replying to lancewillett:

At the beginning of Twenty Twelve development we decided to simplify it over Twenty Eleven, so removed all those extra term archive templates.

I guess the question is, which is simpler?

#10 @lancewillett
11 years ago

  • Summary changed from Twenty Twelve: Missing post_type_archive_title from archive.php to Twenty Twelve: add post_type_archive_title to archive.php

#11 in reply to: ↑ 9 ; follow-ups: @lancewillett
11 years ago

Replying to nacin:

I guess the question is, which is simpler?

Fewer template files.

#12 in reply to: ↑ 11 @obenland
11 years ago

Replying to lancewillett:

Fewer template files.

I agree with Lance on the template issue. Except for the archive title, the rest of the template is the same anyway. I rather have a bit more code in archive.php than more files.


I vote not to add this to Twenty Twelve. I've not seen is_post_type_archive() used in a theme before.

I think archive titles dedicated to custom taxonomies and post types would be a nice addition. I'll refresh the patch to pick up the term_description() part from @nacin. Except that it never was done before, are there additional things that bother you about this?

#13 in reply to: ↑ 11 ; follow-ups: @dd32
11 years ago

Replying to obenland:

Replying to lancewillett:

Replying to nacin:

I guess the question is, which is simpler?

Fewer template files.

I agree with Lance on the template issue.

The problem with those answers, is that it's coming from a Theme Developer; a PHP Developer; someone who knows their stuff - look at it from the other side of the fence, someone newer to theme development and potentially not very PHP smart, multiple files may be simpler, and as a bonus, it also enforces the concepts of template hierarchy.

It goes to the notion that different parts of the Theme are different files - as that's the notion that most people are used to, they're not thinking of an Archive of posts categorized by random things, they're thinking that they want to customise their Category page (and then being confused why the year view was changed too).
Of course.. the thing is, having it as one larger file doesn't prevent people from using category.php in their child themes, it's only those who copy the theme verbatim which benefits from separate files - potentially the people who would benefit from multiple files the most.

If it's not obvious enough, I like the separate files, and am surprised that more people don't release themes that way - there's a reason most frameworks come with every template file under the sun documented and loaded.. not just for the extra bloat factor, but because it makes it easier for some.

especially a few days before freeze.

In this case, since there's no imminent deadline (tied to a major WordPress release for example) and it doesn't significantly alter how the theme operates, I don't see that as a good reason to not consider the merits.

Last edited 11 years ago by dd32 (previous) (diff)

#14 in reply to: ↑ 13 @nacin
11 years ago

Replying to dd32:

Going to have to strongly agree with dd32 on this. I'll also emphasize that I started messing with WordPress themes in the theme editor, with no knowledge of our templating language or hierarchy, and not much PHP experience at the time. The template hierarchy is, quite simply, simply easier to understand. It is truly the basis of how WordPress themes are developed, and for good reason.

In this case, since there's no imminent deadline (tied to a major WordPress release for example) and it doesn't significantly alter how the theme operates, I don't see that as a good reason to not consider the merits.

Twenty Twelve *is* slated for this coming week, but I'd rather take the time to get it right. If we release 3.4 with problems, we can do a 3.4.1. But with a default theme, once you do a 1.0, your hands are mostly tied.

#15 @lancewillett
11 years ago

It's funny to hear these comments from the core team when Twenty Eleven was criticized for being too clever and over-the-top with all its template files.

#16 in reply to: ↑ 13 @lancewillett
11 years ago

Replying to dd32:

I don't see that as a good reason to not consider the merits.

Having many more template files adds cognitive overload. You open the theme. OMG! What are all these files for?! Versus: archive.php -- oh, that makes sense, that must show archives.

#17 @lancewillett
11 years ago

I feel very strongly about adding a template for every single archive view. That is perfect for a child theme to implement if it wishes to.

The default theme does not need to be the most complex and perfect theme to end all themes. See http://make.wordpress.org/themes/2012/09/18/default-themes-change-each-year/ for more on this philosophy.

Related to simplifying the theme this way, we have also removed these files in the popular _s starter theme (back in January 2012) for this very reason. It's simpler and the code is duplicated throughout: https://github.com/Automattic/_s/commit/73ffdba03cd42453f0938ca5b961e00a1193ca08.

#18 @lancewillett
11 years ago

  • Milestone 3.5 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#19 @thomask
11 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I think, that both ways are wrong - i would choose more files, because when developer opens the file, it has just few rows, each exactly for that particular job.

But i think, we should consider IMO third sollution. We have so huge/many files because 2 simple needs

  1. show title. Why the hell we need so huge function to show just the title?!?! Look at this:
<?php
if ( is_day() ) {
	printf( __( 'Daily Archives: %s', 'twentytwelve' ), '<span>' . get_the_date() . '</span>' );
} elseif ( is_month() ) {
	printf( __( 'Monthly Archives: %s', 'twentytwelve' ), '<span>' . get_the_date( _x( 'F Y', 'monthly archives date format', 'twentytwelve' ) ) . '</span>' );
} elseif ( is_year() ) {
	printf( __( 'Yearly Archives: %s', 'twentytwelve' ), '<span>' . get_the_date( _x( 'Y', 'yearly archives date format', 'twentytwelve' ) ) . '</span>' );
} elseif ( is_tag() ) {
	printf( __( 'Tag Archives: %s', 'twentytwelve' ), '<span>' . single_tag_title( '', false ) . '</span>' );
} elseif ( is_category() ) {
	printf( __( 'Category Archives: %s', 'twentytwelve' ), '<span>' . single_cat_title( '', false ) . '</span>' );
} else {
	_e( 'Blog Archives', 'twentytwelve' );
}
?>

(and it still miss the post_type_archive_title or any other title, which may be needed in archive.php (search???)

Why we simple do not have something like the_archive_title() and get_archive_title(), which would contain this complex function in it and return always the proper title. Translations of the context can be easily done from standard .pot, and/or the function could have some optional parameters, where you can define sprintf format form for each term ... array('day'=>Daily Archives: %s', 'month'=>'Monthly Archives: %s'...). And when someone would need something special, the output would be filtered so he can use filter, or he can always replace it with today's function.

The second complexity is very similar, but not for title, but for description.

So if we would put to wordpress those two simple function, we could stay with only one very easy-to-read and short archive file, which would fit needs for 99,9% developers. At it would be also future proof as when we will need to add anything else to archive, we just update this function

This is how the header part of header.php would look and we will save 30 rows (or 5 diferent files)

<header class="archive-header">
<h1 class="archive-title"><?php the_archive_title() ?></h1>

<div class="archive-meta"><?php the_archive_description ?></div>

</header><!-- .archive-header -->

#20 @lancewillett
11 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Closing as wontfix -- the extra archive title is perfect case for child themes.

#21 @thomask
11 years ago

  • Keywords 2nd-opinion added

Sorry, could we please put this to some wider discussion and not just close/wontfix it without knowing more opinions?! (I am not reopening it now as you are the boss, so it is up to you, but i strongly disagree)

  1. problem of the current sollution, is that we have to create new archive file for every custom post type, even when we are perfectly OK with the other archive.php content, or we need to copy current archive.php and change it. There is even no easy way, how we can filter it. So if you realy want to stay with the current sollution, *please* at least do a filter for
else {
						_e( 'Blog Archives', 'twentytwelve' );
					}

or better - replace all printf to sprintf and then filter the result.

  1. problem of the current sollution is its complexity - programmer needs to know, that archive.php is used for tons of needs and each of them needs special title and and description.

My sollution with the_archive_title() and the_archive_description () would cut the complexity (actualy it is than the same as that sprintf() in above point, with advantage that it is then easy to read and code).

#22 follow-up: @nacin
11 years ago

  • Milestone set to 3.5
  • Resolution wontfix deleted
  • Status changed from closed to reopened

lancewillett and I agreed that 'Blog Archives' should become 'Archives'.

There is still a disagreement among conditionals piled into archive.php versus separate template files for tag.php, date.php, category.php, and taxonomy.php.

I am re-opening this for further discussion and I'll be adding it to the agenda for the dev meeting on Wednesday.

#23 @lancewillett
11 years ago

In [21976]:

Twenty Twelve: remove the word "Blog" from archive title, see #21951. Also remove from two comments in functions.php.

#24 in reply to: ↑ 6 ; follow-up: @iandstewart
11 years ago

  • Cc ian@… added

Replying to nacin:

But when you look at it, wouldn't it be cleaner if Twenty Twelve had a date.php, category.php, and tag.php? I'm thinking about the approach a user would take, trying to customize their theme, probably from the theme editor, without knowing a thing about WordPress. (Been there, many years ago.) I'd rather leverage the existing hierarchy than fill up a catchall template with conditionals.

I used to feel the same way, and somewhat strongly, until I realized that in practice this seems to rarely happen with themes and that what you have is a bunch of templates hanging around that are modular for no particular reason. I think, in the end, it's actually easier to grok archive templates with those conditionals for the title-ey bits. Anyone needing to change anything more, developer-ey people, will know they can take advantage of the template hierarchy in a fork or a child theme. It's more code in the one template but more templates feels way heavier. Anecdotally I've seen lots of themers saying the same thing in forums.

Last edited 11 years ago by iandstewart (previous) (diff)

#25 in reply to: ↑ 24 @DrewAPicture
11 years ago

  • Keywords 2nd-opinion removed

It's my belief that the "default" theme is supposed to act as a showcase of WordPress' features, including the template hierarchy. However, now that I've thought about it a bit more, it seems to me that if the theme isn't bundled with custom post types, there shouldn't be an exception for one in archive.php. And if there isn't any kind of drastic difference between the types of archives, it makes plenty of sense to leave it condensed into archive.php

Replying to iandstewart:

It's more code in the one template but more templates feels way heavier.

In short, I agree with this sentiment and what @lancewillett said before about cognitive overload. You can always break them apart in a child theme.

Last edited 11 years ago by DrewAPicture (previous) (diff)

#26 @lancewillett
11 years ago

In [21992]:

Twenty Twelve: include a more verbose comment to educate themers on how to create specific template files for archive views, like tag.php and author.php. See #21951.

#27 in reply to: ↑ 22 @westi
11 years ago

Replying to nacin:

lancewillett and I agreed that 'Blog Archives' should become 'Archives'.

There is still a disagreement among conditionals piled into archive.php versus separate template files for tag.php, date.php, category.php, and taxonomy.php.

I am re-opening this for further discussion

My thoughts:

  • Separate files for this feels like bloat in my opinion too.
  • I think the learning case of knowing that you can just override one variant of the template in a child theme is better provided for by documentation and in tool hints and tips - If we were for example to iterate on the theme editor in future to make it easy to create a child theme for your site to customise it within the admin then when you went to modify the archive template I would expect this improved tool to guide you as to the type/types of file you could create/want to create.
  • If I was to do one thing to make this simpler it would be to make the archive-title section into a template part and thereby make it easier to customise just that part of the archive experience in a child theme - note I don't think we need to do that though.

#28 follow-up: @thomask
11 years ago

My thoughts were above. Please could you write here, why (if) you disagree with my idea of creating two new functions and showing archive like:

<header class="archive-header">
<h1 class="archive-title"><?php the_archive_title() ?></h1>

<div class="archive-meta"><?php the_archive_description ?></div>

</header><!-- .archive-header -->

Imo it is quite stupid to push developers to remember and use (and create conditionals for) all those just slightly different functions like single_cat_title, single_tag_title, post_type_archive_title and so on when i 99 % they use them just for outputing the title in the appropriate archive template.

IMO it is like having different name for post_name when on different taxonomies. My sollution would solve problems of all of you - we will get only one file, but it will be as simple as if we would use file for every archive type and will keep its complexity if needed via params, translations or replacing by those existing functions.

#29 in reply to: ↑ 28 @nacin
11 years ago

Replying to thomask:

My thoughts were above. Please could you write here, why (if) you disagree with my idea of creating two new functions and showing archive like:

It doesn't really matter — this ticket is about Twenty Twelve, which will be 100% compatible with 3.4. If you want to propose new functions, you are going to need to do it in a new ticket against core, not a bundled theme.

#30 @thomask
11 years ago

Thank you. I have filled it (#21995).

Of course for backwards compatibility there need to be if (!function_exist ()) condition in theme functions.php file and copying the new function there, as for all similiar theme enhancements.

#31 @knutsp
11 years ago

  • Cc knut@… added

I think that the very specific archive template files for author/date/tag/category/taxonomy should not be used by a theme, unless they actually must be structurally different and/or would have to use several similar if blocks to create the desired output in each case. The theme should just use the more general archive.php with conditionals when it's just about the header (title and description).

This then also goes for Twenty Twelve. Add some good comments to say that this archive.php may be split into separate files (name them) instead of adding more conditional statements for the rest.

The template hierarchy is one of the fundamentals of WordPress, that's right. But we don't need to be fundamentalists on this. Several files with 95% duplicated code is a bloat. archive.php is also part of the template hierarchy, it's not a hack, nor a shortcut. It's just common sense in most cases.

I also support the idea of two (four) new template functions to get the archive header elements without the need for conditionals. Elegant.

#32 @mdgl
11 years ago

My humble opinions are as follows (agreeing largely with thomask and knutsp):

a) A single "archive.php" rather than multiple templates for each archive type seems like the best compromise for an exemplar theme such as Twenty-Twelve. At one extreme, the template hierarchy means you could do everything within a single "index.php" but this would be rather complicated with much conditional code, etc. At the other extreme, utilising the hierarchy in full (e.g. including all attachment media types, author, tag, category, taxonomy, custom post type, ...) would result in too much duplication of code. A balance/compromise is therefore needed! In general, I think that archives are displayed in the same way with just the exception of the page title (and "not found" text) so this points to the use of a single generic template file. Changes appropriate to just a single content type are probably best left to child themes and use of the specialised template files.

b) Although custom post types are an extension to WP, I believe the exemplar theme should at least allow them to be viewed in some generic fashion via "archive.php" and "single.php". For practical purposes, you probably want to define custom post types in a plugin rather than a theme, because at least then your content remains viewable and editable in the admin tool, even when you switch themes. Yes, theme support will likely be required for almost all custom post types, but at least handling them to some extent makes the exemplar theme useful to child theme developers.

c) As thomask points out, the code in Twenty-Twelve's "archive.php" (and similarly in many other themes) is rather messy and much of this behaviour should be provided by core functions (e.g. see #21995). In fact, in my own theme I have further generalised those functions to cope with the header and description elements for other pages such as search and home. You end up with three separate core template tags for a page's title (wp_title()), page header and page description which can be applied everywhere. The challenge is to make these easily customisable where necessary :-) As I have commented elsewhere, this all points to the fact that the interface between WP core and themes (the "Theme API" if you will) is getting a little bit messy and could do with some love and attention (or "hardening") in 3.6. Just look at all of the outstanding tickets we have with basic functionality such as wp_title() and the_content()! And think of how many hours of effort are needed by the army of plugin/theme developers to check their fragile dependencies against core and update their workarounds on each new WP release!!

#33 @lancewillett
11 years ago

Much discussion today in IRC about the conditional logic in archive.php versus moving it into separate files (tag.php, et al).View the chat log. About evenly divided with good arguments from both sides.

Next step: Nacin is taking it to the core team for further discussion.

#34 @nacin
11 years ago

The debate in IRC was spirited. To the core team, I half-jokingly said I want a conversation like that every week. I should be careful what I wish for, I suppose, but on the other hand, needing to make a decision is exactly the purpose of our dev chats. If there's no discussion to settle a disagreement, it might as well be a blog post rather than a meeting.

Unfortunately, the dev chat could not come to an agreement. I can't remember the last time that happened quite like this. The core team talked it over. I asked Matt to make the call. After laying out both sides for him — he also read the logs — it was decided we'll be adding these templates.

It was also noted that since Twenty Ten had them and Twenty Eleven didn't, maybe Twenty Thirteen should go with the block of conditionals again. (I kid, kind of.)

I'm going to compromise a bit here. Since the proposed date.php still has a conditional block of is_day(), is_year(), and is_month(), I'm going to keep that in archive.php. Date-based archives is also more obviously an "archive" than categories or tags. (It's a shame we don't bother with hours, minutes, or seconds in our template!) That means we'll have category.php and tag.php, which each have specific description blocks that most concerned me in archive.php.

I'll also be converting any uses of brackets in templates to if/endif alternative style, as brackets can get lost (and spelling it out is more teachable, less cryptic). I had done it in date.php, but Matt actually pointed this out in particular.

I'm also going to shelve taxonomy.php, as post format archives haven't taken off yet (and Twenty Twelve doesn't link to them). Those too will fall back to archive.php, as will post type archives. Those are best left to a child theme for now.

If I proposed this in IRC, I have a feeling both sides would have capitulated. Alas, time to move on. We got a theme to ship.

#35 @nacin
11 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from reopened to closed

In [22048]:

Add tag.php and category.php to Twenty Twelve. While by no means required, it pulls some extra logic out of archive.php, instead leveraging the template hierarchy so it is hopefully more understandable to users tweaking their themes. Use alternative control structure syntax in all templates. fixes #21951.

#36 @lancewillett
11 years ago

In [22057] clean up tag.php extra newline, see r22048.

Note: See TracTickets for help on using tickets.