WordPress.org

Make WordPress Core

Opened 18 months ago

Last modified 11 days ago

#22314 new enhancement

Add singular.php to template hierarchy

Reported by: chipbennett Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.4.2
Component: Themes Keywords: has-patch needs-codex needs-testing
Focuses: template Cc:

Description

Currently, the template hierarchy includes a fallback template (archive.php) for all archive-index type pages (date, tag, category, taxonomy, author, blog posts index, custom post type index), but does not include an analogous fallback template for single-post type pages (blog post, page, attachment, custom post type). This patch adds singular.php to act as such fallback.

This change also ensures that all template context conditionals have associated template files. AFAIK, is_singular() is currently the only template context conditional that does not have such a corresponding template file.

Attachments (2)

singular.php.diff (1.2 KB) - added by chipbennett 18 months ago.
Adds support for singular.php template file
singular.php.1.diff (1.2 KB) - added by chipbennett 18 months ago.
Fixes get_singular_template() typo

Download all attachments as: .zip

Change History (14)

chipbennett18 months ago

Adds support for singular.php template file

comment:1 SergeyBiryukov18 months ago

  • Component changed from General to Template

comment:2 follow-up: cais18 months ago

A few questions ...

Is this meant to be a generic template for all single views essentially providing a merged single and page template, rather than falling directly back to index?

Although it would add a consistency to the template hierarchy, and possibly reduce a theme's payload by one (duplicated) file, what are the benefits to adding this template?

Would there be a similar benefit to having page fallback to single (or vice versa) instead?

comment:3 sabreuse18 months ago

  • Cc sabreuse added

comment:4 in reply to: ↑ 2 ; follow-up: chipbennett18 months ago

Replying to cais:

A few questions ...

Is this meant to be a generic template for all single views essentially providing a merged single and page template, rather than falling directly back to index?

Although it would add a consistency to the template hierarchy, and possibly reduce a theme's payload by one (duplicated) file, what are the benefits to adding this template?

I think the consistency is the benefit, in large part. Also, to me, it makes sense to have (the option to have) one template for outputting an index of posts, and one template for outputting a single post.

Would there be a similar benefit to having page fallback to single (or vice versa) instead?

Not really, IMHO; at least, no moreso than it would make sense to have category.php fallback to tag.php.

comment:5 in reply to: ↑ 4 ; follow-up: cais18 months ago

Replying to chipbennett:

I think the consistency is the benefit, in large part. Also, to me, it makes sense to have (the option to have) one template for outputting an index of posts, and one template for outputting a single post.

Does not the single template serve to display a single post? I am not inherently against the idea of adding another template; this discussion is meant more as a consideration of the current template choice logic and if it should be adjusted to take into account what you are suggesting your proposed singular template accomplish.

comment:6 in reply to: ↑ 5 chipbennett18 months ago

Replying to cais:

Replying to chipbennett:

I think the consistency is the benefit, in large part. Also, to me, it makes sense to have (the option to have) one template for outputting an index of posts, and one template for outputting a single post.

Does not the single template serve to display a single post?

Not for all post types, whereas the archive-index pages for all posts types will fallback to archive.php. The exception for single-post pages is the page post-type, which falls back directly to index.php. All the rest - post, attachment, and custom post types - fall back to single.php, then to index.php.

The analogy would be something like having author.php fallback directly to index.php, while all other index-archive type pages falling back to archive.php.

I am not inherently against the idea of adding another template; this discussion is meant more as a consideration of the current template choice logic and if it should be adjusted to take into account what you are suggesting your proposed singular template accomplish.

No worries. I'm just throwing the idea out there. If it gets implemented, then great. If not, then at least the reasoning will be documented here, should anyone ask about the (minor) inconsistency in the future.

comment:7 follow-up: toscho18 months ago

  • Cc info@… added

There is a typo in get_singlular_template(). Should be get_singular_template().

chipbennett18 months ago

Fixes get_singular_template() typo

comment:8 in reply to: ↑ 7 chipbennett18 months ago

Replying to toscho:

There is a typo in get_singlular_template(). Should be get_singular_template().

Aaargh. Fixed.

comment:9 mbijon18 months ago

  • Cc mike@… added

comment:10 nacin3 months ago

  • Component changed from Template to Themes
  • Focuses template added

comment:11 cramdesign11 days ago

This addition seems to make a lot of sense and would parallel is_single(), is_page() and is_singular().

comment:12 knutsp11 days ago

+1

is_singular() is currently the only template context conditional that does not have such a corresponding template file.

This seems a very natural addition to the template hierarchy. This means one can make a common template for all singular content and keep index.php more dedicated to showing multiple content. singular.php has become a "missing link" and it has to do with the introduction of custom post types, a special front page and an alternative "blog" page (posts index), and finally with the introduction of is_singular().

When making a child theme for a (multi) site with (usually, a common theme and) many custom post types I want to keep the templates collection as simple as possible. First I create special templates for CPT archives, tax archives and single CPTs with custom metadata. Other, more plain content, like posts, pages, other CPTs in singular form should be able to share a template file, sometimes with simple conditionals for the display, or not, of standard metadata (author, date etc).

Note: See TracTickets for help on using tickets.