New Template Tags in 4.1

Working on a new default theme is always an opportunity to improve coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s Theme APIs too. With the releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. of Twenty Fifteen there are quite a few improvements that made it in:

Archive Template Tags

Theme authors get to use four new functions to use in their archive templates:

  • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
  • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.

They are especially handy when a theme doesn’t have dedicated templates for taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. or date archives, but can essentially be used in all archive templates. The description functions only display term descriptions, since no other archive type really offers descriptions.

Worked on in #21995 and then introduced in r30223.

Navigation Template Tags

Core has provided template tags for links between posts and pages of posts for a long time. Now theme authors can resort to higher-level template tags to display an entire navigation snippet. If you’ve built your themes off of recent default themes, or created child themes from them, these should look very familiar. As a heads up: Since default themes have been developed in HTML5 for five years now, there is no HTML4 version of these tags.

  • get_the_post_navigation() and the_post_navigation() for navigation to the next and previous post.
  • get_the_posts_navigation() and the_posts_navigation() for navigation to the next and previous page of posts.
  • get_the_posts_pagination() and the_posts_pagination() for paginated navigation between pages of posts. (Updated for 4.1 RC1, see this post)

All functions use the same wrapping markup with semantic class names, so it’s easy to style them in one go. The navigation functions accept custom link texts and screen-reader-texts, in case the defaults are not applicable. The pagination functions even accept all arguments that paginate_links() does, too! (Except for the 'type' argument, we need that to be plain so the template 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.) doesn’t break 😉 )

Worked on in #29808, introduced in r30065, improved in r30457.

Also in 4.1:

Theme Support for Title Tags

I’ve written about title tags before and will refer to that post for more information about the groundbreaking changes that happened here.

Page Template Body Classes

They got a minor update that simplifies those class names and allows theme authors to target folders of page templates. With this /page-templates/full-width.php will produce page-templatepage-template-page-templates, page-template-full-width and page-template-page-templatesfull-width-php. Worked on in #23470 and then introduced in r30100.

#4-1, #bundled-theme, #dev-notes, #themes, #twentyfifteen

Agenda for today’s dev chat in #core Slack…

Agenda for today’s dev chat in #core Slack (November 26 2014 21:00 UTC).

  • Splitting terms #30335 – move into feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.
  • Remaining tickets for 4.1 (>80) – bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub
  • RC and string freeze
  • Decision on focus/DFW behaviour and its default state #29806
  • ‘About’ screen text #30435
  • Any other business

#4-1, #agenda

An update on shared term splitting

Background reading: #30335 and the notes on shared term splitting in https://make.wordpress.org/core/2014/11/20/dev-chat-summary-november-19th/.

As part of the work on the taxonomy roadmap in 4.1, shared terms (terms which are shared across more than one taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. due to a slug collision) now get split when the term gets updated. The end result being that editing a term in one taxonomy will no longer affect the term in another taxonomy.

Many plugins store term IDs in post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., options, terms (!), etc, and the side effect of shared term splitting is that these caches can break when the ID of a term they reference changes. Not only that, but the breakage (and the cause) can be invisible to the user and hard to track down if they do notice it.

Following a discussion in #core Slack I’m proposing that shared term splitting is removed from 4.1 and we’ll add it back in for 4.2 and allow a full releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. cycle to get the word out to developers about the change. I’ll makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). the final decision during tomorrow’s dev chat.

Thanks in particular to @mboynes for his time spent on this.

(Note that this only affects existing terms; new terms do not get shared since r30240.)

#4-1, #dev-notes, #roadmap, #taxonomy

Agenda for November 19th dev chat

Agenda for today’s dev chat in #core Slack (November 19 2014 21:00 UTC).

  • Splitting terms #30335
  • i18n of the plugin directory
  • SidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. behaviour in Twenty Fifteen #30404
  • Tweaks to the release schedule:
    • BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 2 tomorrow
    • RC back one week?
    • ReleaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. date unchanged
    • String freeze with RC1
  • New alpha/beta forum issues
  • New Trac issues
  • User feedback on the new DFW mode
  • Beta tester 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 issues #30405
  • Anything else?

Current status: A little over 100 tickets in 4.1 milestone

#4-1, #agenda

JS/Underscore-template-rendered Custom Customizer Controls in WordPress 4.1

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. is a JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.-driven feature of WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but until recently, most of the APIs for extending it in themes and plugins were PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20-oriented. In WordPress 4.1, we’re introducing more complete JS models for the different UIUI User interface objects that comprise the Customizer. In the process, all controls are now placed into the DOM with JavaScript, rather than being output directly in PHP.

At the same time, we’ve been working on issues of scalability and performance. In particular, bringing the navigation menu management experience into the Customizer has highlighted several areas with room for improvement. With menus, each menu item is a Customizer control with several fields, so a site with hundreds of menu items across different menus will end up sending a lot of repetitive HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. down from PHP, and we currently have to send the full markup for a menu item control down from the server when adding menu items in an Ajax call.

#29572 offered a solution to these challenges: an optional 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. that allows Customizer controls to be written as JavaScript templates. Rather than populating a control’s container with markup rendered on the server and obtained via an Ajax call, we can now use JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. templates to render these controls on the client without any server-side call. In the future, new controls could be added dynamically (lazy-loaded, #28580) by leveraging the control-type templates already loaded in the Customizer.

In the remainder of this post, I’ll walk through how to use this API, its benefits, and example use-cases that are already benefiting WordPress core in 4.1.

Registered Control Types

In order to introduce a concept of having one template for multiple Customizer controls of the same type, we needed to introduce a way to register a type of control with the Customize Manager. Previously, custom control objects were only encountered when custom controls were added using WP_Customize_Manager::add_control(). But detecting added control types to render one template per type wouldn’t allow new controls to be created dynamically if no other instances of that type were loaded. So we’ve introduced WP_Customize_Manager::register_control_type(). Usage is simple:

add_action( 'customize_register', '29527_customize_register' );
function 29527_customize_register( $wp_customize ) {
	// Define a custom control class, WP_Customize_Custom_Control.
	// Register the class so that it's JS template is available in the Customizer.
	$wp_customize->register_control_type( 'WP_Customize_Custom_Control' );
}

All registered control types will have their templates printed to the Customizer by WP_Customize_Manager::print_control_templates().

Sending PHP Control Data to JavaScript

While Customizer control data has always been passed to the control JS models, and this has always been able to be extended, you’re much more likely to need to send data down when working with JS templates. Anything that you would want access to in render_content() in PHP will need to be exported to JavaScript to be accessible in your control template. WP_Customize_Control exports the following control class variables by default:

  • type
  • label
  • description
  • active (boolean state)

You can add additional parameters specific to your custom control by overriding WP_Customize_Control::to_json() in your custom control subclass. In most cases, you’ll want to call the parent class’ to_json method also, to ensure that all core variables are exported as well. Here’s an example from the core color control:

public function to_json() {
	parent::to_json();
	$this->json['statuses'] = $this->statuses;
	$this->json['defaultValue'] = $this->setting->default;
}

JS/Underscore Templating, + examples

Once you’ve registered your custom control class as a control type and exported any custom class variables, you can create the template that will render the control UI. You’ll override WP_Customize_Control::content_template() (empty by default) as a replacement for WP_Customize_Control::render_content(). Render content is still called, so be sure to override it with an empty function in your subclass as well.

Underscore-style custom control templates are very similar to PHP. As more and more of WordPress core becomes JavaScript-driven, these templates are becoming increasingly more common. Some sample template code in core can be found in media, revisions, the theme browser, and even in the Twenty Fifteen theme, where a JS template is used to both save the color scheme data and instantly preview color scheme changes in the Customizer. The best way to learn how these templates work is to study similar code in core and, accordingly, I’ll briefly explain an example here now.

class WP_Customize_Color_Control extends WP_Customize_Control {
	public $type = 'color';
// ...
	/**
	 * Render a JS template for the content of the color picker control.
	 */
	public function content_template() {
		?>
		<# var defaultValue = '';
		if ( data.defaultValue ) {
			if ( '#' !== data.defaultValue.substring( 0, 1 ) ) {
				defaultValue = '#' + data.defaultValue;
			} else {
				defaultValue = data.defaultValue;
			}
			defaultValue = ' data-default-color=' + defaultValue; // Quotes added automatically.
		} #>
		<label>
			<# if ( data.label ) { #>
				<span class="customize-control-title">{{{ data.label }}}</span>
			<# } #>
			<# if ( data.description ) { #>
				<span class="description customize-control-description">{{{ data.description }}}</span>
			<# } #>
			<div class="customize-control-content">
				<input class="color-picker-hex" type="text" maxlength="7" placeholder="<?php esc_attr_e( 'Hex Value' ); ?>" {{ defaultValue }} />
			</div>
		</label>
		<?php
	}
}

In the above template for the core custom color control, you can see that after the closing PHP 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.), we have a JS template. <# #> notation is used around statements to be evaluated – in most cases, this is used for conditionals. All of the control instance data that we exported to JS is stored in the `data` object, and we can print a variable using double or triple brace notation {{ }}. As I said before, the best way to get the hang of writing controls like this is to read through existing examples. WP_Customize_Upload_Control was recently updated to leverage this API as well, integrating nicely with the way the media manager is implemented, and squeezing a ton of functionality out of a minimal amount of code. If you want some really good practice, try converting some of the other core controls to use this API – and submit patches to core too, of course!

Working with Controls in JavaScript

The Customizer has always had an API for working with controls in JavaScript. Now that the Customizer supports JS-rendered controls, this API will be even more useful, as you can do things like re-rendering the entire control if its data changes significantly (think media attachment previewing, for example), rather than doing direct DOM manipulation. Again, the core code is the best place to start getting a feel for this API, but it essentially works like subclasses do in PHP. See @westonruter‘s post for details on how this side of the API has evolved in 4.1, and take a look at the control-related models in wp-admin/js/customize-controls.js.

Putting the pieces together

Here’s a summary of what’s needed to leverage the new API in a custom Customizer control subclass:

  1. Makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). your render_content() function empty (but it does need to exist to override the default one).
  2. Create a new function, content_template(), and put the old contents of render_content() there.
  3. Add any custom class variables that are needed for the control to be exported to the JavaScript in the browser (the JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. data) by modifying the to_json() function (see WP_Customize_Color_Control for an example).
  4. Convert the PHP from render_content() into a JS template, using <# #> around JS statements to evaluate and {{ }} around variables to print. PHP class variables are available in the data object; for example, the label can be printed with {{ data.label }}.
  5. Register the custom control class/type. This critical step tells the Customizer to print the template for this control. This is distinct from just printing templates for all controls that were added because the ideas are that many instances of this control type could be rendered from one template, and that any registered control types would be available for dynamic control-creation in the future. Just do something like $wp_customize->register_control_type( 'WP_Customize_Color_Control' );.

The PHP-only parts of the API are still fully supported and perfectly fine to use. But, with WordPress 4.0’s decreased need for custom controls, and given our long term goals for making the Customizer more flexible for doing things like switching themes in the Customizer without a pageload, I strongly encourage using this new API for all custom Customizer controls where feasible.

#4-1, #customize, #dev-notes, #menu-customizer, #menus

WordPress Core Weekly

Hi Everyone!

It’s that time again: WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Weekly is here. This is a catchup post and covers all commits since the last post up until 11/9/2014.

First, a couple quick notes!

Taxonomies

  • Do not create shared taxonomy terms. [30240] #21950; See #5809.
  • Split shared taxonomy terms during term update. [30238] [30239] [30241] #5809
  • Don’t force child_of=0 for non-hierarchical taxonomies in get_terms(). [30265] #30275
  • In get_adjacent_post(), $excluded_terms should check term_id rather than term_taxonom_id. [30263] #29663, #22112.
  • Allow resource_type to be specified in get_ancestors(). Being explicit about resource type (taxonomy vs post_type) allows for the proper resolution of conflicts when a taxonomy and post_type share a slug. [30141] #15029
  • In wp_insert_term(), clean up accidental duplicate terms after insert. [30238] See #22023, #5809.
  • Add some unit tests for is_object_in_term(). These tests check a number of the ways that different kinds of values for $terms (integers that match term_id, strings that match term_id or name or slug) are handled. [30204] #29467
  • In in_object_in_term(), only check numeric string values against term_id. [30205] #29467
  • Introduce term_template param to get_the_taxonomies() to allow theme 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 authors to specify the formatting on term links as they are parsed into the taxonomy list. [30209] See #27238.
  • Allow duplicate slugs across different post types. [30158] #18962
  • In get_terms(), do not override hierarchical and pad_count when parent is present. The previous behavior resulted in descendant terms being improperly excluded from the results when passing a parent, even when hierarchical had been set to true. [30107] #29815
  • Clean up get_term_by() caching, fix cache key/group modification that was missed in [30073], and update unit tests. [30108] #21760

Twenty Fifteen

  • Use new core navigation tags. [30216] #30189
  • Support for title-tag. [30097] #30146
  • Improve support for 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.. [30274] [30275] #29988; [30230] #30164 #29980; [30272] #30165
  • Improve accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) by clarifying link context #30108 [30208], adding accessible alt text for post thumbnail links. [30231] #30076, and using continue reading links for auto-generated excerpts [30237] #30135.
  • Prevent a flash of visible sub menus before scripts load. [30211] #30056.
  • Detach widgets from 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. in mobile views. [30243] #30252
  • Improve Styles for playlists [30213] [30269] #30163, user-selected custom colors [30221] #30234, and image alignment for RTL [30222] #30239, and body class for page templates [30100] #23470.
  • Makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). sure that the edit link will always be right of its icon. [30215] #30171
  • Add a fallback icon for social links where we don’t have an icon. [30212] #30148
  • Use the new archive template tags and make archive template titling simpler. [30236] #30246

Database

  • Bump db_version and add upgrade routine for schema change in [30056]. [30121] [30134] #22023
  • WPDB’s __get() function should perform strict comparisons against member names. [30292]

RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.

  • Allow revision Backbone classes to be used on pages other than revision.php. [30128] #30221
  • Add a single responsibility function for outputting Revisions JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. templates: wp_print_revision_templates(). Use it in wp-admin/revision.php. [30129] #30220
  • Revisions modules should not rely on global settings; only pass in global settings on init, this allows the classes to be used agnostically elsewhere. [30131] #30219

Metadata

  • Pass all updated metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. IDs to filters in update_metadata(). [30140] #11683
  • Unserialize get_metadata() results when key is omitted. [30115] #15030

Queries

Adminadmin (and super admin)

  • Display error message when Media Library upload fails. [30156] [30177] #29891
  • Delete admin_created_user_subject() rather than deprecate. As it was never used as anything more than a callback to a 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. before the MU merge, and is only available in user-new.php in multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, it is safe to remove this function entirely. [30176] #29915

Customizer

  • Improve/introduce Customizer JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. models for Controls, Sections, and Panels, along with a reference. [30102] see #28032, #28579, #28580, #28650, #28709, #29758. Fixes #29529.
  • Improve ColorControl‘s wpColorPicker to update UIUI User interface based on setting changes. Update Twenty Fifteen’s colorScheme control to properly interact with the 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., using wp.customize.control(). [30126] #30031
  • Add stable sorting for panels, sections and controls in JS. Improve sorting in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20. [30214] #30225
  • Bind input and propertychange events for range input types. [30219] #30223
  • Twenty Fourteen: Make featured content in Customizer contextual to the front page. [30143] #29578

Templates

  • Introduce new template functions for archive titles and descriptions: [30223] #21995
    • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
    • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.
  • In get_page_children(), only check $page->ancestors once to avoid duplicates when the function recurses. Adds an argument, $ancestors. [30246] #18962
  • Allow get_pages(), with child_of passed to it, to work with interrupted hierarchies. [30159] #18962

Thanks to @afercia, @avryl, @azaozz, @bobbingwide, @boonebgorges, @bradyvercher, @Caspie, @celloexpressions, @dancameron, @davidakennedy, @davidjlaietta, @dikiy_forester, @dlh, @donutz, @DrewAPicture, @ericlewis, @filosofo, @florianziegler, @garyc40, @gcorne, @greuben, @hereswhatidid, @iamtakashi, @iandstewart, @imath, @Jayjdk, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @kitchin, @kovshenin, @kraftbj, @kurtpayne, @lancewillett, @landakram, @loushou, @markjaquith, @mattkeys, @mattwiebe, @mboynes, @MikeHansenMe, @mlteal, @mordauk, @morganestes, @nacin, @NikV, @nobinobi, @obenland, @ocean90, @pento, @philiparthurmoore, @realloc, @rmccue, @ryankienstra, @sakinshrestha, @SergeyBiryukov, @slobodanmanic, @TobiasBg, @tollmanz, @tywayne, @voldemortensen, @wedi, @westonruter, and @wonderboymusic for their core contributions!

Revisions covered: [30094] to [30292]. For the complete list of commits to 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., check out the log on Trac.

Interested in joining in? Write or test a patch for 4.1.

#4-1, #week-in-core

An update on the taxonomy roadmap

In 2013, @nacin laid out a potential roadmap for the WordPress taxonomy component. Progress on this roadmap has necessarily been deliberate and, as a result, somewhat slow. But some important steps have been taken in the last few months.

Improvements in 4.1

Recall the problem. Since 2.3 – when WP’s taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. schema was first introduced – terms have been “shared” between taxonomies when they happen to share the same slug. This architecture was designed to enable serendipitous connections between bloggers writing about similar subjects, especially when combined with “global” terms, which are shared across a multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site networknetwork (versus site, blog). However, as WP has developed as a CMS and taxonomies have been put to much broader use than originally envisioned, this feature has ended up causing more problem than it solved. Shared slugs in particular have caused a good deal of frustration for users and developers. A notable example is the infamous #5809: changing a term in one taxonomy (say, ‘Chicago’ in the taxonomy ‘cool_cities’) would update all terms that happened to share the same slug (say, ‘Chicago’ in the taxonomy ‘cool_bands’).

Fixing this behavior has required a series of carefully staged maneuvers. Here’s what’s happened during the 4.1 cycle:

  • Unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. coverage has been improved for wp_insert_term(), wp_update_term(), and term_exists() ([29798], [29830], [29875]).
  • We fixed a few edge-case bugs in term_exists() #29589 #29851. These fixes, plus the increased test coverage, have made us confident in our ability to prevent the creation of unwanted duplicate terms in most cases, a prerequisite for the next item.
  • We removed the UNIQUE index from the ‘slug’ column in wp_terms #22023, and added some failsafe logic to avoid duplicate term creation in certain edge cases [30238]. This step is small but critical. “Splitting” existing shared terms means creating a new row in the wp_terms table for each item in wp_term_taxonomy that currently shares its ‘term_id’ with another item. But when we split these terms, we cannot change their slugs, or we’ll break backward compatibility with things like taxonomy archive permalinks. That is: example.com/cool_bands/chicago and example.com/cool_cities/chicago must continue to work. So the ‘slug’ column of the terms table must not enforce uniqueness.
  • We stopped creating new shared terms #21950. This means that each new item inserted into wp_term_taxonomy will correspond to a new row in wp_terms, even if the new item shares its slug with an existing term.
  • Updating a shared term will cause it to be split into two separate terms #5809. This addresses the primary pain point of shared terms: you can now change ‘Chicago’ to ‘The Windy City’ without your readers thinking that you’re confused about the artists behind this hard-rockin’ hit. (Edit – term splitting was removed for WP 4.1, and is slated for 4.2.)

In short, while 4.1 won’t completely remove shared terms from WP – see below – it should alleviate the pains they inflict.

Looking ahead

The continued existence of shared terms in the database means that we still have to deal with the translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. between ‘term_id’+’taxonomy’ and ‘term_taxonomy_id’, a requirement that limits the cool things we can do with terms. As such, cleaning up existing shared terms is a top priority. #30261 lays out some suggestions for how to expunge them from the database. This step isn’t practical for 4.1: we can only split existing terms when the 4.1 database schema change has been applied #22023, and schema changes are not immediate in multisite enviroments. But we can consider it for 4.2.

Once term_ids and term_taxonomy_ids are in one-to-one correspondence, we can start on some of the more exciting items that Nacin outlined. Termmeta #10142 becomes a viable possibility once we can rely on unique term_ids. And collapsing the wp_terms and wp_term_taxonomy tables #30262 will allow us to simplify and streamline the internals of our taxonomy functions. These are tasks that we can start exploring for 4.3 and beyond, at least one version after we’ve split existing terms on all installations. These tickets are a good starting place for people who are interested in following (and contributing to) the future of taxonomies in WordPress.

#4-1, #dev-notes, #roadmaps, #taxonomy

Focus v2 demo video

Here is the current state of the Focus v2 project, a re-think of Distraction Free Writing:

I would like to propose that we immediately merge this into core for 4.1.

Some of the bullet points:

  • Current Distraction Free Writing (DFW) interface is too much of a transition.
  • Current DFW doesn’t give you quick access to everything (you feel trapped in it).
  • Current DFW isn’t very discoverable.
  • New DFW (Focus v2) triggers on keyup (discoverable).
  • New DFW transition is seamless. Things you don’t need while typing just go away. Your scroll position is maintained. It’s the same editor, whereas before it was a separate one.
  • New DFW gives you instant access to all your metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes and everything else, with a wag of the mouse, a TAB press, or a tap.
  • Best of both worlds!

Not mentioned in the video is that the old DFW button now is a disabling toggle for this mode. So it’s Auto/Off, instead of On/Off.

#4-1, #dev-notes

Agenda for today’s dev chat in the #core…

Agenda for today’s dev chat in the #core channel on slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. (November 5 2014 21:00 UTC):

  • BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process./Merge Window@johnbillion would like to extend the merge window and tagging the beta to Friday
  • Hook Recursion#17817: @jbrinley is requesting some eyes on it (likely 4.2-early). Three main issues:
    1. Is there enough unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. coverage?
    2. Does it break plugins which interact with $wp_filter and $wp_actions directly (eg accessing the nested arrays)?
    3. Does it “fix” any existing behavior which could be seen as a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5.?
  • Focus#29806: Patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. for editor focus v2 looks good. @markjaquith will be posting a merge request update on makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility)./coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. @johnbillion will decide whether to merge on Thurs/Fri
  • Sessions UIUI User interfaceNeeds a ticketticket Created for both bug reports and feature development on the bug tracker., #30264 decision for merge will be Thurs/Fri
  • Shiny Updates#29820: Decision at WCSF was to go with shiny installs, leave shiny updates for a later releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software.. Awaiting feedback from @pento/@nacin/@melchoyce about whether this still has a chance of getting done in time for merge
  • FS Credentials Modal#29820: Also affects #29395 (installing languages from general settings screen)
  • TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. Roadmap@boone is on fire
  • Twenty Fifteen – Some discussion around smaller issues with the new template functions and color schemes, nothing that can’t be iterated upon during beta
  • Bug Scrubs – Continuing weekly bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs on Friday this week, likely a mixture of a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) and 4.1 tickets

#4-1, #agenda

Title Tags in 4.1

For over three years we have been trying to makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). it easier for plugins and themes to manage the document title. Kubrick didn’t necessarily set a great example to theme authors by appending the blogblog (versus network, site) name to wp_title(), a practice we have been trying to correct ever since.

#18548 was created to find a solution to that problem, but after initial excitement hasn’t seen any noteworthy action until a few weeks ago. Yesterday @johnbillion committed a first step towards a brighter future in [30074], introducing a forward compatible way to make document titles fully customizable.

Adding titles to themes

Starting with 4.1 and Twenty Fifteen, the recommended way for themes to display titles is by adding theme support like this:

function theme_slug_setup() {
   add_theme_support( 'title-tag' );
}
add_action( 'after_setup_theme', 'theme_slug_setup' );

Support should be added on the after_setup_theme or init action, but no later than that. It does not accept any further arguments.

By declaring support like this, themes acknowledge that they are not defining titles on their own and WordPress can add it safely without duplication.

To maintain full forward compatibility, plugins can not check for theme support of title tags, and are discouraged from building functionality around it just yet. The long term plan is to enable users to manage document titles from their adminadmin (and super admin), independent of which theme they’re using. At that time it will also become more 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 friendly. To make sure this can be achieved however, it was important to rule out backwards compatibility concerns as much as possible.

While there is no consensus on how the final implementation will look like yet, this should be a good way to get themes started to opt into a more user friendly way. It will also make any future changes that much more impactful when the final version ships.

Backwards compatibility

To enable support in existing themes without breaking backwards compatibility, 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;

This would also be the place to optionally add a 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. to enhance the document title, along the lines of what recent default themes have been doing.

#4-1, #bundled-theme, #dev-notes, #themes, #twentyfifteen