If the functionality is not related specifically to presentation of content, then it is squarely within Plugin Territory. This list is long:
- Modifying core WP filters (
wp_head
content, such as canonical links, generator and other HTML meta, etc - Site Favicon
- Post-content shortcodes
- Post sharing links
- Google Analytics (and similar) footer scripts
- SEO tools/controls
- etc.
If the functionality is related to presentation of content, then it is a candidate for being included in the Theme. At this point, I would revert to @Raf912’s Theme-switch criterion: would you miss the functionality when you switch Themes? If the answer to that question is no, then the functionality belongs in the Theme. Some examples:
- Removing/overriding the WP core Gallery CSS
- Filtering post excerpt length, “read more” text, etc.
- Anything implemented via
add_theme_support()
(I suppose this one should be obvious) - Custom CSS
Normally, these two questions will provide a fairly clear line of differentiation; however, there are exceptions.
Custom Post Types
Custom Post Types, for example, are a bit of a unique hybrid of content generation and presentation, given the way the Template Hierarchy works for single-post-type archive index pagesand single post pages. The content-generation aspect of CPTs would normally place them squarely in Plugin Territory; however, Plugins cannot define template pages that inherently fit into the design/layout/style for any given Theme (especially if the CPT displays other than the usual Title/Content/Meta, or has custom taxonomies associated with it).
Long-term, the solution to this disparity, IMHO, is to have a standard convention/consensus for the definition of CPTs for given types of content (real estate listings, calendar events, e-commerce products, book/media library entries, etc.). That way, user-generated content would remain portable between Themes that implement the standard/convention definition of a given CPT, while Theme developers retain the flexibility to define the design/layout/style of that CPT in the Theme template files.
Social Media Links
Similarly, I would normally say that social media profile links, ave become all but ubiquitous in current Themes, are Plugin Territory, because they have nothing to do with presentation of content. The best solution would be for these profiles to be defined somewhere in core; however, there is currently no standard/consensus means of defining these links. Are they best-defined at the site-setting level, or on a per-user basis? If per-user, which user’s meta gets exposed in the template? etc.
So again, long-term, the solution to this disparity is for either core to define where these links are defined, or else for the Theme developer community to develop its own consensus. In the meantime, there’s really nothing for it but to keep them defined within each Theme.