[38179] added support for the rainbow flag to core, but platform compatibility is a bit strange, because the flag was defined out of sync with the usual Unicode release cycle. For example Android N supports all Unicode 9.0 emoji, but doesn't support the rainbow flag thus the rainbow flag isn't rendered.
The Twemoji loader already has an exception for flags - it'll load if the browser supports everything but flags, and then only replace flag emoji, leaving everything else as native rendering. To provide a seamless experience for all flags the loader now uses the rainbow flag to test flag support.
Props pento.
See #37543.
Fixes#37566.
Built from https://develop.svn.wordpress.org/trunk@38194
git-svn-id: http://core.svn.wordpress.org/trunk@38135 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This includes a new test in the emoji loader, to see if the browser supports rendering Unicode 9.0 emoji, as well as an update to `twemoji.js`, to load Unicode 9.0 twemoji images.
The default CDN location for loading Twemoji images has changed, moving to a versioned subdirectory. This allows updates without needing to purge the CDN.
Fixes#37361.
Built from https://develop.svn.wordpress.org/trunk@38087
git-svn-id: http://core.svn.wordpress.org/trunk@38028 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Custom permalink structures require at least one valid structure tag, e.g. `%postname%`. If none is included, it would leave users with broken permalinks.
Let's make sure this won't happen by validating the permalink structure.
Adds unit tests.
Props rockwell15 for initial patch.
Fixes#35936.
Built from https://develop.svn.wordpress.org/trunk@37747
git-svn-id: http://core.svn.wordpress.org/trunk@37712 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Covers:
* Currency signs
* Decompositions for Latin-1 Supplement
* Decompositions for Latin Extended-A
* Decompositions for Latin Extended-B
* Vowels with diacritic (Chinese, Hanyu Pinyin)
* Characters replaced for the `de_DE`, `de_DE_formal`, and `da_DK` locales
Props john_schlick for the initial work.
Props DrewAPicture, ocean90.
See #34677.
Built from https://develop.svn.wordpress.org/trunk@37669
git-svn-id: http://core.svn.wordpress.org/trunk@37635 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also use 'back-compat' in some inline comments where backward compatibility is the subject and shorthand feels more natural.
Note: 'backwards compatibility/compatibile' can also be considered correct, though it's primary seen in regular use in British English.
Props ocean90.
Fixes#36835.
Built from https://develop.svn.wordpress.org/trunk@37431
git-svn-id: http://core.svn.wordpress.org/trunk@37397 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[37028] missed some logic to capture the base emoji skin tone, to compare to the modified emoji skin tone. This caused all browsers to report that they supported skin tone modifiers, regardless of whether they actually did.
Fixes#36604 for trunk.
Built from https://develop.svn.wordpress.org/trunk@37256
git-svn-id: http://core.svn.wordpress.org/trunk@37222 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When the browser test for diversity emoji was added in [36160], it included a workaround for Chrome not being able to compare `Uint8ClampedArray` objects directly, by converting them to a string. Unfortunately, Safari doesn't support the `Uint8ClampedArray.toString()` method correctly, so the test was incorrectly failing in Safari.
Fixes#36266 for trunk.
Built from https://develop.svn.wordpress.org/trunk@37028
git-svn-id: http://core.svn.wordpress.org/trunk@36995 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As new sets of emoji are added to Unicode, and browsers add support for them at random intervals, we'll inevitably need to add new tests to the emoji loader. This change makes it much easier to add new tests as they're needed.
Fixes#35300.
Built from https://develop.svn.wordpress.org/trunk@36816
git-svn-id: http://core.svn.wordpress.org/trunk@36783 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[35709] was overly broad, and stopped transforming `&` characters within tag attributes. So that sites aren't generating invalid HTML, we need to restore this functionality, while continuing to not transform `&` within blocked tags.
Fixes#35008 for trunk.
Built from https://develop.svn.wordpress.org/trunk@36036
git-svn-id: http://core.svn.wordpress.org/trunk@36001 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Twelve years later, after no fewer than three themes have intentionally implemented popup comments in their functionality, before being abandoned for at least the last six years, we've reached a time where we can put this era behind us. A time when we can remove comment popup functionality from WordPress.
If this breaks the internet, I'll eat my hat.
Fixes#28617
Built from https://develop.svn.wordpress.org/trunk@35848
git-svn-id: http://core.svn.wordpress.org/trunk@35812 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The whole string is escaped with `esc_html()` anyway, so we don't
need to `wp_kses_post()`. This is a better experience for users who
want to use angle brackets in their site title or description.
Does not allow any HTML, adds unit tests.
props BandonRandon, pauldewouters.
fixes#27942.
Built from https://develop.svn.wordpress.org/trunk@35788
git-svn-id: http://core.svn.wordpress.org/trunk@35752 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, `&` would be converted everywhere, which caused problems when it was converted within a `<script>`, for example.
`convert_chars()` is now removed from the `the_content` filter, as it was doing the same job as `wptexturize()`.
KSES correctly handles converting `&` within HTML attributes, so there's no need for `wptexturize()` and `convert_chars()` to do the same job.
Fixes#34698.
Built from https://develop.svn.wordpress.org/trunk@35709
git-svn-id: http://core.svn.wordpress.org/trunk@35673 1a063a9b-81f0-0310-95a4-ce76da25c4cd
