This adds a new function `wp_get_image_mime()` which is used by
`wp_check_filetype_and_ext()` to validate image files using
`exif_imagetype()` if available instead of `getimagesize()`.
`getimagesize()` is less performant than `exif_imagetype()` and is
dependent on GD. If `exif_imagetype()` is not available, it falls back to
`getimagesize()` as before.
If `wp_check_filetype_and_ext()` can't validate the filetype, we now return
`false` for ext/MIME values.
Merges [39831] to the 4.7 branch.
Built from https://develop.svn.wordpress.org/branches/4.7@39832
git-svn-id: http://core.svn.wordpress.org/branches/4.7@39770 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A theme can opt-in for tailored starter content to apply to the customizer when previewing the theme on a fresh install, when `fresh_site` is at its initial `1` value. Starter content is staged in the customizer and does not go live unless the changes are published. Initial starter content is added to Twenty Seventeen.
* The `fresh_site` flag is cleared when a published post or page is saved, when widgets are modified, or when the customizer state is saved.
* Starter content is registered via `starter-content` theme support, where the argument is an array containing `widgets`, `posts`, `nav_menus`, `options`, and `theme_mods`. Posts/pages in starter content are created with the `auto-draft` status, re-using the page/post stubs feature added to nav menus and the static front page controls.
* A `get_theme_starter_content` filter allows for plugins to extend a theme's starter content.
* Starter content in themes can/should re-use existing starter content items in core by using named placeholders.
* Import theme starter content into customized state when fresh site.
* Prevent original_title differences from causing refreshes if title is present.
* Ensure nav menu item url is set according to object when previewing.
* Make sure initial saved state is false if there are dirty settings without an existing changeset.
* Ensure dirty settings are cleaned upon changeset publishing.
Props helen, westonruter, ocean90.
Fixes#38114, #38533.
Built from https://develop.svn.wordpress.org/trunk@38991
git-svn-id: http://core.svn.wordpress.org/trunk@38934 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In addition to `wp_list_filter()` for filtering a list of objects, and `wp_list_pluck()` for plucking a certain field out of each object in a list, this new function can be used for sorting a list of objects by specific fields. These functions are now all contained within the new `WP_List_Util()` class and `wp_list_sort()` is used in various parts of core for sorting lists.
This was previously committed in [38859] but got reverted in [38862] and [38863]. To fix the previous issues, `wp_list_sort()` supports now an additional argument to preserve array keys via `uasort()`.
Props flixos90, DrewAPicture, jorbin.
Fixes#37128.
Built from https://develop.svn.wordpress.org/trunk@38928
git-svn-id: http://core.svn.wordpress.org/trunk@38871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In addition to `wp_list_filter()` for filtering a list of objects, and `wp_list_pluck()` for plucking a certain field out of each object in a list, this new function can be used for sorting a list of objects by specific fields. These functions are now all contained within the new `WP_List_Util()` class and `wp_list_sort()` is used in various parts of core for sorting lists.
Props flixos90, DrewAPicture, jorbin.
Fixes#37128.
Built from https://develop.svn.wordpress.org/trunk@38859
git-svn-id: http://core.svn.wordpress.org/trunk@38802 1a063a9b-81f0-0310-95a4-ce76da25c4cd
One thing fairly common to the cache groups is a block of code to look to see when the cache was last changed, and if there isn't one, to set it for the current microtime(). It appears in 8 different places in core. This adds a new helper `wp_cache_get_last_changed` to DRY things up a bit.
Since `wp-includes/cache.php` isn't guaranteed to be loaded, this new function is in `wp-includes/functions.php`
Props spacedmonkey, desrosj.
Fixes#37464.
Built from https://develop.svn.wordpress.org/trunk@38849
git-svn-id: http://core.svn.wordpress.org/trunk@38792 1a063a9b-81f0-0310-95a4-ce76da25c4cd
REST API endpoints for your WordPress content. These endpoints provide machine-readable external access to your WordPress site with a clear, standards-driven interface, allowing new and innovative apps for interacting with your site. These endpoints support all of the following:
- Posts: Read and write access to all post data, for all types of post-based data, including pages and media.
- Comments: Read and write access to all comment data. This includes pingbacks and trackbacks.
- Terms: Read and write access to all term data.
- Users: Read and write access to all user data. This includes public access to some data for post authors.
- Meta: Read and write access to metadata for posts, comments, terms, and users, on an opt-in basis from plugins.
- Settings: Read and write access to settings, on an opt-in basis from plugins and core. This enables API management of key site content values that are technically stored in options, such as site title and byline.
Love your REST API, WordPress! The infrastructure says, "Let's do lunch!" but the content API endpoints say, "You're paying!"
Props rmccue, rachelbaker, danielbachhuber, joehoyle, adamsilverstein, afurculita, ahmadawais, airesvsg, alisspers, antisilent, apokalyptik, artoliukkonen, attitude, boonebgorges, bradyvercher, brianhogg, caseypatrickdriscoll, chopinbach, chredd, christianesperar, chrisvanpatten, claudiolabarbera, claudiosmweb, cmmarslender, codebykat, coderkevin, codfish, codonnell822, daggerhart, danielpunkass, davidbhayes, delphinus, desrosj, dimadin, dotancohen, DrewAPicture, Dudo1985, duncanjbrown, eherman24, eivhyl, eliorivero, elyobo, en-alis, ericandrewlewis, ericpedia, evansobkowicz, fjarrett, frozzare, georgestephanis, greatislander, guavaworks, hideokamoto, hkdobrev, hubdotcom, hurtige, iandunn, ircrash, ironpaperweight, iseulde, Japh, jaredcobb, JDGrimes, jdolan, jdoubleu, jeremyfelt, jimt, jjeaton, jmusal, jnylen0, johanmynhardt, johnbillion, jonathanbardo, jorbin, joshkadis, JPry, jshreve, jtsternberg, JustinSainton, kacperszurek, kadamwhite, kalenjohnson, kellbot, kjbenk, kokarn, krogsgard, kuchenundkakao, kuldipem, kwight, lgedeon, lukepettway, mantismamita, markoheijnen, matrixik, mattheu, mauteri, maxcutler, mayukojpn, michael-arestad, miyauchi, mjbanks, modemlooper, mrbobbybryant, NateWr, nathanrice, netweb, NikV, nullvariable, oskosk, oso96_2000, oxymoron, pcfreak30, pento, peterwilsoncc, Pezzab, phh, pippinsplugins, pjgalbraith, pkevan, pollyplummer, pushred, quasel, QWp6t, schlessera, schrapel, Shelob9, shprink, simonlampen, Soean, solal, tapsboy, tfrommen, tharsheblows, thenbrent, tierra, tlovett1, tnegri, tobych, Toddses, toro_unit, traversal, vanillalounge, vishalkakadiya, wanecek, web2style, webbgaraget, websupporter, westonruter, whyisjake, wonderboymusic, wpsmith, xknown, zyphonic.
Fixes#38373.
Built from https://develop.svn.wordpress.org/trunk@38832
git-svn-id: http://core.svn.wordpress.org/trunk@38775 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`get_network()` falls back to the current network when called without any arguments. Between this and `get_current_network_id()`, we can replace almost all instances of the global `$current_site` and all instances of `get_current_site()`.
This effectively deprecates `get_current_site()`, something that we'll do in a future ticket.
Props flixos90.
Fixes#37414.
Built from https://develop.svn.wordpress.org/trunk@38814
git-svn-id: http://core.svn.wordpress.org/trunk@38757 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Additionally, update the `$message` parameter description in the DocBlock for `wp_die()` to make it explicitly clear messages derived from a passed `WP_Error` object will only be evaluated if not performing an Ajax or XML-RPC request (as both default handlers completely ignore `WP_Error` object messages).
See #37770.
Built from https://develop.svn.wordpress.org/trunk@38518
git-svn-id: http://core.svn.wordpress.org/trunk@38459 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `wp-admin` and `wp-includes` are scanned for classes to autoload
* Several 3rd-party and Ryan McCue-shaped libraries are excluded when the classmap is generated, see `composer.json`: `autoload.exclude-from-classmap`
* `wp-vendor/autoload_52.php` is included at the top of `wp-settings.php` - no changes need to be made to unit tests to include the autoloader
* An avalanche of `require()` and `require_once()` calls that loaded class files have been removed from the codebase.
The following files have been added to `svn:ignore` - they are not 5.2-compatible and fail during pre-commit:
* src/wp-vendor/autoload.php
* src/wp-vendor/composer/autoload_real.php
* src/wp-vendor/composer/autoload_static.php
* src/wp-vendor/composer/ClassLoader.php
We favor these files instead:
* src/wp-vendor/autoload_52.php
* src/wp-vendor/composer/autoload_real_52.php
* src/wp-vendor/composer/ClassLoader52.php
When new PHP classes are added to the codebase, simply run `composer install` or `composer update` from the project root to update the autoloader.
The future is now.
See #36335.
Built from https://develop.svn.wordpress.org/trunk@38399
git-svn-id: http://core.svn.wordpress.org/trunk@38340 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Registration is now based solely on object type, which allows the code around this to be simplified significantly.
In the process of making this adjustment:
* `register_meta()`, `unregister_meta_key()`, `get_registered_metadata()`, and `registered_meta_key_exists()` no longer return `WP_Error` objects.
* The recently introduced `wp_object_type_exists()` function and the restriction on object type has been removed.
Note: No guarantee of uniqueness is made across object subtypes. Registered meta keys should be uniquely prefixed to avoid conflict.
Fixes#35658.
Built from https://develop.svn.wordpress.org/trunk@38095
git-svn-id: http://core.svn.wordpress.org/trunk@38036 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Don't lower memory limit if the current limit is greater than `WP_MAX_MEMORY_LIMIT`.
* Set `WP_MEMORY_LIMIT` and `WP_MAX_MEMORY_LIMIT` to current limit if the `memory_limit` setting can't be changed at runtime.
* Use `wp_convert_hr_to_bytes()` when parsing the value of the `memory_limit` setting because it can be a shorthand or an integer value.
* Introduce `wp_raise_memory_limit( $context )` to raise the PHP memory limit for memory intensive processes. This DRYs up some logic and includes the existing `admin_memory_limit` and `image_memory_limit` filters. The function can also be used for custom contexts, the `{$context}_memory_limit` filter allows to customize the limit.
* Introduce `wp_is_ini_value_changeable( $setting )` to determine whether a PHP ini value is changeable at runtime.
* Remove a `function_exists( 'memory_get_usage' )` check. Since PHP 5.2.1 support for memory limit is always enabled.
Related commits: [38011-38013]
Props jrf, A5hleyRich, swissspidy, ocean90.
Fixes#32075.
Built from https://develop.svn.wordpress.org/trunk@38015
git-svn-id: http://core.svn.wordpress.org/trunk@37956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In doing this, non-core object types are no longer forcibly blocked and are instead checked against `wp_object_type_exists()` which has a filterable return value. Still, filter that at your own risk.
props Faison for the initial patch.
see 35658.
Built from https://develop.svn.wordpress.org/trunk@37991
git-svn-id: http://core.svn.wordpress.org/trunk@37932 1a063a9b-81f0-0310-95a4-ce76da25c4cd