[wp-trac] [WordPress Trac] #57575: Editor: Introduce HTML Tag Processor

[WordPress Trac]

#57575: Editor: Introduce HTML Tag Processor
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  6.2
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests gutenberg-  |     Focuses:
  merge                                          |
-------------------------------------------------+-------------------------

Comment (by hellofromTonya):

 Replying to [comment:8 dmsnell]:
 > Pardon me for my ignorance, but why would we want to remove the safety
 these checks provide? Based on the existing codebase I was under the
 impression this practice is somewhat normative and important, having also
 seen cases where people unintentionally pulled in class files with
 `require` that were already there, and thus created crashes where they
 weren't needed.
 >
 > This is why I preferred wrapping each class in the check, but given that
 the linter wants to indent the entire file, I moved them to `wp-html.php`
 as a compromise.
 >
 > If a version in Gutenberg were to somehow load first I wouldn't see that
 as problematic. We aren't wanting to break the API in the future.

 Good questions. Here are the reasonings:

 1. Core loads first before plugins and themes.
 2. Files are loaded very very early in the request cycle. These are
 grouped in `wp-settings.php`.
 3. WordPress Core's code is native to itself. The expectation is that Core
 does not need to guard its own functions, traits, classes, etc. from
 custom code that may also use the same custom naming conventions. Notice
 in Core, it does not wrap each class or function in a `*_exists()` before
 loading it into memory. That's on purpose. Why? Because the expectations
 are:
    * These functions, classes, etc. are native to WordPress Core.
    * Plugins and themes are responsible to guard any of their custom code
 that duplicates a native Core function, class, etc. to prevent a fatal
 error.

 Since Core loads these files before plugins or themes, the `*_exists()`
 wrappers are unnecessary. Why?
 * Core loads first so there should not be a duplicate name already loaded
 into memory.
 * Core's code is native to Core. See the expectation explanation above in
 reason 3.

 Take a look at the REST, Sitemaps, and other APIs within Core. Notice they
 are not wrapped in `*_exists()`. Take a look at all of the functions in
 Core. Notice they are not wrapped in `function_exists()`.

 Does that help @dmsnell?
 Is there a compelling reason why the HTML API files are at risk whereas
 the other native Core functions, classes, etc. are not?

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