As decided in the JavaScript core chat. With a few reasons:
* It is visually cleaner when reading the source.
* This bring the JavaScript documentation closer to the PHP documentation.
The only disadvantage is that the JSDoc parser doesn't split out the summary and the description in the new format. We've decided to solve this when building the JavaScript documentation parser.
Props herregroen.
Fixes#42901.
Built from https://develop.svn.wordpress.org/trunk@42411
git-svn-id: http://core.svn.wordpress.org/trunk@42240 1a063a9b-81f0-0310-95a4-ce76da25c4cd
On the "Attachment Details" screen:
* The crop button is always 'enabled'.
* Clicking the crop button with no selection selects the entire image.
* Clicking the crop button with the entire image selected doesn't do anything.
* Clicking the crop button with a selection crops as expected.
Props sonjanyc, afercia, mikeschroder.
Fixes#30155.
Built from https://develop.svn.wordpress.org/trunk@42404
git-svn-id: http://core.svn.wordpress.org/trunk@42233 1a063a9b-81f0-0310-95a4-ce76da25c4cd
JSDoc takes it structural data from `@namespace`, `@lends` and `@memberOf`. This change fixes these tags for all JavaScript files in the wp-admin folder.
* Add jsdoc configuration to parse wp-admin/js files. Use `jsdoc -c jsdoc.conf.json` to generate JSDoc.
* Define all used namespaces using `@namespace`.
* Define each usage of the extend function as a prototype assignment using `@lends`.
* Add `@alias` if JSDoc cannot detect the correct name automatically.
This has previously been corrected for all `wp-includes` JavaScript files: [41351].
Props herregroen.
Fixes#42485.
Built from https://develop.svn.wordpress.org/trunk@42403
git-svn-id: http://core.svn.wordpress.org/trunk@42232 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `custom-header.js` file is only used on the `wp-admin/themes.php?page=custom-header` page. As that page is no longer linked from the UI the functions in the file are marked deprecated.
Props nicollle, jipmoors, diedeexterkate.
Fixes#42678.
Built from https://develop.svn.wordpress.org/trunk@42385
git-svn-id: http://core.svn.wordpress.org/trunk@42214 1a063a9b-81f0-0310-95a4-ce76da25c4cd
We have a handful of super long regexen that are written over multiple lines, as a collection of strings concatenated together. Each string is indented appropriately for the regex, but PHPCS doesn't recognised this, so defaults to removing the extra whitespace.
Disabling the `Squiz.Strings.ConcatenationSpacing.PaddingFound` rule for these blocks stops the extra whitespace from being removed.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42249
git-svn-id: http://core.svn.wordpress.org/trunk@42078 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While caching here seemed like a good idea in theory, in practice the cache would be often stale causing development issues.
We exclude common folders (such as `node_modules`) from the scanning to avoid directories which are not useful to the end-user, so as long as those exclusion lists are held up this shouldn't cause too much of a degredation in the future.
We may consider adding caching here again in the future if it's determined that it is really needed.
Props precies, ibenic, mariovalney, schlessera, and all the others who commented on the ticket(s).
This partually reverts [41806].
See #6531.
Fixes#42573.
Built from https://develop.svn.wordpress.org/trunk@42242
git-svn-id: http://core.svn.wordpress.org/trunk@42071 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
When the setup process reads `wp-config-sample.php`, it assumes that there are no spaces inside the brackes of the `define()`s. Unfortunately, this doesn't match our coding standards, so will no longer work correctly once we start enforcing them.
This also improves coding standards of the generated `wp-config.php` file.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42218
git-svn-id: http://core.svn.wordpress.org/trunk@42047 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
The `meta_box_cb` argument was introduced in [25572] to allow plugin
authors to provide a custom callback for rendering their taxonomy's meta
box on the post edit screen. However, the routine used to handle the saving
of these custom taxonomy meta boxes was not customizable, but was instead
based simply on whether the taxonomy was hierarchicaly. See [13535].
The new `meta_box_sanitize_cb` argument defaults to the "tag" routine for
non-hierarchical taxonomies and the "category" routine for hierarchical ones,
thereby maintaining the current default behavior. Developers can override this
when the data passed from their `meta_box_cb` differs.
Props boonebgorges, ZaneMatthew, stephenharris.
Fixes#36514.
Built from https://develop.svn.wordpress.org/trunk@42211
git-svn-id: http://core.svn.wordpress.org/trunk@42040 1a063a9b-81f0-0310-95a4-ce76da25c4cd
