Rejoice, for your admins will feel more native to your surrounding computing environment and likely load faster, especially when offline, as they no longer have to talk to The Google Overlord.
At the time of introduction in 3.8, there were not good system fonts common to all platforms at the time. In the years since, Windows, Android, OS X, iOS, Firefox OS, and various flavors of Linux have all gotten their own (good) system UI fonts.
There will definitely be visual bugs, mainly around alignment and spacing; these should be documented and reported on the ticket and fixed more atomically so that our current and future selves have a better understanding of what happened and why.
The style remains registered, as it is almost certainly in use by themes and plugins.
props mattmiklic.
see #36753.
Built from https://develop.svn.wordpress.org/trunk@37361
git-svn-id: http://core.svn.wordpress.org/trunk@37327 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
Built from https://develop.svn.wordpress.org/trunk@37342
git-svn-id: http://core.svn.wordpress.org/trunk@37308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Unicode 8 added `U+1F644`, "Face with Rolling Eyes", which matches our `:roll:` smiley. Continuing our ever present quest to rid the world of legacy smilies, we now translate that smiley into its emoji form.
Sadly, `:mrgreen:` remains sorely under-represented in the Unicode standard, I'm inclined to think that we should buy a voting membership of the Unicode Consortium, in order to rectify that situation. (Personally, I'm hoping for a green skin tone modifier.)
Fixes#36365.
Built from https://develop.svn.wordpress.org/trunk@37296
git-svn-id: http://core.svn.wordpress.org/trunk@37262 1a063a9b-81f0-0310-95a4-ce76da25c4cd
To improve the performance of `wp_upload_dir()` the result of `wp_mkdir_p()` was stored in a persistent cache, introduced in [36565]. But this becomes an issue when WordPress is scaled horizontally. You may end up caching a value for a server where the directory doesn't exist which will prevent further uploads on other servers because of the persistent cache.
The fix is to use a non-persistent cache.
Props azaozz, ocean90.
See #34359.
Fixes#36621.
Built from https://develop.svn.wordpress.org/trunk@37285
git-svn-id: http://core.svn.wordpress.org/trunk@37251 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Following pattern of `wp_get_mime_types()`, introduce `wp_get_ext_types()` function. New function returns a filtered list of file types with their extensions.
* Use this function in new tests for `wp_ext2type()`.
Props borgesbruno.
Fixes#35987.
Built from https://develop.svn.wordpress.org/trunk@37189
git-svn-id: http://core.svn.wordpress.org/trunk@37155 1a063a9b-81f0-0310-95a4-ce76da25c4cd
An unintended consequence of improving the precommit task is that when it's time to run a release, more tasks need to get run to verify things. This adds a prerelease task to help fix that situation. grunt prerelease should include tasks that verify the code base is ready to be released to the wild and find all the tears on the mausoleum floor and help Blood stain the Colosseum doors.
See #35557
Built from https://develop.svn.wordpress.org/trunk@36930
git-svn-id: http://core.svn.wordpress.org/trunk@36898 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Cache the output in non-persistent cache.
- Cache the result from `wp_mkdir_p()` in persistent cache (when present).
- Introduce `wp_get_upload_dir()` for use when not uploading files. It is equivalent to `wp_upload_dir()` but does not check for the existence or create the upload directory.
- Change tests to use the non-cached `_wp_upload_dir()`. They change options on the fly (should never be used in production) to simulate different environments.
- Introduce `_upload_dir_no_subdir()` and `_upload_dir_https()` to facilitate testing. These use the proper `upload_dir` filter to simulate different environments.
Props kovshenin, azaozz.
See #34359.
Built from https://develop.svn.wordpress.org/trunk@36565
git-svn-id: http://core.svn.wordpress.org/trunk@36532 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Multisite functions use the term "blog" to refer to what we now call a "site," e.g. `get_current_blog_id()`. These functions are here to stay because of our commitment to backwards compatibility. What we can do is set the documentation straight.
See #35417.
Built from https://develop.svn.wordpress.org/trunk@36417
git-svn-id: http://core.svn.wordpress.org/trunk@36384 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The API uses this to do special operations on list responses (used
for collections), so we need to detect whether an array is
associative or numeric-indexed.
After much discussion, the bikeshed is to be painted green and gold.
See #33982.
Built from https://develop.svn.wordpress.org/trunk@34927
git-svn-id: http://core.svn.wordpress.org/trunk@34892 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `_network_option()` parameter order will be changing to accept `$network_id` first. The `_site_option()` functions will remain in use throughout core as our way of retrieving a network option for the current network.
See #28290.
Built from https://develop.svn.wordpress.org/trunk@34912
git-svn-id: http://core.svn.wordpress.org/trunk@34877 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
Built from https://develop.svn.wordpress.org/trunk@34828
git-svn-id: http://core.svn.wordpress.org/trunk@34793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
