Addition of new ‘wp_body_open’ hook.

Starting from WordPress 5.2 a new function is added – wp_body_open() – that is used to trigger a wp_body_open action. The intention of this action is to allow people to add things – like a <script> tag – directly inside the body of a page.

Themes should start adding this hook to their themes as soon as 5.2 releases. The function should be placed inside of the <body> tag immediately after it is opened like so:

<body <?php body_class(); ?>>
<?php wp_body_open(); ?>

See also the notes at the end of this post and what Justin says in his comment for alternative acceptable ways to add the new hook to your theme.

Use of this hook is a plugin-territory item so themes are unlikely to be doing anything other than adding the tag to the template in the correct spot.

Bear in mind that using this hook should be reserved for output of unseen elements like <script> tags or additional metadata. It should not be used to add arbitrary HTML content to a page that could (and probably would) break layouts or lead to unexpected situations.

Backwards Compatibility

UPDATE: see this comment for an alternative: https://make.wordpress.org/themes/2019/03/29/addition-of-new-wp_body_open-hook/#comment-43714

Additionally for backwards compatibility it is recommended you use a shim to add support on old WP versions and prevent your theme throwing a fatal error for undefined function use. The shim that is suggested looks like this:

<?php
if ( ! function_exists( 'wp_body_open' ) ) {
        function wp_body_open() {
                do_action( 'wp_body_open' );
        }
}

It has also been pointed out that you could call the do_action directly where the wp_body_open() function is placed in my first example (and where it is in the core themes). This removes any need for backwards compatibility code. My personal suggestion is to use the function + shim method because that is how core looks to be handling it – however calling do_action directly would also be fine.

X-post: Call for Testing: wp-theme-auditor

X-comment from +make.wordpress.org/accessibility: Comment on Call for Testing: wp-theme-auditor

X-post: Strengths and Challenges: Organization

X-comment from +make.wordpress.org/updates: Comment on Strengths and Challenges: Organization

Theme Licencing Reminder

The wordpress.org Theme Directory contains only themes which are considered 100% GPL or GPL compatible. This includes the code and all of the bundled assets of a theme.

In Theme Reviews I see 3 different types of licence issue pop up in many themes.

  • Missing licence declarations.
  • Images or assets used under a non-compatible licence for the GPL.
  • Assets or other code not documented or attribution removed.

Missing Licence or Copyrights Declarations

Themes should have a licence declaration in the header of the style.css file as well as a licence and copyrights declaration inside of their readme.

The preferred copyrights statement uses the following format (where Fred is the theme name and Joe Smith as the author):

Fred WordPress Theme, Copyright 2019 Joe Smith. Fred is distributed under the terms of the GNU GPL

In addition to that you should include a licence declaration in the file header comment of each source file of the theme.

Images and Other Assets

Image issues have been touched on recently in the post about Pixabay images and in other posts in the past. Issues with licencing based on the Theme Review Team policy about them have been common recently so to clarify:

All of the images used in a theme for the .org directory should be shared under a GPL compatible licence – one such licence suitable for images is CC0. Other licences may be appropriate too.

Licences which limit the distribution of an image, or it’s use in other ways not covered by the GPL, are not accepted. This is because adding such limitations is not in the spirit of the GPL or in line with the 4 core freedoms of open source software which WordPress follows as part of it’s core philosophy.

Other assets, such as CSS or fonts, should also be shared under a GPL compatible licence. We have a list of some GPL compatible font licences.

Missing Information about Third-Party Assets

Any code used from a 3rd party resource should have a declaration of it’s use (in a ==Resources== section of your readme is ideal).

The licence you use the resource under must be GPL compatible and you must not remove the original authors copyrights notice. You also must clearly state if you modified the source.

Release of the Theme Sniffer plugin

After a long time of refactoring and improving the plugin, the Theme Review team is proud to announce that we’ve released the Theme Sniffer plugin to the wordpress.org plugin repository.

Theme Sniffer is a plugin utilising custom sniffs for PHP_CodeSniffer that statically analyses your theme and ensures that it adheres to WordPress coding conventions, as well as checking your code against PHP version compatibility.

Themes are not required to pass the Theme Sniffer scan without warnings or errors to be included in the theme directory but all reviewers are encouraged to use this plugin to help them review themes quicker.

Theme Sniffer plugin page

The plugin is actively developed on Github, so if you wish to contribute you can start there. Also, if you find any issue with the plugin, feel free to open an issue on the repository.

You can find an entry in the handbook about the usage and some clarification regarding the sniff results interpretation.

#plugin, #theme-sniffer, #trt