Historically, it has been possible to call `get_term_by()` within
a 'get_terms' filter callback. Since `get_term_by()` was refactored
to use `get_terms()` internally [38677], callbacks of this nature
have resulted in infinite loops.
As a workaround, we introduce a 'suppress_filter' option to `get_terms()`,
and use it when calling the function from within `get_term_by()`.
Props ocean90.
See #21760.
Built from https://develop.svn.wordpress.org/trunk@40275
git-svn-id: http://core.svn.wordpress.org/trunk@40192 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change moves to specifying the PHPUnit version for all PHP versions, and fixes an issue where the Composer global bin directory is not at `~/.composer/vendor/bin` on the boxes that are used for HHVM builds.
See #40100
Built from https://develop.svn.wordpress.org/trunk@40269
git-svn-id: http://core.svn.wordpress.org/trunk@40188 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Overriding pluggable functions in the test suite is asking for trouble in the future. In addition, it means the test suite can't be guaranteed to behave the same as core.
This instead introduces a `send_auth_cookies` filter which can be hooked in during the test suite to prevent these functions from attempting to send cookie headers to the client.
Fixes#39367
Built from https://develop.svn.wordpress.org/trunk@40263
git-svn-id: http://core.svn.wordpress.org/trunk@40183 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The site's current timezone offset is an important piece of information for any REST API client that needs to manipulate dates. It has not been previously available.
Expose both the `gmt_offset` (the site's current offset from UTC in hours) and `timezone_string` (which also provides information about daylight savings time) via the "site info" endpoint (the base `/wp-json` response).
Also update the `wp-api-generated.js` fixture file with the changes to the default API responses.
Props sagarkbhatt.
Fixes#39854.
Built from https://develop.svn.wordpress.org/trunk@40238
git-svn-id: http://core.svn.wordpress.org/trunk@40168 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit adds some missing test cases for combinations of `orderby` and other parameters (`post_parent__in` and `post_name__in`).
Followup to [40056] for `orderby` and `post__in`.
The interaction of these parameters is perhaps counterintuitive because `orderby` does not affect the returned results. This is overall probably the best design, and it's now better tested and documented.
Props fibonaccina.
See #39055.
Built from https://develop.svn.wordpress.org/trunk@40237
git-svn-id: http://core.svn.wordpress.org/trunk@40167 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Terms with duplicate names are not allowed at the same level of a
taxonomy hierarchy. The name lookup introduced in [34809] did not
properly account for the 'parent' parameter, with the result that
the duplicate-name restriction was tighter than intended (terms
with duplicate names could not be created at different levels of
a single hierarchy).
Props mikejolley.
Fixes#39984.
Built from https://develop.svn.wordpress.org/trunk@40145
git-svn-id: http://core.svn.wordpress.org/trunk@40084 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_insert_term()` does not allow for terms with the same name to exist
at the same hierarchy level, unless the second term has a unique slug.
When this logic was refactored in [31792] and [34809], a bug was
introduced whereby it was possible to bypass the no-same-named-sibling
check in cases where the first term had a non-auto-generated slug
(ie, where the name was 'Foo' but the slug something other than 'foo',
such that the second term would get the non-matching slug 'foo').
This changeset fixes this issue by ensuring that the duplicate name
check runs both in cases where there's an actual slug clash *and* in
cases where no explicit `slug` has been provided to `wp_insert_term()`.
The result is a more reliable error condition:
`wp_insert_term( 'Foo' ... )` will always fail if there's a sibling
'Foo', regardless of the sibling's slug.
Props mikejolley.
See #39984.
Built from https://develop.svn.wordpress.org/trunk@40144
git-svn-id: http://core.svn.wordpress.org/trunk@40083 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since support for PDF previews were added in [38949], it's possible
that the generated image file could overwrite an existing image file
with the same name. This uses `wp_unique_filename()` to avoid this
issue and adds a '-pdf' identifier on the end of filenames.
Props gitlost, derosj, mikeschroder, joemcgill.
Fixes#39875. See #31050.
Built from https://develop.svn.wordpress.org/trunk@40130
git-svn-id: http://core.svn.wordpress.org/trunk@40067 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [40123], `WP_Image_Editor_Imagick` started using
`Imagick::setImageOrientation` and `Imagick::ORIENTATION_TOPLEFT`,
but had no equivalent feature check.
While they were introduced more than 9 years ago, it's important
to double-check everything is available before using with Imagick.
Fixes#37140.
Built from https://develop.svn.wordpress.org/trunk@40129
git-svn-id: http://core.svn.wordpress.org/trunk@40066 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A few of the multisite tests were failing after [40124] because
multisite filters `upload_mimes` with the `check_upload_mimes()`
function to reduce the set of allowed MIME types. This fixes those
errors by skipping the tests for adding additional MIME types and
only tests file types assumed to be allowed.
See #39550.
Built from https://develop.svn.wordpress.org/trunk@40125
git-svn-id: http://core.svn.wordpress.org/trunk@40062 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[39831] introduced more strict MIME type checking for uploads, which
resulted in unintetionally blocking several filetypes that were
previously valid. This change uses a more targeted approach to MIME
validation to restore previous behavior for most types.
Props blobfolio, iandunn, ipstenu, markoheijnen, xknown, joemcgill.
Fixes#39550, #39552.
Built from https://develop.svn.wordpress.org/trunk@40124
git-svn-id: http://core.svn.wordpress.org/trunk@40061 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Due to inconsistencies in the way browsers handle Exif orientation data,
if a user manually rotates an image within WordPress, set the Exif orientation to
the default (1) so that the image displays with the same rotation/flip in every browser.
Props sanchothefat, triplejumper12, joemcgill, azaozz, markoheijnen, mikeschroder.
See #14459.
Fixes#37140.
Built from https://develop.svn.wordpress.org/trunk@40123
git-svn-id: http://core.svn.wordpress.org/trunk@40060 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, when getting posts from the API with `sticky=true`, if there were no sticky posts set, the query would return all posts as if the `sticky` argument was not set. In this situation, the query should return an empty array instead.
A `sticky=true` query that should return an empty array (in the previous situation, or with `include` and no intersecting post IDs) was also broken in that it would query the post with ID 1.
Finally, this commit significantly improves test coverage for the `sticky` filter argument, including direct testing of the `WHERE` clauses generated by `WP_Query`.
Props ryelle.
Fixes#39947.
Built from https://develop.svn.wordpress.org/trunk@40122
git-svn-id: http://core.svn.wordpress.org/trunk@40059 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A `post_format` not used by the current theme, but supported by core is not a wrong/broken piece of information. It's just not used at this point in time. Therefore we should allow setting and retrieving any of the standard post formats supported in core, even if the current theme doesn't use them.
After this commit, a post's `format` value can survive a round trip through the API, which is a good general design principle for an API.
Props JPry, iseulde, davidakennedy, Drivingralle.
Fixes#39232.
Built from https://develop.svn.wordpress.org/trunk@40120
git-svn-id: http://core.svn.wordpress.org/trunk@40057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
