WordPress no longer supports many old old browsers: https://make.wordpress.org/core/2017/04/23/target-browser-coverage/
This also removes alot of no longer necessary CSS. It served us well, but we are never getting back together with IE8,9,10.
So, in the (paraphrased) words of Taylor Swift:
I remember when we dropped support the first time
Saying, "This is it, I've had enough, " 'cause like
We hadn't seen many users in a month
When you said you needed flexbox. (What?)
Then you postMessage again and say
"IE8, I miss you and I swear I'm gonna change, trust me."
Remember how that lasted for a day?
I say, "I hate the box model, " we break up, you call me, "I love css-grids."
Ooh, we called it off again last night
But ooh, this time I'm telling you, I'm telling you
We are never ever ever supporting IE 8,9,10,
We are never ever ever supporting IE 8,9,10,
You go talk to EDGE, talk to my FIREFOX, talk to CHROME
But we are never ever ever ever getting back together
Like, ever...
Fixes#37651.
Props stunnedbeast, netweb, jorbin.
Built from https://develop.svn.wordpress.org/trunk@41062
git-svn-id: http://core.svn.wordpress.org/trunk@40912 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Before this changeset, the language of a new site would always result in the language of the current network, regardless of the `$site_id` parameter passed that actually determines the network for the site. Now the correct `WPLANG` value is used in such cases.
Alongside this change, a few minor documentation changes around the function have been made to account for the current naming conventions of sites and networks.
Props spacedmonkey.
Fixes#40503.
Built from https://develop.svn.wordpress.org/trunk@41058
git-svn-id: http://core.svn.wordpress.org/trunk@40908 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The Text widget in legacy mode omits TinyMCE and retains old behavior for matching pre-existing Text widgets. Usage pointers added to default visual mode appear when attempting to paste HTML code into the Visual tab and when clicking on the Text tab, informing users of the new Custom HTML widget.
Props westonruter, melchoyce, gitlost for testing, obenland for testing, dougal for testing, afercia for testing.
See #35243.
Fixes#40951.
Built from https://develop.svn.wordpress.org/trunk@41050
git-svn-id: http://core.svn.wordpress.org/trunk@40900 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, these filters were being run once per post, but the changes in [41043] caused them to be run once per emoji found.
We will not stand idly by while this kind of unfair performance penalty is placed on the emoji literate. The filters are now run once only, emoji aficionados everywhere can rest easy, knowing their posts will be just as performant as their emoji-less cousins.
Props ocean90 for noticing this severe oversight.
See #35293.
Built from https://develop.svn.wordpress.org/trunk@41046
git-svn-id: http://core.svn.wordpress.org/trunk@40896 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, `wp_encode_emoji()` and `wp_staticize_emoji()` used inaccurate regular expressions to find emoji, and transform then into HTML entities or `<img>`s, respectively. This would result in emoji not being correctly transformed, or occasionally, non-emoji being incorrectly transformed.
This commit adds a new `grunt` task - `grunt precommit:emoji`. It finds the regex in `twemoji.js`, transforms it into a PHP-friendly version, and adds it to `formatting.php`. This task is also automatically run by `grunt precommit`, when it detects that `twemoji.js` has changed.
The new regex requires features introduced in PCRE 8.32, which was introduced in PHP 5.4.14, though it was also backported to later releases of the PHP 5.3 series. For versions of PHP that don't support this, it will fall back to an updated version of the loose-matching regex.
For short posts, the performance difference between the old and new regex is negligible. As the posts get longer, however, the new method is exponentially faster.
Fixes#35293.
Built from https://develop.svn.wordpress.org/trunk@41043
git-svn-id: http://core.svn.wordpress.org/trunk@40893 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[40514] introduced a bug that caused term queries to return some duplicates
when the `$taxonomies` array contained only taxonomies that were originally
registered with an `$args` array. We fix this bug by ensuring that
recursive `get_terms()` queries stop when all queried `$taxonomies` have
already been referenced.
Props bor0, atanasangelovdev.
Fixes#41010.
Built from https://develop.svn.wordpress.org/trunk@41037
git-svn-id: http://core.svn.wordpress.org/trunk@40887 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Set view state properly when navigating history using the browser back/next button in the media library (grid view). Correctly handle navigating, search, image detail view and image edit mode. Also handle bookmarking/reloading.
Props kucrut, joemcgill, afercia.
Fixes#31846.
Built from https://develop.svn.wordpress.org/trunk@41021
git-svn-id: http://core.svn.wordpress.org/trunk@40871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change standardizes some language in the parameter descriptions between the two hook docs in an effort to reduce confusion between the `$pre_option` pseudo-parameters and the new `$default` ones. `$pre_option` is the truthy value used to short-circuit the `get_*option()` call, `$default` is the value passed to the `get_*option()` returned in the event that 1) a short circuit isn't performed, 2) the option doesn't exist.
Props sc0ttkclark.
Fixes#41254.
Built from https://develop.svn.wordpress.org/trunk@41013
git-svn-id: http://core.svn.wordpress.org/trunk@40863 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, changing these constants in `wp-tests-config` would cause PHPUnit to regenerate `wp-api-generated.js` with different values.
This commit uses the existing mechanism to also "freeze" all values that would change as a result of changing these constants.
Fixes#41123.
Built from https://develop.svn.wordpress.org/trunk@41006
git-svn-id: http://core.svn.wordpress.org/trunk@40856 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, checks like `current_user_can( 'edit_term_meta', $term_id )`
returned the proper value, but generated a PHP notice due to the fact
that `get_term( $term_id )` could, in certain instances, return
`WP_Error` objects.
Props caercam.
Fixes#40891.
Built from https://develop.svn.wordpress.org/trunk@40999
git-svn-id: http://core.svn.wordpress.org/trunk@40849 1a063a9b-81f0-0310-95a4-ce76da25c4cd