Multisite Focused Changes in 4.6

The 4.6 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 has been a productive one! Several major and a few minor updates are described in detail below. If you’d like even more detail, here is a full list of 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 focused changes for 4.6.

Introduce WP_Site_Query and WP_Network_Query

WordPress 4.6 introduces WP_Site_Query and WP_Network_Query as well as their companion functions, get_sites() and get_networks().

WP_Site_Query

With WP_Site_Query (or get_sites()), sites can now be queried from the $wpdb->blogs table in a flexible way by id, domain, path, and more. For a full list of supported arguments, see the documentation attached to the __construct() method.

New filters and actions associated with this change include parse_site_query, pre_get_sites, the_sites, site_search_columns, sites_clauses, and found_sites_query.

Query results are cached as part of the global sites group. This will provide a performance boost for sites using a persistent object cache.

The introduction of this class helped resolve several long standing issues with WP_MS_Sites_List_Table. Expect to see a faster and more relevant search when browsing through a networknetwork (versus site, blog)’s sites. See #36675.

For the background discussion around these changes, see #35791.

WP_Network_Query

With WP_Network_Query (or get_networks()), networks can now be queried from the $wpdb->site table by id, domain, and path. Query results are cached as part of the global networks group. For a full list of supported arguments, see the documentation attached to the __construct() method.

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. does not provide a UIUI User interface for managing multiple networks, but any sites using 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 to do this will start to see a benefit from having this available.

New filters and actions associated with this change include parse_network_query, pre_get_networks, the_networks, networks_clauses, and found_networks_query.

For the background discussion around these changes, see #32504.

Enhancements to WP_Site and WP_Network

New utility methods

New functions get_site() and get_network() have been introduced to retrieve a specific site or network respectively. They both accept either an ID, database object or class instance as the first parameter. If that parameter is omitted, the current site / network is returned.

Property changes on WP_Site and WP_Network

The WP_Site and WP_Network objects now support access to their respective ID properties through property names which match current naming conventions. Furthermore, by accessing the properties with the new names, it is ensured that these are returned as integers rather than strings. The old properties are still accessible and valid, but these changes should encourage developers to use the new property names.

The following is the list of property improvements:

  • $site->id is the site’s ID. (previously $site->blog_id)
  • $site->network_id is the site’s parent network ID. (previously $site->site_id)
  • $network->id is now an integer instead of a string.
  • $network->site_id is the network’s main site ID. (previously $network->blog_id)

For background discussion around these changes, see #36717 and #37050.

Lazy-loading extended properties

Additional properties of a site object normally accessed with get_blog_details() are now automatically lazy-loaded when requested. This allows developers to use get_site() as a replacement for get_blog_details() which is likely to be deprecated in a future release. See #36935.

New Actions and Filters

Several new actions and filters were added as part of the WP_Site_Query and WP_Network_Query changes. Here are some others of note:

  • ms_loaded fires at the end of the multisite bootstrap process in ms-settings.php. At this point the current site and network are available in the global scope. See #37235.
  • pre_get_blogs_of_user allows developers to alter or short-circuit the results of get_blogs_of_user(), which can be an expensive function to run on configurations with many users. See #36707.
  • clean_site_cache fires after cache has been cleared with clear_blog_cache(). This can be useful for clearing any custom cache keys associated with a site record. See #36203.
  • network_edit_site_nav_links filters the list of links displayed at the top of Edit Site views as a “tabbed” interface. See #15800.
  • ms_sites_list_table_query_args filters the arguments passed to WP_Site_Query when building the MS Sites List Table. See #26580.

Other enhancements of note

Introduce get_current_network_id() as a helper function to find the current network’s ID. See #33900.

The MULTISITE and SUBDOMAIN_INSTALL constants can now be overridden in a project’s wp-config.php when running unit tests. See #36567.

Deprecated Functions

wp_get_sites() has been deprecated and get_sites() should be used instead. Please note when making code changes that get_sites() returns an array of WP_Site objects where wp_get_sites() returned an array of arrays.

WP Multi Network compatibility

The introduction of get_networks() in 4.6 conflicts with the function of the same name in WP Multi Network, a plugin commonly used to provide multiple networks on a multisite installation. A fix for this is already in the master branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of the plugin, and will be included in the next release. In the same change, many other functions were wrapped in function_exists() calls to prevent similar conflicts in the future. If you are using WP Multi Network, please be sure to update accordingly.

#4-6, #dev-notes, #multisite, #network-sites

Enhancing register_meta() in 4.6

Note: Note: The direction of register_meta() has changed since this was published. Please see the most recent developer note explaining these changes.

In 4.6, register_meta() expands to support the registration of meta keys and what to expect from those keys. See #35658 for the discussion around this change.

The behavior of register_meta() is similar to register_post_type() in that the registration of this data is stored in the global scope. This makes an object’s meta data more accessible to parts of core and extending code.

Why make this change

In 4.5 and earlier, WordPress provided no method to explicitly register a meta key’s public state. Instead, register_meta() provided “protected” and “authenticated” meta. This can be used effectively for some things, particularly to determine what meta appears in the Custom Fields metabox when editing a post. It can not be used as a basis for arbitrarily showing meta keys and values to unauthenticated visitors.

What does this change involve

A global variable, $wp_meta_keys, contains all registered meta keys.

The function signature of register_meta() has changed to support 3 arguments, the last being an array. That array should contain data about the meta with these key/values:

  • sanitize_callback, a callable method to provide sanitization. This is the new version of the current 3rd parameter in register_meta().
  • auth_callback, a callable method to provide authorization. This is the new version of the current 4th parameter in register_meta().
  • object_subtype, a string containing an object subtype slug. If there is no object subtype, meta will not be registered and a WP_Error will be returned instead.
  • type, a string indicating what type of data the meta value will be. This is intentionally not restricted to a specific list of data types, however full names should be used when possible. (e.g. boolean, integer)
  • description, a string containing a basic description of the meta value.
  • single, whether code retrieving meta for this key should expect a single or multiple values when using something like get_post_meta().
  • show_in_rest, whether this should be shown as part of a post’s meta endpoint in the WordPress REST API. Note that this should be treated as experimental until the WordPress REST API provides support for meta.

The register_meta_args filter is available to add support for additional arguments. This need to explicitly whitelist further arguments is to reserve the right for core to add further arguments in the future; should you choose to use this filter, you should be prepared to follow along with further development. Your testing with trunk or betas is greatly appreciated!

By default, only WordPress core object types (post, user, term, comment) can be registered. To add support for custom object types, use the wp_object_types filter. This whitelisting is similar to the above.

Object sub types provide specific registration of meta keys to a type of data.

  • A standard WordPress post has an object type of “post” and an object subtype of “post”.
  • A custom post type registered with a slug of “my_cpt” has an object type of “post” and an object subtype of “my_cpt”.
  • A WordPress user has an object type of “user” and an object subtype of “user”.
  • A standard WordPress comment has an object type of “comment” and an object subtype of “comment”.
  • A standard WordPress category term has an object type of “term” and an object subtype of “category”.
  • A custom taxonomy registered with a slug of “my_tax” has an object type of “term” and an object subtype of “my_tax”.

Meta keys must be explicitly registered for each object type and subtype combination.

Additional helper functions get_registered_metadata(), get_registered_meta_keys(), unregister_meta(), and registered_meta_key_exists() have been added to make the innards of the global data more accessible.

The $wp_meta_keys variable should not be altered directly. It is possible that its structure will change in the future.

Any code currently using register_meta() and expecting pre-4.6 behavior will continue to work as is. Please report any breaks in compatibility that might be found.

Example

Here’s what registering meta looked like in 4.5. This meta key has sanitization and authorization callbacks.

register_meta( 'post', 'my_meta_key', 'sanitize_my_meta_key', 'authorize_my_meta_key' );

The above code will continue to work in 4.6, though will not be considered completely registered. The callbacks will be registered, but the key will not be added to the global registry. A WP_Error object will be returned with this explanation.

Here’s what registering meta looks like in 4.6. This meta key will have sanitization and authorization callbacks, and be registered as public for the WordPress REST API.

$args = array(
    'object_subtype' => 'post',
    'sanitize_callback' => 'sanitize_my_meta_key',
    'auth_callback' => 'authorize_my_meta_key',
    'type' => 'string',
    'description' => 'My registered meta key',
    'single' => true,
    'show_in_rest' => true,
);
register_meta( 'post', 'my_meta_key', $args );

If you are currently using register_meta() and would like to maintain support for older versions of WordPress, the best method will be to check for the registration of the sanitization and authorization callbacks after calling register_meta() and then registering them manually if not present. This manual registration is all that register_meta() was previously doing. Continuing from the example above:

// Pre-WordPress 4.6 compatibility
if ( ! has_filter( 'sanitize_post_meta_my_meta_key' ) ) {
    add_filter( 'sanitize_post_meta_my_meta_key', 'sanitize_my_meta_key', 10, 4 );
}

if ( ! has_filter( 'auth_post_meta_my_meta_key' ) ) {
    add_filter( 'auth_post_meta_my_meta_key', 'authorize_my_meta_key', 10, 6 );
}

What’s next

While the initial work on this is largely driven by the need to move the WordPress REST API forward, its scope is not limited to solving the problem of public access to metadata. By having information about the meta keys used in a code base, it becomes much easier for other pieces of code to make decisions about what can be done with this data.

This data can one day be useful to everything from the Customizer, the editing experience for all object types, the Fields API, and many plugins that rely on metadata. Work will continue on transforming this $wp_meta_keys object and the methods surrounding it to be flexible and explicit. As WordPress core becomes familiar with register_meta() and more confident in the approach, the set of default arguments can and likely will expand to include more data about registered meta keys as required.

Feedback

Please leave any feedback you have on this new iteration of register_meta() in the comments below. Test it out in your plugins and themes to be sure it is working in a backwards compatible way. Try out the new function signature and register meta for objects and their subtypes. This continues to be a work in progress and feedback is important.

#4-6, #dev-notes, #fields-api, #options-meta, #rest-api

Native Fonts in 4.6

When WordPress switched to Open Sans in version 3.8 at the end of 2013, the state of typography on the web was just beginning to evolve. Before, our choices for typefaces were limited to a small subset of fonts reliably installed on most major operating systems. And, in some cases, those fonts were optimized for print, not the web. Open Sans is optimized for the screen, has generous character support, and, best of all, is open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL.. For these reasons, it was a better option for a modern web app than the system fonts of that time.

Today, the landscape has changed. The majority of our users are now on devices that use great system fonts for their user interface. System fonts load more quickly, have better language support, and 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). web apps look more like native apps. By using the same font that the user’s device does, WordPress looks more familiar as a result. This change prioritizes consistency from the user’s perspective over consistency in branding. And while typography does play a role in the WordPress brand, the use of color, iconography, and information architecture still feels very much like WordPress.

To this end, Font Natively (#36753) replaces Open Sans with a set of system fonts that covers major operating systems, including Android, iOSiOS The operating system used on iPhones and iPads., Windows, macOS, and Linux.

The Font Stack

Safari, Chrome, and Firefox on iOS and macOS have new CSSCSS Cascading Style Sheets. values that return the current system UIUI User interface font, but on other platforms, the font has to be declared by name. As such, the font stack includes the following:

  • -apple-system for Safari (iOS & macOS) and Firefox macOS
  • BlinkMacSystemFont for Chrome macOS
  • Segoe UI for Windows
  • Roboto for Android and Chrome OS
  • Oxygen-Sans for KDE
  • Ubuntu for Ubuntu
  • Cantarell for GNOME
  • Helvetica Neue for versions of macOS prior to 10.11
  • sans-serif, the standard fallback

The complete CSS declaration: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;

Details

The operating system’s UI font is used for any text that’s part of the WordPress user interface. In other contexts, like the Editor, we continue to use a serif system typeface, Georgia. This creates a clear typographic distinction between text that is part of the interface, and text that is part of the user’s content.

Not all system fonts provide the same range of weights that Open Sans did. We recommend using only the 400 and 600 weights, which will display most consistently across all platforms. I’ve created a test page that shows the difference between Open Sans and your current device’s system font at every available weight. (A collection of screenshots of that test page is also available).

The order in which they’re called is important, because we want the user’s system font to be the first available font in the stack. For example: if Roboto were listed ahead of Segoe UI, Windows developers who have installed the Roboto font for Android development would see it instead of their native system font. There may be edge cases if users have manually installed these fonts on their machines, but this order should work best for the majority of users.

When using this font stack, it must be called using the font-family property, and not the font shorthand. This works around an issue in Microsoft Edge.

Screenshots

All screenshots were taken on a retina (2dppx) device. If you’re reviewing screenshots on a non-retina display, check out this Cloudup gallery of 1x screenshots.

#4-6, #design, #dev-notes, #fonts

Shiny Updates in 4.6

After being approved for a partial merge, Shiny Updates V2 was added to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in [37714]. Thanks to that change, updating as well as installing and deleting plugins and themes has become much easier for users. With the exception of the wp-admin/update-core.php screen, those actions are now all performed via AJAX, avoiding what we internally called The Bleak Screen of Sadness.

Visual Changes

If you wanna see Shiny Updates in action, check out the merge proposal post which contains screenshots and a video.

Proposal: More Shiny Updates

One big user facing change is about search: There is now an AJAX search on both the Installed Plugins screen as well as the Add New 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 screen, this means the search results change as you type, drastically simplifying your workflow.

Under The Hood

The 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/. responsible for shiny updates (enqueued via the 'updates' handle) has been completely revamped to improve the UXUX User experience across the board by displaying better progress updates and error messages.

If you’re in any way relying on this JavaScript, you will notice that wp.updates.update() has been renamed to wp.updates.updatePlugin(). The same goes for the plugin update success / error callbacks.

In addition to that, callbacks are now passed as arguments to the wp.updates.updatePlugin(), wp.updates.updateTheme() and the like, e.g. wp.updates.updatePlugin( { success: wp.updates.updatePluginSuccess, … } ). The whole code is thoroughly documented.

However, you probably won’t ever need to call these functions directly. Instead, you might wanna hook into the custom jQuery events that are being triggered throughout the code, like 'wp-plugin-install-success'.

Shiny Updates V3

While the last iteration of Shiny Updates has been merged into core, development of the plugin continues to happen on GitHub. If you’re running the Shiny Updates feature plugin on your site, everything will continue to work when using 4.6.

The current version of the plugin now only contains things that didn’t 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 into 4.6 and is our base for further development. Feel free to keep it running and provide feedback!

#4-6, #dev-notes, #shiny-updates

Resource Hints in 4.6

Resource Hints is a rather new W3C specification that “defines the dns-prefetch, preconnect, prefetch, and prerender relationships of the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Link Element (<link>)”. These can be used to assist the browser in the decision process of which origins it should connect to, and which resources it should fetch and preprocess to improve page performance.

Introduced with [37920], WordPress now has a simple 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. to register and use resource hints. The relevant ticketticket Created for both bug reports and feature development on the bug tracker. is #34292

By default, wp_resource_hints() prints hints for s.w.org (the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ CDN) and for all scripts and styles which are enqueued from external hosts.

Developers can use the wp_resource_hints 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 add custom domains and URLs for dns-prefetch, preconnectprefetch or prerender. One needs to be careful to not add too many resource hints as they could quite easily negatively impact performance, especially on mobile, but the filter works like this:

function makewp_example_resource_hints( $hints, $relation_type ) {
	if ( 'dns-prefetch' === $relation_type ) {
		$hints[] = '//make.wordpress.org';
	} else if ( 'prerender' === $relation_type ) {
		$hints[] = 'https://make.wordpress.org/great-again';
	}

	return $hints;
}

add_filter( 'wp_resource_hints', 'makewp_example_resource_hints', 10, 2 );

#4-6, #dev-notes, #script-loader

Bootstrap/Load updates in 4.6

Alert: A change was made to remove protection for overloading Plugin API related global variables in advanced-cache.php

Every time WordPress is loaded, it goes through the bootstrap or loading process. In WordPress 4.6, there will be a few changes to the process focused on making pieces available earlier. Many of these changes will have no effect whatsoever on the vast majority of WordPress sites. However, if you are the type that maintains your own advanced-cache.php drop-in, host/run large profile sites, or work on tools that bootstrap WordPress is odd ways than this article is for you!

Load plugin.php earlier in wp-settings.php

plugin.php contains the functions such as add_filter() and add_action() that form the foundation of the WordPress plugin system. The file (and thus those functions) are now being loaded earlier in wp-settings.php. This allows for some hooks to be placed earlier, but also for advance-cache.php drop-ins to use the plugins API rather than directly manipulating global variables. For more information, see #36819.

Reconcile wp-settings-cli.php with wp-settings.php

Any time WordPress made a change to wp-settings.php, it inevitably broke WP-CLI. In order to allow WP-CLI to no longer need to maintain a custom fork, a handful of new hooks were added to the bootstrap process. These hooks happen before plugins load. They are designed more for non-web uses such as WP-CLI. For more information about these hooks, see #34936.

is_ssl() is now located in wp-includes/load.php

Many advanced-cache.php drop-ins duplicate is_ssl(). They will no longer need to do that as it will be available earlier in the bootstrap process. See #35844 for more info on this change.

ABSPATH can now be safely defined before WordPress is loaded

Defining ABSPATH in an auto_prepend_file will no longer cause notices to be generated. This can lead to less complexity for some WordPress specific hosts. See #26592 for more info on this change.

In conclusion

The bootstrap process provides the foundation for WordPress. It’s not pure, but dang zimit, it works. These changes are all expected to be backward compatible. Please test and report any regressions on Trac.

Thanks to the following people who contributed to the Bootstrap component this release. @jorbin @danielbachhuber @DrewAPicture @ocean90 @barry @SergeyBiryukov @johnjamesjacoby

#4-6, #bootstrap-load, #dev-notes

WP_Term_Query in WordPress 4.6

WordPress 4.6 will introduce WP_Term_Query. This new class brings parity between 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. term queries and WP’s other content type queries: WP_Query, WP_Comment_Query, and WP_User_Query. And – as in the case of posts, comments, and users – the get_terms() function has been converted to a wrapper for the new WP_Term_Query.

Aside from support for querying by term_taxonomy_id #37074, no functional changes to get_terms() will be introduced in 4.6; 100% backward compatibility with previous uses is the goal for this 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..

For more background on the change, see #35381.

#4-6, #dev-notes, #taxonomy

I18N Improvements in 4.6

WordPress 4.6 significantly improves the way translations are loaded for plugins and themes which are hosted in the WordPress 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 and Theme Directory and using language packs via WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/’s translation platform.

Loading Translations in Different Order

Functions like load_plugin_textdomain( $domain ) and load_theme_textdomain( $domain ) are used to load the translations for a specific text domain, where $domain equals the slug of your plugin or theme.

Up until now, these functions first looked inside the plugin/theme folder for available translations before checking the wp-content/languages directory, where language packs reside. With WordPress 4.6, this order has been reversed.
The translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. platform for plugins/themes was opened up in December last year. Since then 15,000 plugins and themes were imported and are now benefiting from automated translation updates. That’s why translation files are most likely to be located wp-content/languages directory, hence this change. See [37414] / #34213.

Just-in-time Loading for Translations

By far the biggest change is that you do not have to call load_plugin_textdomain() or load_theme_textdomain() anymore with WordPress 4.6. Of course the same goes for load_muplugin_textdomain().

Again, since translations files are usually inside wp-content/languages, WordPress now scans that directory for available translations and automatically loads them if it encounters a text domain for the first time. That’s handled by the new _load_textdomain_just_in_time() function which gets called in get_translations_for_domain(). See [37415] / #34114.

This so-called just-in-time loading of text domains works really great and removes one more step for developers to worry about. If you do not want this to happen, however, you can still use the override_load_textdomain 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 load your text domains manually.

Also, if you use unload_textdomain() you will have to manually load translations afterwards if you want to use them again because it keeps a record of unloaded text domains.

Localized jQuery UIUI User interface datepicker

https://make.wordpress.org/core/2016/07/06/jquery-ui-datepicker-localization-in-4-6/

Other Changes

  • Support for comment number declension in get_comments_number_text(). See #13651.
  • Fallback for TextDomain 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. field in get_plugin_data(). See #36706.
  • Updated list of continents and cities for the timezone selector. See #37554.
  • Support for the German (Switzerland) localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. in remove_accents(). See #37076.
  • Improved support for month name declension. See #36790.

 

#4-6, #dev-notes, #i18n

jQuery UI datepicker localization in 4.6

In WordPress 4.6 (#29420) localization defaults were added for the jQuery UI datepicker based on the current localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. using the new wp_add_inline_script() function. With 4.6 you can enqueue the datepicker and you are set. It works out of the box.

Instead of using the language files from the jQuery UI project the necessary information, mainly from the WP_Locale class, is directly passed to the datepicker. The list of localized information: closeText, currentText, monthNames, monthNamesShort, nextText, prevText, dayNames, dayNamesShort, dayNamesMin, dateFormat, firstDay, and isRTL.

If you are using the files from jQuery UIUI User interface in your theme or 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, please be aware of this change. With 4.6 you can omit calling these files and enqueue the default datepicker which will use the built-in defaults from WordPress.

If you want to change the defaults or add custom settings, you can still use all the arguments from the datepicker. WordPress only sets sane defaults for the chosen locale. But you should check if jQuery UI datepicker is enqueued and you should check if the browser is showing a native datepicker (like Chrome).

@ipstenu has scanned the plugin repo for plugins including the jQuery UI files. The following plugins can be changed to use WordPress’ own translations.

Advanced Booking Calendar, Albo Pretorio On line, Altos Toolbar, AWPCP – Classifieds Plugin, Appointment Calendar, Banner Garden Plugin for WordPress, BBS e-Popup, Beaverlodge Maintenance, Beaverlodge Menu Styler, BigContact Contact Page, Blog Post Calendar Widget, Booking Calendar Contact Form, Events Calendar, Class Booking, Contact Form 7 IE DatePicker and Number Spinner Fix, Custom fields, Datepicker i18n, Easy Calendar, EEXCESS, Event Post Type, Events Made Easy, Events Manager, Social Marketing Scheduler, FormCraft – Form Builder, Date Picker in List Fields for Gravity Forms, Gravity Forms (Spanish), Gravity Forms (nl), inquiry form creator, Jet Event System for BuddyPress, JQuery Accessible Accordion, JQuery Accessible Autocomplete, JQuery Accessible Button, JQuery Accessible Carousel, JQuery Accessible Checkbox, JQuery Accessible Datepicker, JQuery Accessible Dialog, JQuery Accessible Menu, JQuery Accessible Progressbar, JQuery Accessible Slider, JQuery Accessible Tabs, JQuery Accessible Tooltip, JQuery Accessible Tree, Js-appointment, LearnPress – WordPress LMS Plugin, LePress, List Urls, Livemesh SiteOrigin Widgets, Lodgix.com Vacation Rental Listing, Management & Booking Plugin, MailChimp List Subscribe Form, Social Media Share Buttons | MashShare, Member Register, Membership 2, Meta Collections, mind-body, Tribulant Newsletters, Orbis, Order Delivery Date for WooCommerce, OpenWebAnalytics, Pay2Post, PDF Catalog, Pronamic Events, RPB Calendar, Vinum Master Tracking Plugin, Simple Ads Manager, Simple Photos Contest, Sk Multi Tag, Solidres – Hotel booking plugin for WordPress, Cubilis Fastbooker, Surbma – Datepicker localization for Gravity Forms, teachPress, TemplatesNext ToolKit, TheNextTable, Toolset Types, Uiform – Cost Estimation & Payment Form Builder, Uiform – Form Builder, Vacation Rentals, Video Central for WordPress, Visual Form Builder, Webagency Widget – Website builder, WEeventscalendar, WooCommerce Checkout Manager, WooCommerce Quick Donation, WP Agenda, WP-AMD – Global JS and CSS handling, WP Any Form, WP Contact Slider, wp-creator-calculator, WP-CRM – Customer Relations Management for WordPress, WP FEvents Book, wp-greet, WP-Invoice – Web Invoice and Billing, WP Maintenance, WP Online Store, WP-Property – WordPress Powered Real Estate and Property Management, Wp-Recall, WP Scripts Updater, WP Swiper, wpShopGermany Free, and XO Event Calendar.

#4-6, #dev-notes, #external-libraries, #i18n

Pre-instantiated Widget Registration in 4.6

Since WP_Widget was introduced in 2.8 the register_widget() and unregister_widget() functions required the class name (string) of a WP_Widget subclass to be supplied. As of 4.6 these functions also accept a class instance (object) of a WP_Widget subclass as well. See #28216.

Two key benefits for allowing objects to be instantiated are:

  1. Widgets can now be instantiated and registered with constructor dependency injection.
  2. New 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. types can now be added dynamically, such as adding a Recent Posts widget for each post type, per #35990.

#4-6, #dev-notes, #widgets