Document title in 4.4

WordPress 4.1 introduced a way for themes to support a new way of rendering the document title, letting CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handle its generation and output. The next step followed just recently (#31078), deprecating wp_title() and replacing it with a more comprehensive way to generate titles.

UPDATE 12 November – wp_title has been reinstated until alternative usages have been identified and a path forward for them defined.

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 authors can now check for theme support and have a few new filters available that will allow them to change or replace the title in a reliable way:

  • 'pre_get_document_title' short-circuits wp_get_document_title() if it returns anything other than an empty value.
  • 'document_title_separator' filters the separator between title parts.
  • 'document_title_parts' filters the parts that make up the document title, passed in an associative array.

This latest change makes the new 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. (almost) feature complete and theme authors are discouraged from using wp_title() in the future. If it was decided to add a UIUI User interface to let users choose the make up of their document title, or another improvement to how title generation works, we now have a forward compatible way to handle these things.

To upgrade themes from using wp_title() to declaring theme support for core’s title-tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) without breaking backwards compatibility with WordPress 4.0 and older, theme authors can check if the callback function exists and add a shiv in case it does not:

if ( ! function_exists( '_wp_render_title_tag' ) ) :
	function theme_slug_render_title() {
?>
<title><?php wp_title( '-', true, 'right' ); ?></title>
<?php
	}
	add_action( 'wp_head', 'theme_slug_render_title' );
endif;

#4-4, #dev-notes, #wp_title

Changes to fields output by comment_form in WordPress 4.4

A change in WordPress that just landed in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. is to move the comment textarea to the top for logged-out users when replying. This is done largely with the goal to improve keyboard/focus navigation, but also aims to make it easier for end users to leave comments on WordPress sites. The change necessitated some filters and actions now being run in a different order. It also means that the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. output by comment_form will now be different.

This is what the comment form looked like before

This is what the comment form looked like before

This is what the comment form looks like after.

If you use any of the 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. inside comment_form, but especially comment_form_field_comment and comment_form_after_fields, you are highly encouraged to test your code against the current WordPress nightly and report any issues on ticketticket Created for both bug reports and feature development on the bug tracker. #29974 so that any necessary adjustments can be made. Visual records and example code will help ensure everyone is satisfied with the final result.

#4-4, #comments, #dev-notes

my-hacks.php no longer supported

A long time ago in a WordPress far, far away sites were customized via the use of a my-hacks.php file. Then 2005 came along and brought with it a new developer feature: Plugins and Themes. For the last ten years, there has been an option to continue using my-hacks.php. Following the WordPress philosophy Decisions, not Options, as of today, WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. no longer supports the use of a my-hacks.php file. The option has long been removed from the adminadmin (and super admin) and now the file will not be loaded.  This is a breaking change for sites that still use a my-hacks.php file.

If you are using my-hacks.php, now is a great time to convert that code into a proper 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. For the last number of years, the file has been loaded just like any other plugin. To change your my-hacks.php file into a plugin you need to do three steps:

  1. Move the file from the root of your install into the plugins folder which defaults to wp-content/plugins
  2. Add the plugin file header comments to the file
  3. Activate your new plugin

This change is associated with ticketticket Created for both bug reports and feature development on the bug tracker. #33741.

#4-4, #breaking-change, #dev-notes, #my-hacks-php

Enforcing the show_ui argument for post types

Since [34177], the show_ui argument for post types is now enforced to correct unexpected behaviour whereby the post type listing screen and post editing screen for post types with show_ui set to false were still accessible via a manually entered URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org.

There’s a small chance this may have an effect on your 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 or website if it’s relying on the fact that these screens were accessible. If this is the case, you should correct the arguments for your post type by setting show_ui to true, and then setting show_in_menu, show_in_nav_menus, and show_in_admin_bar to false, as appropriate.

#4-4, #dev-notes, #post-types