The API should allow updates that don't actually change anything. This allows
clients to, for example, accidentally send the same request twice without
encountering unexpected errors. This currently works for posts, terms, and
users, so this commit adds test cases accordingly.
See #38700 for issues preventing this from working for comments.
Fixes#38975.
Built from https://develop.svn.wordpress.org/trunk@39371
git-svn-id: http://core.svn.wordpress.org/trunk@39311 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Fixes typo in args passed to `get_term_link()` which caused a fatal error due to this call returning a `WP_Error` which was set to `url`. Also fixes never-satisfiable condition for obtaining post type archive URL. Also ensures that `WP_Error` never leaks through as `url` by setting it to an empty string. Adds missing unit tests.
Amends [38991].
See #38114.
Fixes#38945.
Built from https://develop.svn.wordpress.org/trunk@39365
git-svn-id: http://core.svn.wordpress.org/trunk@39305 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Moves logic from `WP_Customize_Custom_CSS_Setting::update()` into a re-usable `wp_update_custom_css_post()` function, useful for future REST API endpoint, WP-CLI command, or plugin migrations.
* Renames `customize_update_custom_css_post_content_args` filter to `update_custom_css_data` and improves the naming of the parameters. Instead of passing `post_content` and `post_content_filtered` the filtered array now contains `css` and `preprocessed` respectively.
* The second context param for the `update_custom_css_data` filter is now an array of the original args passed to `wp_update_custom_css_post()` and there is now no more `$setting` arg since it isn't necessarily being called in the customizer context.
Props westonruter, georgestephanis.
See #35395.
Fixes#38672.
Built from https://develop.svn.wordpress.org/trunk@39350
git-svn-id: http://core.svn.wordpress.org/trunk@39290 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Core requires the post password to view and create comments on password protected posts, so we must support a “password” param on the comments endpoint when fetch comments for a specific post and creating a comment on a password protected post.
Props flixos90, jnylen0.
Fixes#38692.
Built from https://develop.svn.wordpress.org/trunk@39349
git-svn-id: http://core.svn.wordpress.org/trunk@39289 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Brings consistency to the `rest_insert_*` actions. Also includes some shuffling and clean-up as well including:
- Ensure we are passing the most current `$post` and `$user` objects to the `update_additional_fields_for_object()` callbacks.
- Changes the function signature of `handle_status_param()` in the Comments controller to accept just the comment_id as the 2nd parameter, instead of a full WP_Comment object. Only the comment_id is needed in the method, this avoids having to include another `get_comment()` call.
- Renames a variable in the `create_item()` method of the Posts controller from `$post` -> `$prepared_post` to be more explicit.
- Minor fixes/clarifications to the rest_insert_* hook docs
Props rachelbaker, joehoyle
Fixes#38905.
Built from https://develop.svn.wordpress.org/trunk@39348
git-svn-id: http://core.svn.wordpress.org/trunk@39288 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Featured image support means that attachments can now be imported. Media can be sideloaded from within theme or plugin directories. Like other posts, attachments are auto-drafts until customizer changes are published, and are not duplicated when they already exist in the customized state. Attachment IDs can be used for any number of purposes, much like post IDs. Twenty Seventeen now includes 3 images used as featured images to best showcase the multi-section homepage setup.
As featured image IDs are stored in post meta, it also made sense to add support for page templates. Twenty Seventeen does not include any such templates, but the functionality can be quite important for displaying themes to their best effect.
props westonruter, helen, flixos90.
fixes#38615.
Built from https://develop.svn.wordpress.org/trunk@39346
git-svn-id: http://core.svn.wordpress.org/trunk@39286 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This bug occurred in any language where text wraps character-by-character, since those languages don't delimit words with spaces. In Japanese, Chinese and Korean, etc., it was possible for the label to be displayed vertically.
Props tg29359, afercia, odysseygate.
Fixes#38876.
Built from https://develop.svn.wordpress.org/trunk@39341
git-svn-id: http://core.svn.wordpress.org/trunk@39281 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This makes a few adjustments to CSS to bring them inline with WordPress
CSS coding standards including:
* Font weights should be defined using numeric values
* Do not pad parentheses with spaces
This also fixes a couple of typos to inline comments.
Props netweb for initial patch.
Fixes#38901.
Built from https://develop.svn.wordpress.org/trunk@39340
git-svn-id: http://core.svn.wordpress.org/trunk@39280 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When a custom header image was set but custom CSS was not, `wp_get_custom_css_post()` was generating an UPDATE query on every frontend request.
In theme options the header image meta data is stored as an object. In `update_option()` this hits an edge case as the resource IDs of the old and new values never match.
This changes the logic of `wp_get_custom_css_post()` to ensure `set_theme_mod()` is only called when the custom CSS has changed.
Props bradyvercher, helen.
Fixes#38866.
Built from https://develop.svn.wordpress.org/trunk@39338
git-svn-id: http://core.svn.wordpress.org/trunk@39278 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Invalid nav menu items are exported as settings in the customize controls since it `is_admin()`, but any such `nav_menu_item` settings are excluded from the preview since it's the frontend. Selective refresh for nav menus needs to ignore the syncing of any such `nav_menu_item` settings that are `_invalid` since they are never rendered, and when a nav menu only contains invalid items, an infinite fallback refresh can ensue.
Fixes#38890.
Built from https://develop.svn.wordpress.org/trunk@39333
git-svn-id: http://core.svn.wordpress.org/trunk@39273 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, if no translation files exist for a text domain, `_load_textdomain_just_in_time()` went through the entire process each time it was called. This results in an increased call to `get_locale()` and its `locale` filter.
This change splits the logic into `_get_path_to_translation()` and `_get_path_to_translation_from_lang_dir()`. The former, which is used by `_load_textdomain_just_in_time()`, caches the result of the latter. It also removes some non-working code from `WP_Locale_Switcher::load_translations()`.
Props jrf, swissspidy, sharkomatic, ocean90.
Fixes#37997.
Built from https://develop.svn.wordpress.org/trunk@39330
git-svn-id: http://core.svn.wordpress.org/trunk@39270 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adding a brand new anonymous comment method is a potential conduit for spam. Since it's still useful functionality, we're now hiding it behind a filter to allow plugins and themes to turn it on if they do want it.
Props helen, rachelbaker, joehoyle.
Fixes#38855.
Built from https://develop.svn.wordpress.org/trunk@39327
git-svn-id: http://core.svn.wordpress.org/trunk@39267 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This removes support for the skin tone modifier on emoji involving two or more people. This functionality is opposed by Apple and Google, so there is unlikely to be an input mechanism for such emoji, they oppose it on the grounds that they "...do not think a mechanism should be supported that only permits depiction of multi-person groups (or elements) in which each person has the same skin tone."
See their official notification for further details: http://www.unicode.org/L2/L2016/16332-remove-multi-emb.pdf
This change does not require a CDN update, as no emoji were altered or added, only removed.
See #38113.
Built from https://develop.svn.wordpress.org/trunk@39319
git-svn-id: http://core.svn.wordpress.org/trunk@39259 1a063a9b-81f0-0310-95a4-ce76da25c4cd
