WordPress tries to avoid an issue where slugs might match an existing slug of a page/post.
If we are in a hierarchical post type, there will be a level, and we can leave it the same.
Props stormrockwell, SergeyBiryukov, terriann, tubys, jeremyfelt, Daschmi, MaximeCulea, knutsp, whyisjake.
Fixes#51147.
See also #44112 and #45260.
Built from https://develop.svn.wordpress.org/trunk@51855
git-svn-id: http://core.svn.wordpress.org/trunk@51454 1a063a9b-81f0-0310-95a4-ce76da25c4cd
To be able to disable jQuery Migrate as step 3 of updating the jQuery version shipped with WordPress, all `JQMIGRATE` warnings in the browser console will have to be addressed.
This includes many minor adjustments to a wide array of core files.
Follow-up to:
* Step 1: Disabling jQuery Migrate 1.4.1 in WordPress 5.5: [48323], [48324]
* Step 2: Updating jQuery to 3.5.1 and adding jQuery Migrate 3.3.x in WordPress 5.6: [49101], [49338], [49615], [49649]
Props Clorith, azaozz.
See #51812.
Built from https://develop.svn.wordpress.org/trunk@50001
git-svn-id: http://core.svn.wordpress.org/trunk@49702 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Add missing translator comments.
* Fix placement of some translator comments. Translator comments should be on the line directly above the line containing the translation function call for optimal compatibility with various `.pot` file generation tools. The CS auto-fixing, which changed some inconsistent function calls to multi-line function calls, is part of the reason why this was no longer the case for a select group of translator comments.
Includes minor code layout fixes.
Polyglots, rejoice! All WordPress core files now have translator comments for all strings with placeholders!
Props jrf, subrataemfluence, GaryJ, webdados, Dency, swissspidy, alvarogois, marcomartins, mihaiiceyro, vladwtz, niq1982, flipkeijzer, michielatyoast, chandrapatel, thrijith, joshuanoyce, FesoVik, tessak22, bhaktirajdev, cleancoded, dhavalkasvala, garrett-eclipse, bibliofille, socalchristina, priyankkpatel, 5hel2l2y, adamsilverstein, JeffPaul, pierlo, SergeyBiryukov.
Fixes#44360.
Built from https://develop.svn.wordpress.org/trunk@45926
git-svn-id: http://core.svn.wordpress.org/trunk@45737 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- adds `role="presentation"` to the edit comment table
- removes a few pointless `<fieldset>` elements
- adds a few missing `<label>` elements
- adds the CSS class `class="td-full"` to table rows spanning to multiple cells
- adds explicit `scope="row"` attribute to the table headers in `options-permalink.php`: this table is better communicated as data table
- uses consistent label association in the "Privacy Settings" page
- in the installation page "Set up your database connection": associates descriptions to their inout fields using `aria-describedby`
- improves the link to gravatar.com in the `user-edit.php` page
See #46899.
Fixes#47390.
Built from https://develop.svn.wordpress.org/trunk@45416
git-svn-id: http://core.svn.wordpress.org/trunk@45227 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds `role="presentation"` to the `<table>` elements used for layout purposes.
Ideally, HTML tables should be used for tabular data. When tables are used for layout purposes, it's important to remove any native semantics so that assistive technologies can correctly announce the table content in a linearized fashion.
Props greatislander, afercia.
Fixes#46899.
Built from https://develop.svn.wordpress.org/trunk@45403
git-svn-id: http://core.svn.wordpress.org/trunk@45214 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Some "visual tabs" in the WordPress admin used links wrapped in a `h2` heading. While these tabs look like ARIA tabs, they're just navigation menus and should be marked-up as such to be correctly exposed to assistive technologies.
- changes the wrapping `<h2>` to a `<nav>` element: worth reminding `<nav>` elements also define ARIA landmarks
- adds an `aria-label` to the `<nav>` elements so they can be distinguished from other `<nav>` elements in the page
- adjusts the headings level in the Credits page
Props audrasjb, afercia.
Fixes#43398.
Built from https://develop.svn.wordpress.org/trunk@44905
git-svn-id: http://core.svn.wordpress.org/trunk@44736 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset makes the new CRUD API for sites introduced in [43548] usable for real-world sites. A new function `wp_initialize_site()`, which takes care of creating a site's database tables and populating them with initial values, is hooked into the site insertion process that is initiated when calling `wp_insert_site()`. Similarly, a new function `wp_uninitialize_site()`, which takes care of dropping a site's database tables, is hooked into the site deletion process that is initiated when calling `wp_delete_site()`.
A new function `wp_is_site_initialized()` completes the API, allowing to check whether a site is initialized. Since this function always makes a database request in its default behavior, it should be called with caution. Plugins that would like to use site initialization in special ways can leverage a `pre_wp_is_site_initialized` filter to alter that default behavior.
The separate handling of the site's row in the `wp_blogs` database table and the actual site setup allows for more flexibility in controlling whether or how a site's data is set up. For example, a unit test that only checks data from the site's database table row can unhook the site initialization process to improve performance. At the same time, developers consuming the new sites API only need to know about the CRUD functions, since the initialization and uninitialization processes happen internally.
With this changeset, the foundation for a sites REST API endpoint is fully available. The previously recommended functions `wpmu_create_blog()` and `wpmu_delete_blog()` now call the new respective function internally. Further follow-up work to this includes replacing calls to `wpmu_create_blog()` with `wp_insert_site()`, `update_blog_details()` with `wp_update_site()` and `wpmu_delete_blog()` with `wp_delete_blog()` throughout the codebase.
As a side-effect of this work, the `wpmu_new_blog`, `delete_blog`, and `deleted_blog` actions and the `install_blog()` function have been deprecated.
Fixes#41333. See #40364.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
New functions `wp_insert_site( $data )`, `wp_update_site( $id, $data )` and `wp_delete_site( $id )` are introduced to manage site rows in the `wp_blogs` table, forming the new CRUD API together with the existing `get_site()` / `get_sites()`. The new API provides various benefits over the previously existing API, fixing several cache invalidation issues and being hook-driven so that normalization and validation of the passed data can be fully customized.
New hooks introduced as part of this are the actions `wp_insert_site`, `wp_update_site`, `wp_delete_site`, `wp_validate_site_data` and the filter `wp_normalize_site_data`.
At this point, `wp_insert_site()` does not handle setting up the site's database tables, and `wp_delete_site()` does not handle dropping the site's database tables, so the two can not yet be used directly as full replacements of `wpmu_create_blog()` and `wpmu_delete_blog()`. Managing the site's database tables will be added via hooks as part of the follow-up ticket #41333.
The existing functions `wpmu_create_blog()`, `update_blog_details()`, and `wpmu_delete_blog()` make use of the respective new counterpart and will be obsolete once #41333 has been completed.
Props flixos90, jeremyfelt, spacedmonkey.
Fixes#40364.
Built from https://develop.svn.wordpress.org/trunk@43548
git-svn-id: http://core.svn.wordpress.org/trunk@43377 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A new global multisite table `wp_blogmeta` is added to the database schema, and a set of `*_site_meta()` API functions are introduced.
The implementation fails gracefully when the new table is not yet available, which may happen especially shortly after the core update, before the network has been upgraded to the new database schema. The presence of the table is detected once and stored as a global setting on the main network.
Core does not yet use site metadata, but there are several use-cases to be implemented or explored in the near future, and it allows plugins to extend sites with arbitrary data, which will come in particularly handy with the upcoming REST API endpoint for sites.
Props spacedmonkey, johnjamesjacoby, jeremyfelt, flixos90.
Fixes#37923.
Built from https://develop.svn.wordpress.org/trunk@42836
git-svn-id: http://core.svn.wordpress.org/trunk@42666 1a063a9b-81f0-0310-95a4-ce76da25c4cd
"Install" is not a noun, and while it might be acceptable to use the verb as a noun, it is not correct. Using the correct
noun, "installation", increases clarity, especially for non-native English speakers.
This change fixes the usage in user-facing text and in developer documentation.
Fixes#41620
Built from https://develop.svn.wordpress.org/trunk@41289
git-svn-id: http://core.svn.wordpress.org/trunk@41129 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This adds this previously Multisite-only functionality to single site installations too. This change prevents accidental or erroneous email address changes from potentially locking users out of their site.
Props MatheusGimenez, johnbillion
Fixes#39118
Built from https://develop.svn.wordpress.org/trunk@41254
git-svn-id: http://core.svn.wordpress.org/trunk@41094 1a063a9b-81f0-0310-95a4-ce76da25c4cd
