* 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
With the exception of the "Edit" link, the "row actions" controls in the Comments table behave differently depending if JavaScript support is on or off.
When JavaScript support is off, they behave like links. When JavaScript support is on, they behave like buttons and they need to be buttons or have an ARIA `role="button"` added via JavaScript.
Lastly, the buttons in the Reply/Quick Edit form and the "Add Comment" in the edit post page meta box need to be buttons.
Fixes#43412.
Built from https://develop.svn.wordpress.org/trunk@44759
git-svn-id: http://core.svn.wordpress.org/trunk@44591 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When merging, [44244] and [44260] were committed to trunk the opposite way that they were committed to the 5.0 branch. They were originally committed in [43885] and [43861], respectively.
Due to this switch, a change in how the Custom Fields meta box was registered wasn't merged from the 5.0 branch, causing it to not be registered correctly in trunk.
Props dd32, pento.
Fixes#46028.
Built from https://develop.svn.wordpress.org/trunk@44648
git-svn-id: http://core.svn.wordpress.org/trunk@44479 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This brings support for the custom fields meta box into the new block editor.
The `webpack` and `copy-webpack-plugin` packages have also been updated.
This does not bump the `@wordpress` packages like in [43861] because of conflicts with package versions already installed in `trunk`. The packages will be brought up to date in a subsequent merge.
Merges [43861] and [43863] into trunk.
See #45145.
Fixes#45257.
Built from https://develop.svn.wordpress.org/trunk@44260
git-svn-id: http://core.svn.wordpress.org/trunk@44090 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Some plugins remove the Custom Fields meta box, particularly when they provide functionality that replaces it. The block editor would correctly not display this meta box in these circumstances, but it still showed the option to display or hide it.
Props pento, noisysocks.
Merges [43885] to trunk.
See #45282.
Built from https://develop.svn.wordpress.org/trunk@44244
git-svn-id: http://core.svn.wordpress.org/trunk@44074 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The block editor needs to duplicate the classic meta box behaviour, so it can extract the registered meta boxes, and import them into the block editor.
To match the classic editor behaviour as closely as possible, this moves the relevant code from the classic editor, into a new function, so it can be called by both.
Merges [43837] from the 5.0 branch to trunk.
Props pento, peterwilsoncc.
Fixes#45172.
Built from https://develop.svn.wordpress.org/trunk@44214
git-svn-id: http://core.svn.wordpress.org/trunk@44044 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
In order to get the best result when running `phpcbf` across the codebase, there are some manual tweaks we need to make.
These fall into three categories:
- Fixing incorrectly indented code which has flow-on effects when auto-fixing.
- Tweaking the layout of inline PHP inside HTML tags.
- Moving more complex inline PHP inside HTML tags, to execute earlier.
See #44600.
Built from https://develop.svn.wordpress.org/trunk@43569
git-svn-id: http://core.svn.wordpress.org/trunk@43398 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42228
git-svn-id: http://core.svn.wordpress.org/trunk@42057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This pattern occurs a handful of times across the codebase:
`<div class="foo<?php if ( $bar ) { echo ' baz'; } ?>">`
Unfortunately, it doesn't really play nicely with `phpcbf`, so all instances need to be removed in preperation for auto code formatting.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42217
git-svn-id: http://core.svn.wordpress.org/trunk@42046 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Update stubs to have draft status when changeset is saved as draft, instead of preventing auto-draft garbage collection by giving them a far-future `post_date`.
* Show notice in publish metabox when editing a customization draft indicating that it will be published automatically with its changeset; a link to Customizer is included.
* Include a new "Customization Draft" display post state in the post list table.
* Disconnect stubs from their changesets when they are updated with a status other than "Draft".
* Trash customization drafts when their related changeset is trashed or deleted.
* Add a `_customize_changeset_uuid` postmeta to stubs to link them with their associated changeset.
* Include `customize_changeset_uuid` as context when requesting to insert a new auto-draft.
Props westonruter, melchoyce.
See #39896, #39752, #34923.
Fixes#42220.
Built from https://develop.svn.wordpress.org/trunk@41887
git-svn-id: http://core.svn.wordpress.org/trunk@41721 1a063a9b-81f0-0310-95a4-ce76da25c4cd
With [38951] the support for custom page templates has been extended to all post
types. By making the visible meta box titles real labels, accessibility improves
for all users and form fields have meaningful labels.
Fixes#38790.
Built from https://develop.svn.wordpress.org/trunk@39247
git-svn-id: http://core.svn.wordpress.org/trunk@39187 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages.
While this feature is very helpful, it has always been limited to the 'page' post type and not was not available to other post types.
By opening up the page template functionality to all post types, we continue to improve the template hierarchy's flexibility.
In addition to the `Template Name` file header, the post types supported by a template can be specified using `Template Post Type: post, foo, bar`.
When at least one template exists for a post type, the 'Post Attributes' meta box will be displayed in the back end, without the need to add post type support for `'page-attributes'`. 'Post Attributes' can be customized per post type using the `'attributes'` label when registering a post type.
Props johnbillion, Mte90, dipesh.kakadiya, swissspidy.
Fixes#18375.
Built from https://develop.svn.wordpress.org/trunk@38951
git-svn-id: http://core.svn.wordpress.org/trunk@38894 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- changes the "X" links in buttons, improves their color contrast ratio and focus style
- adds screen reader text "Remove item: + tagname"
- uses `wp.a11y.speak()` to give screen reader users feedback when adding/removing tags
- makes the `tagcloud-link` toggle a button, with an `aria-expanded` attribute to indicate the tag cloud collapsed/expanded state
- changes colors for the autocomplete highlighted option in order to have a better color contrast ratio
- reduces the font size for the autocomplete on Press This
- removes CSS related to the old `suggest.js` from Press This
Props joedolson, cgrymala, azaozz, afercia.
Fixes#27555.
Built from https://develop.svn.wordpress.org/trunk@38880
git-svn-id: http://core.svn.wordpress.org/trunk@38823 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Replace suggest.js with UI Autocomplete.
- Use the same settings like in the editor link toolbar.
- Abstract it and add in a new file, tags-suggest.js. Then make it a dependency for the Tags postbox(es) and Quick and Bulk Edit.
- Add `data-wp-taxonomy` on all input elements to improve handling in the UI for custom taxonomies.
Props afercia, azaozz.
See #33902.
Built from https://develop.svn.wordpress.org/trunk@38797
git-svn-id: http://core.svn.wordpress.org/trunk@38740 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This introduces the singular `edit_term`, `delete_term`, and `assign_term` meta capabilities for terms, and switches the base capability name for tags from `manage_categories` to `manage_post_tags` and the corresponding `edit_post_tags`, `delete_post_tags`, and `assign_post_tags`.
All of these capabilities ultimately map to `manage_categories` so by default there is no change in the behaviour of the capabilities for categories, tags, or custom taxonomies. The `map_meta_cap` filter and the `capabilities` argument when registering a taxonomy now allow for control over editing, deleting, and assigning individual terms, as well as a separation of capabilities for tags from those of categories.
Fixes#35614
Props johnjamesjacoby for feedback
Built from https://develop.svn.wordpress.org/trunk@38698
git-svn-id: http://core.svn.wordpress.org/trunk@38641 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces some consistency in the usage of the button CSS classes, fixes the
focus style for accessibility and responsiveness of the buttons.
- Adds the `button` class to all primary buttons make them responsive
- Removes all `secondary-button` classes and replaces it with button when needed. `button-secondary` shouldn't be used and exists just for backward compatibility reasons
- Replaces classes inside `submit_button()` with a shorthand for some buttons, and use an empty string for the default `button` class. Passing `button` is unnecessary
- Adjusts `get_submit_button()` to remove empty items
Props iseulde, dimchik, chris_d2d, mhowell, afercia.
Fixes#27314, #37138, #37448.
Built from https://develop.svn.wordpress.org/trunk@38672
git-svn-id: http://core.svn.wordpress.org/trunk@38615 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `submitdelete` CSS class is used in various places across the admin for some
"red" action links. It is worth simplifying this rule for further improvements
related to color contrast.
- simplifies a non-standard styling for the "Remove/Cancel" links in the Menus screen
- underlines all the "Move to trash/Delete" red links in all the Publish meta boxes
- fixes CSS classes usage for all the Publish meta boxes primary buttons
- fixes broken layout for the old Link Manager publish meta box
Props karmatosed, hugobaeta, monikarao, afercia.
Fixes#37969, #37018. See #37448, #37138, #27314.
Built from https://develop.svn.wordpress.org/trunk@38616
git-svn-id: http://core.svn.wordpress.org/trunk@38559 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Longer passwords and passphrases are much more common than when post passwords were introduced all those eons ago, so let's increase the length of the `post_password` field from 20 to 255 characters.
The password will continue to be stored in plaintext, as the ability for the post author to view the password is a commonly used feature.
Trivia: this was the last 3 digit Trac ticket to be closed.
Props skippy, nazgul, iandunn, adamsilverstein, pento.
Fixes#881.
Built from https://develop.svn.wordpress.org/trunk@38590
git-svn-id: http://core.svn.wordpress.org/trunk@38533 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Avoid references to "visual" positions in favour of positions in the document
structure. The help text shouldn't assume users can see.
Also, in the Posts screen don't mention specific types of posts and use a more
generic text instead.
Props odysseygate, pansotdev, zakb8.
Fixes#34761.
Built from https://develop.svn.wordpress.org/trunk@37680
git-svn-id: http://core.svn.wordpress.org/trunk@37646 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After [36053] don't show a warning about something users can't change
because there's no control exposed in the UI for that. The Revisions
screen is probably a better place to show a more complete information.
Fixes#35029.
Built from https://develop.svn.wordpress.org/trunk@36612
git-svn-id: http://core.svn.wordpress.org/trunk@36579 1a063a9b-81f0-0310-95a4-ce76da25c4cd
User dropdowns in wp-admin have traditionally shown the users' display names.
However, this causes ambiguity when users share display names. To correct this,
we now show the unique user_login in parentheses after the display name.
The new `display_name_with_login` value for the `show` parameter of
`wp_dropdown_users()` enables this functionality. The default value of `show`
has not been changed, for backward compatibility, but all instances of
`wp_dropdown_users()` in core wp-admin have been switched.
This changeset also reduces some duplicated logic when assembling a user list
when `include_selected` is true.
Props krogsgard, boonebgorges.
Fixes#31251.
Built from https://develop.svn.wordpress.org/trunk@35790
git-svn-id: http://core.svn.wordpress.org/trunk@35754 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Introduce `is_post_type_viewable( $post_type_object )`
* Separate the HTML bits from the translatable bits in the `post` messages array in `edit-form-advanced.php`
* Don't show certain UI pieces when a post is not viewable on the front end
When a custom post type item is not viewable on the front end, we don't want to show links to View it (on the front end) all over the admin. We also want to hide the Preview link, et al. We also want our admin messages to not contain said links.
Custom post types with `public_queryable` set to `false` are not viewable on the front end.
`'page'` is viewable on the front end, but `'page'` is a `_builtin` type, and `public_queryable` is set to `false` when it is registered - see `WP::parse_request()` for when `public_queryable` gets used.
This is confusing, but also somewhat straightforward: to determine if a post type is viewable on the front end, we can check one way for `_builtin => true` and another way for `_builtin => false`:
`$post_type->publicly_queryable || ( $post_type->_builtin && $post_type->public )`
If a post type is `publicly_queryable`, it's viewable. If that value is `false`, it is viewable if it's a `_builtin` type that is also `public`.
I am in search of edge cases, so this shall land.
Props wonderboymusic, DrewAPicture.
See #17609.
Built from https://develop.svn.wordpress.org/trunk@33666
git-svn-id: http://core.svn.wordpress.org/trunk@33633 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Users are frequently confused as to why the content they've entered or the page template they've selected doesn't apply for this one page. Showing and saving items that don't do anything hurts trust.
Developers can elect to turn on the editor should they be using it for something. If the content isn't empty, the editor will show so that users still have access to their content.
props alexkingorg for the initial, long-suffering patch.
fixes#17470.
Built from https://develop.svn.wordpress.org/trunk@31550
git-svn-id: http://core.svn.wordpress.org/trunk@31531 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Both functions only need to read `taxonomy`, yet they extract every available variable from `$box['args']`. Even if those variables were useful, there is no attempt to pass them to anything, and scope in PHP does not allow them to be scooped up by inner functions without being passed directly.
See #22400.
Built from https://develop.svn.wordpress.org/trunk@28391
git-svn-id: http://core.svn.wordpress.org/trunk@28219 1a063a9b-81f0-0310-95a4-ce76da25c4cd