Chip Bennett 3:21 pm on May 8, 2012
Tags: 3.4 ( 4 ), Guidelines ( 34 )

Proposed WordPress 3.4 Guidelines Revisions

As we near the final release of WordPress 3.4, it is time to begin discussion and finalization of the related changes to the Theme Review Guidelines. Below are the proposed changes. Please discuss in the comments. We’ll do our best to keep this proposed list updated based on discussions in the comments.

New WordPress 3.4 Functionality

Custom Headers/Backgrounds
- New and deprecated functions are already covered by existing Guidelines. Themes may OPTIONALLY provide backward-compatibility with pre-3.4 handling of custom backgrounds and headers
Child Themes
- Child Themes will formally be allowed to be submitted for inclusion in the Theme repository.
- Child Themes are REQUIRED to use an approved Theme as a Template (i.e. as the Parent Theme)
- Child Themes are REQUIRED to demonstrate sufficient difference from the Parent Theme to warrant inclusion
- Stand-alone Themes are REQUIRED to provide basic Child-Theme support, including:
  - Proper use of get_template_directory()/get_template_directory_uri() vs. get_stylesheet_directory()/get_stylesheet_directory_uri()
  - Proper enqueueing of stylesheets, and proper cascading of styles, including no inline styles in the Theme template
Backward Compatibility
- Backward compatibility is covered by existing Guidelines. Per existing Guidelines (2 major WP versions required/1 major WP version recommended):
  - Themes MUST NOT support backward-compatibility for more than two major WordPress versions (i.e. 3.2).
  - Themes are RECOMMENDED NOT to support backward-compatibility for more than one major WordPress version (i.e. 3.3).
Theme Settings and Data Security
- Themes are RECOMMENDED to incorporate Theme options into the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Theme customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings..

New Guidelines (REQUIRED)

Required HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and Navigation
- Add to list of template tags REQUIRED where appropriate: previous_image_link()/next_image_link() (or equivalent)
Theme Features
- If implementing a site logo, Themes are REQUIRED to provide user-configuration of the logo via the core custom headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. feature. (Exception: if incorporating both a site logo and custom header, the custom header is required to support the core custom header feature, and the custom logo is then required to be implemented via custom Theme option.)
Function Parameters, Filters, and Action Hooks
- Themes are REQUIRED to use function parameters, filters, and action hooks where appropriate in order to modify content, rather than hard-coding:
  - wp_title: Themes are REQUIRED to modify output via wp_title filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. (Refer to Codex note.)
  - body_class()/post_class():
    - Themes are RECOMMENDED to modify output via filter
      (body_class/post_class)
    - Themes may OPTIONALLY modify output via function parameter
      (body_class( $class )/post_class( $class ))

New Guidelines (RECOMMENDED)

Code Quality
- Themes are RECOMMENDED to follow the official WordPress coding standards for all PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. code.
- Themes are RECOMMENDED to follow the official WordPress CSS coding standards for all CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site..

Script Enqueueing

Themes are RECOMMENDED to enqueue the comment-reply script at the comment_form_before hook

function theme_slug_enqueue_comment_reply_script() {
	if ( comments_open() && get_option( 'thread_comments' ) ) {
		wp_enqueue_script( 'comment-reply' );
	}
}
add_action( 'comment_form_before', 'theme_slug_enqueue_comment_reply_script' );

Clarifications

Clarifications to existing guidelines being enforced:

Presentation vs Functionality
- Themes are REQUIRED to function as stand-alone code. Themes may OPTIONALLY integrate support for third-party Plugins; however, Themes are REQUIRED to degrade gracefully and to function fully and properly without any such Plugins active.

Feedback

What else should be included? What should be revised? Let us know in the comments.

#3-4, #guidelines

Andy Adams 4:36 pm on May 8, 2012

I’m not all too familiar with the .org theme repository requirements, so forgive me if I’m missing any background information. Thanks for all your work putting this together, Chip.

The piece that I would revise would be the requirement to use the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. custom headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. feature for logos. Many of the themes we develop use logos that don’t span the full width of the page, so it’s technically incorrect to call it a “header”. It comes down to semantics, I suppose. But I don’t like using the word “header” when it doesn’t apply.
- Chip Bennett 4:52 pm on May 8, 2012
  
  And thus, the discussion. 🙂
  
  The thought behind the requirement is two-fold: one, consistent UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. is ideal for the end user, and two, with the advent of flexible headers, the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. custom headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. feature becomes suitable for variable-sized logos.
  
  Personally, I think I’d rather see core implement a “site logo” option, because a site logo is Theme-independent (much like the site favicon, title, description, etc.), and then provide a way for Themes to incorporate/support that core feature.
- Greg Priday 4:59 pm on May 8, 2012
  
  3.4 gives you a lot more control over the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. size. So it doesn’t need to span the full width of the page. The nice thing about using WordPress’ header functionality is that (I assume) it’ll integrate with 3.4’s theme customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.. Pretty neat.
  
  I agree though, I think using “headers” as logos might confuse a user. Say the user switches from one theme that uses the header as a header, to another theme that uses the header as a logo. That might not go down too well.
  
  Having a site logo in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. would be a great solution but for now, maybe this requirement is a bit strict – given it’s essentially a hack.
  - Chip Bennett 5:04 pm on May 8, 2012
    
    Which would be easier to migrate in the future, if a “site logo” eventually becomes a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. option: a core custom headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. theme_mod, or a custom Theme option? I don’t know; maybe either one would be equally easy, or equally difficult.
    
    Also, my thinking with using custom headers for the logo is that it might help differentiate the logo as a site option, rather than as a custom Theme option. But the question of end user confusion may very well be valid…
- Devin Price 2:22 am on May 12, 2012
  
  I agree. If coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. had a “logo” option, I would say go ahead and make it a requirement. But headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. implies something different.
  
  Also, I assume themes that already have a logo option in their theme options would be required to change it, and that could be very confusing for users who update.
Konstantin 4:38 pm on May 8, 2012

Can we drop the requirement for the following, when loading a textdomain?

$locale = get_locale();
$locale_file = get_template_directory() . “/languages/$locale.php”;
if ( is_readable( $locale_file ) )
require_once( $locale_file );

See #20471

In the comment-reply example, the comments_open() is not necessary (is it?), as it is called just prior to the 'comment_form_before' action.
- Chip Bennett 4:49 pm on May 8, 2012
  
  Are you referencing the right TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket? At first glance, it doesn’t appear relevant to loading a textdomain.
  
  And you’re right: comments_open() is likely redundant in the example.
  - Konstantin Obenland 4:52 pm on May 8, 2012
    
    No I don’t, it’s supposed to be: https://core.trac.wordpress.org/changeset/20471
    - Chip Bennett 4:53 pm on May 8, 2012
      
      Ah, there it is. 🙂
      
      So, that bit is not actually required in order to load the locale file?
      - Konstantin Obenland 4:55 pm on May 8, 2012
        
        Not AFAIK. I’ve never seen locale files with the filetype being PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php.…
- Michael Fields 6:31 pm on May 8, 2012
  
  I spoke with Nacin regarding this over Skype and he explained that this code is not really necessary and that coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. would be moving away from loading .php files for i18n. It was also removed from Twenty Ten r20473, Twenty Twelve r19844. After seeing these changesets we removed it from _s as well.
  - Chip Bennett 6:52 pm on May 8, 2012
    
    Great! Less code FTW. 🙂
- Chip Bennett 6:57 pm on May 8, 2012
  
  So, where, exactly, are we actually requiring use of that code?
  - Michael Fields 7:40 pm on May 8, 2012
    
    I’m not sure, I just checked the docs and did not notice it as a requirement anywhere.
  - Konstantin Obenland 5:42 am on May 9, 2012
    
    We don’t explicitly. I suspect this falls under the “if you do it, do it right” approach we have towards i18n. But if you look for it in tickets, there are a few: https://themes.trac.wordpress.org/search?q=if+%28+is_readable%28+%24locale_file+%29+%29
    - Chip Bennett 6:42 pm on May 9, 2012
      
      I would probably chalk that up to a case of following the example of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-bundled Themes…
- Andrew Nacin 5:00 am on May 10, 2012
  
  There’s no reason at all for this code in a theme, ever.
- Rico Neitzel 6:34 am on June 14, 2012
  
  Hey Guys,
  
  dropping that would be bad for some german implementations. we’re using that file to rewrite permalinks for german sites… we don’t want to use a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party as this setting is theme related and not system wide.
  
  so removing that might raise an issue for us 🙂
  
  Best,
  Rico
  - Chip Bennett 12:34 pm on June 14, 2012
    
    If it works for you, keep using it. What we’ve done, though, is dropped it as a requirement. Generally speaking, a Theme is only required to load_theme_textdomain().
    - Middlesister 12:52 pm on June 16, 2012
      
      But if theme’s are not required to include a $locale.php, how would languages that need/utilize them be able to localize said theme properly?
      
      For example greek: http://themeshaper.com/forums/topic/thematic-in-greek
      
      What has changed that makes these files unneccessary?
      - Chip Bennett 2:00 pm on June 16, 2012
        
        In most cases, load_theme_textdomain( $textdomain, get_template_directory() . '/languages' ); will suffice. Just drop the language files, named appropriately (e.g. en_US.mo and en_US.po) in the /languages sub-folder inside the Theme, and WordPress will use them.
        
        If you still need to use $locale.php, then feel free to do so. We’re just no longer going to require that it be used.
ravi 4:45 pm on May 8, 2012

The section on “backward compatibility” is a bit confusing (to me): 2 major WP versions REQUIRED, 1 major WP version RECOMMENDED. That seems contradictory.
- Chip Bennett 4:50 pm on May 8, 2012
  
  Themes are required NOT to provide backward compatibility beyond two major WordPress versions, and they are recommended NOT to provide backward compatibility beyond one major WordPress version. The ideal is no backward compatibility at all, but that ideal simply isn’t practical.
Pingback: Wiki Duh » WordPress 3.4 Proposed Guidelines
Sayontan Sinha 9:37 pm on May 8, 2012

So, for the inline styles, consider this scenario:
1. Let’s say I have some widgets where the users can put in a color that they want some text to show up with in the front end.
2. There could be several instances of this widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user., each with a different ID, which is dynamically assigned at the time of rendering. In such a case how can the user input be captured as an external style?

I believe that inline styles should be allowed in such scenarios, because you are not taking away the flexibility from a user here: in fact you are offering the user the flexibility to provide such information through the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing..

Note that the upfront absence of the widget ID makes it almost impossible to determine this information upfront. You could, theoretically parse the array of widgets to find the ID whenever the widgets are updated, then save the information to an external stylesheet, but this is not going to provide any added flexibility, since the method of information entry itself is from the user rather than the developer.
- Chip Bennett 9:43 pm on May 8, 2012
  
  First, remember: in (almost) all cases, exceptions can be requested.
  
  Second: you’re talking about a WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user., not a template file.
  
  Third: outputting a user-defined style inline is entirely different from hard-coding inline styles. The point isn’t that there’s anything inherently wrong with inline styles, but rather that hard-coded inline styles are almost impossible to override. User-defined styles output inline don’t fall into that situation.
  
  I think your scenario is essentially an example of an exception that proves the rule.
Bruce Wampler 5:11 pm on May 9, 2012

I should have posted a comment from the reviewers list here, sorry…

But as Chip just said – the guide line applies to front end template files. After re-reading the guideline, it is clear that one of the main goals is to be sure child themes can essentially override anything the need to. Just keeping that goal in mind clarifies where inline styles really matter.

Rather than widgets, my question was about inline style in the admin side where a child is not as likely to need to override a style. My admin interface code is full of inline styles because it is just kind of difficult to create a bunch of totally arbitrary styles for the admin style sheet anyway.
Bruce Wampler 5:19 pm on May 9, 2012

Yet another point – partly because recommended often becomes required, so about this one:
Themes are RECOMMENDED to follow the official WordPress coding standardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook.
May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. for all PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. code.

I have a problem, sort of. Back when I started programming, and tab was based on 8 spaces. So I’ve always programmed with tabs or tabs+4 spaces for indentation. All my files use that – with the help of my IDE (Komodo). While not trivial, it certainly is possible to transform all that to 4 space based tabs which seems to be the PHP “standard”. Same with some of the other conventions, ( space in arg lists ) for example.

But a problem with massive reformatting like that is that it will essentially make a diff review impossible. Perhaps a solution would be to allow a “reformatting” submission that would be mostly about making the code follow the WP standards?
- Chip Bennett 6:39 pm on May 9, 2012
  
  There are certainly some who want to move in the direction of requiring WP coding standards, but I think we need to have a very long conversation before ever considering that. There are certainly a plethora of best practices in the coding/CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. coding standards, but that doesn’t mean that they should be required.
  
  One of the primary reasons for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to publish coding standards is to help ensure consistency among disparate patches committed by a growing number of contributors and committers. It is fairly important for the core codebase to be consistent, in order to facilitate troubleshooting, bug-fixing, and future code enhancements and changes. None of these issues apply for non-core-bundled Themes.
  
  We want to make the coding/CSS coding standards recommended, in order to help raise awareness of those standards among the Theme developer community. I don’t view this recommended status as an intended escalation (unlike, say, the Settings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. implementation, which I would prefer very much eventually to escalate to required); rather, I view it merely as awareness and promotion of best practices.
  
  I think it would be in the community’s best interest to consider each specific standard on a case-by-case basis, to determine appropriateness for inclusion in the Theme Review guidelines as required, rather than a wholesale adoption of those standards. By making the standards recommended, it opens the door to such further discussions within the community.
Pingback: The theme review team discusses changes for 3.4 | WPCandy
Andrew Nacin 5:07 am on May 10, 2012

A few points:

Both Twenty Ten and Twenty Eleven would fail a number of these guidelines, including: not enqueueing styles, not filtering wp_title(), etc. I would be happy to see a TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket to change these in 3.4 or 3.5. But until we do change them, I’m weary (but okay) with making these requirements.

The CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. guidelines are still in draft mode, and may not be finalized before 3.4’s release. They were proposed originally by the Automattic theme team and not yet endorsed by the various frontend developers working on coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

get_template_directory_uri() versus get_stylesheet_directory_uri() is not straightforward and may be tough to judge at times.
- Chip Bennett 5:07 pm on May 10, 2012
  
  I’ll be happy to submit any necessary patches for Twenty Ten and Twenty Eleven. If you see specific places where either would fail, just pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me and I’ll write them up.
  
  Thanks for the caveat regarding the CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. coding standards. That’s yet another reason that nothing more than recommended is appropriate at this time.
  
  In some cases, get_template_directory*() vs get_stylesheet_directory*() will be a matter of intended use; most of the time, though, the correct template tag to use is fairly clear. (Can/should be overridden by a Child ThemeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/.? Use stylesheet. Can’t/shouldn’t be overridden by a Child Theme? Use template.)
  - Justin Tadlock 6:04 pm on May 10, 2012
    
    The use of get_stylesheet_directory*() should rarely be used in standalone/parent themes. It makes the assumption that either a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. is not being used or that a particular file is housed within a child theme.
    
    Nearly always, if a regular theme is using *stylesheet*, it should be falling back to *template*.
- Konstantin 8:29 pm on May 10, 2012
  
  Oh, I’d love to contribute too (as a matter of fact, I have a patch prepared).
  
  @nacin: When you say “enqueueing styles” would that also include style.css?
Chip Bennett 5:02 pm on May 10, 2012

Please note the recent addition, under Clarifications, regarding stand-alone Theme functionality, and PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party integration. This is something the WPTRT has been enforcing all along, but is not explicitly spelled out in the current Guidelines.
Justin Tadlock 6:01 pm on May 10, 2012

Themes are RECOMMENDED to incorporate Theme options into the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Theme customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings..

Why recommend this at all? I’m already imagining disastrous scenarios of theme authors going too far. I definitely don’t want to see themes add 100s of options to this thing.
- Chip Bennett 6:47 pm on May 10, 2012
  
  I don’t understand the hesitation. Wouldn’t initial user configuration of custom Theme options via the customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings., upon Theme activation, provide the best-possible user experience?
  
  Sure, we’ll need to be sensible about how that integration takes place, but I think we can safely play that by ear as developers get their feet wet with the new feature. If we take the same philosophical approach with the customizer tab as we do with the Appearance sub-menu, I think we can reasonably keep things manageable, and avoid such disastrous scenarios as you’re envisioning.
  - Justin Tadlock 12:06 am on May 11, 2012
    
    It’s just a question of whether we really need to recommend it, especially until we see how theme authors are utilizing it. I’m neither for or against recommending it. I’d just like to be more cautious with it for a while.
    
    As far as best user experience goes, I agree, to a degree. It can make for a great user experience as well as a horrible one.
    
    It’s just something I thought I’d throw out there for discussion.
  - Andrew Nacin 2:35 am on May 11, 2012
    
    I agree with Justin. I would not “Recommend” it yet.
    - Chip Bennett 1:42 pm on May 11, 2012
      
      I can see where both of you are coming from. Maybe OPTIONAL is a better approach initially? I want the customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. feature to be in the Guidelines (as with basically every other coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. feature that touches or interacts with Themes), as a basis for establishing future implementation guidelines.
Konstantin Kovshenin 6:56 am on May 11, 2012

I think it’s also time to make wp_nav_menu required.
- Chip Bennett 1:44 pm on May 11, 2012
  
  well, wp_nav_menu() is required: if the Theme design incorporates a navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site.. The line we’ve not crossed thus far is dictating Theme design or aesthetic, and I’m not sure we want to cross that line. (Bear in mind that WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. support is required, and that Nav Menu Widgets can be added to dynamic sidebars – so technically speaking, all Themes do support navigation menus, at least in some form.)
Konstantin 7:12 am on May 11, 2012

I’d love to have a clearer Credit Link guideline with less leeway for both, Theme Authors and Reviewers!

I’m not too happy about the entire “Credit Link” section of the Theme Review codex page. And when I say not too happy, I mean I hate this part of every review, because of the enormous propability that my findings won’t correlate with the opionion of more seasoned reviewers (as it happened on this one).

What more is there to a Theme URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, other than it being a page specifically related to the Theme?
What is relevant and appropriate in a public-facing credit link?
What we understand under a project/development website?

As I said before, I think a clarification, and writing up requirements that are currently enforced but not documented, would benefit both, Theme Authors and Reviewers.
- Chip Bennett 2:01 pm on May 11, 2012
  
  I completely understand your frustration. Trying to keep credit link guidelines completely objective, while at the same time avoiding CFR-level detail and breadth, can be a delicate balance.
  
  Regarding the ticket you linked (and if you want to discuss that one specifically, I’d be happy to do so in-ticket), when I look at the Theme URI, especially for a site that would otherwise not be valid as Author URI, the red flag for me is the ratio of Theme-related content to non-Theme-related content. Another criterion for me is, “how beneficial is this content to the end user?” But these criteria are difficult-to-impossible to quantify objectively. Call it experience-based intuition. (Maybe call it jadedness from dealing with too many Themes with crappy credit links?)
  
  My personal preference/ideal for an appropriate Theme URI would be Theme-specific landing page on a Theme developer (or Theme shop) site, not an essentially orphaned page, with some Theme-related content, on a site otherwise unrelated to WordPress/Themes. But that preference is not the consensus, so we try to strike a balance regarding appropriateness.
  
  Theme URI is one of the most subjective guidelines, and as such ends up causing most of the headaches regarding Theme-review observations.
  - Konstantin 3:13 pm on May 11, 2012
    
    Please do share your thoughts in-ticket!
    
    I can see how it is difficult to to come up with objective guidelines, given the variations in Theme URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org pages. This is probably why they haven’t been defined in more detail yet.
    
    But how about starting with someting like:
    
    Theme page is RECOMMENDED to be on a WordPress/Theme related site.
    
    I’d love to hear from other reviewers what they look for, when reviewing a Theme and it comes to the Crdit Links! Please share, so we can come to a better understanding on this.
  - Vicky Arulsingam 1:48 am on May 14, 2012
    
    The key here is unrelated content.
    
    I’m okay with the Theme URI being an orphaned page but only if there isn’t unrelated content.
Clementine Hobbins 1:00 pm on May 17, 2012

Thx for information.
Satish Gandham 7:51 am on May 20, 2012

Can you please include guidelines for the featured themes, or at least ask the reviewer to say why he thought the theme should be featured.
Arie Putranto 8:31 pm on May 20, 2012

Well, what if comments.php does not exists but replace by a function which generated the comments list? Is it okay?
- Justin Tadlock 11:17 pm on August 4, 2012
  
  There’s technically not a need for the comments.php template. If your theme doesn’t need it but still handles comments correctly using the appropriate WordPress functions, you’ll be fine.
  - Chip Bennett 11:25 pm on August 4, 2012
    
    I disagree. It is a general principle that Themes not rely on legacy template-part file support. And specifically for comments.php, according to source, backward compat for comments.php in comments_template() is intended to be removed, which IMHO is equivalent to it being considered as deprecated:
    
    else // Backward compat code will be removed in a future release 919 require( ABSPATH . WPINC . '/theme-compat/comments.php');
    
    Thus, proper implementation of comments requires use of comments.php, included in the template via comments_template().
    
    If a Theme has a legitimate reason for an exception to this implementation, then that exception can be handled just like any other guideline exception.
@mercime 5:06 pm on May 22, 2012

We know now that there are theme authors who add another subpanel, Appearances > More Themes in themes that have been approved/accepted into the WP Theme Repository https://lists.wordpress.org/pipermail/theme-reviewers/2012-April/008791.html

There should be guidelines surrounding the practice if this (More Themes subpanel) continues and grows, for example:
1. Maximum number of themes which can be listed in that subpanel.
2. Links from that subpanel should only go to webpages of approved Theme URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org
3. No affiliate links.
4. In relation to that, no calling home scripts to find out how many clicked from subpanel links to theme webpage
5. Best practices for adding subpanel.
6. Etc.

Thanks.
- Konstantin Obenland 8:05 pm on May 23, 2012
  
  How many Theme Authors actually do this that we can’t deal with something like this on a case-by-case basis?
Pingback: WordPress 3.4 | WPNinja
Emil Uzelac 5:36 am on June 22, 2012

Just a very quick note that this 3.4 guidelines will need to be discussed bit more before we actually decide on anything and push this over to https://codex.wordpress.org/Theme_Review

For example get_template_directory()/get_template_directory_uri() should be recommended, not required.

The reason is that many users already have Child Themes in place with non get_template_directory()/get_template_directory_uri(), requiring Themes to make a switch will break all of them. If requirements are needed, let’s set this for new submissions only, while only recommending to currently approved ones.

Yes, this is definitely way to go, but not for currently approved Themes.

Thanks,
Emil
- Justin Tadlock 8:34 am on June 24, 2012
  
  Properly using get_template_directory() and get_template_directory_uri() is already required. From the guidelines:
  
  All template tags and hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. used in a Theme are required to be implemented properly.
  - Konstantin Obenland 8:58 am on July 1, 2012
    
    Would that include using the_title_attribute() rather than the_title() in title attributes?
    - Chip Bennett 11:08 am on July 1, 2012
      
      Absolutely!

Welcome to the Themes team!

Handbooks and review requirements

Coding standards and plugins

Code Packages

Communication

Proposed WordPress 3.4 Guidelines Revisions

New WordPress 3.4 Functionality

New Guidelines (REQUIRED)

New Guidelines (RECOMMENDED)

Clarifications

Feedback

Welcome to the Themes team!

Handbooks and review requirements

Coding standards and plugins

Code Packages

Communication

New WordPress 3.4 Functionality

New Guidelines (REQUIRED)

New Guidelines (RECOMMENDED)

Clarifications

Feedback

Share this: