[wp-trac] [WordPress Trac] #63731: wp-emoji-release.min.js Requires URL Update

[WordPress Trac]

#63731: wp-emoji-release.min.js Requires URL Update
--------------------------+-------------------------
 Reporter:  isaumya       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Emoji         |     Version:
 Severity:  normal        |  Resolution:  wontfix
 Keywords:  has-patch     |     Focuses:  javascript
--------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Replying to [comment:9 isaumya]:
 > Hi @peterwilsoncc, I'm sorry but I do not agree with you. As per my
 understanding (corrent me if I am wrong), WP Core gives users both
 options:
 > 1. Load the emojis via `s.w.org` (Default)
 > 2. Load the emojis via `cdn.jsdelivr.net` (Fallback in case any user
 does not want to use the `s.w.org`)
 >
 > Regardless of plugins, as a WP user anyone can choose to not use
 `s.w.org` in which case the fallback URL gets active.

 I'm sorry, but it is indeed a misunderstanding.

 WordPress does not provide an option for users to choose the fallback URL.
 WordPress will always use s.w.org.

 WordPress does provide filters to allow developers to filter the URLs,
 using the filters `emoji_url` and `emoji_svg_url`. However, these filters
 must:

 a) return a string
 b) return the fill path to the PNG file and SVG files respectively.

 You can see an example of [https://github.com/peterwilsoncc/local-
 twemoji/blob/6a0a87f337dd6ce0d52f3fd22c658c497498c833/inc/namespace.php#L19-L48
 the correct use of these filters] in a plugin I maintain.

 The code example provided by @siliconforks in the comment above is the
 correct way to use `cdn.jsdelivr.net`, as seen in
 [https://github.com/fairpm/fair-
 plugin/blob/fede6b64132e18344e0046d4a540428b0baa9684/inc/assets/namespace.php#L10-L49
 this code example].

 If a plugin developer doesn't follow these requirements, then yes, the
 emoji images will produce a 404 error and there is nothing WordPress can
 do about it. Returning `false` on these filters is incorrect.

 I am going to reclose this ticket as wontfix for the reason stated
 earlier: attempting to defend against plugins introducing bugs to this
 code will lead to more problems than it will solve.

 Discussion can continue on closed tickets.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63731#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform