[wp-trac] [WordPress Trac] #59547: Rename WP_HTML_Processor::createFragment() to follow the coding standards

[WordPress Trac]

#59547: Rename WP_HTML_Processor::createFragment() to follow the coding standards
------------------------------+-----------------------
 Reporter:  SergeyBiryukov    |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  6.4
Component:  HTML API          |    Version:  trunk
 Severity:  normal            |   Keywords:  has-patch
  Focuses:  coding-standards  |
------------------------------+-----------------------
 As per the [https://developer.wordpress.org/coding-standards/wordpress-
 coding-standards/php/#naming-conventions Naming Conventions] section:

 > Use lowercase letters in variable, action/filter, and function names
 (never camelCase). Separate words via underscores. Don’t abbreviate
 variable names unnecessarily; let the code be unambiguous and self-
 documenting.
 > {{{
 > function some_name( $some_variable ) {}
 > }}}

 `WP_HTML_Processor::createFragment()` appears to be only method in the
 HTML API classes that does not follow the snake_case format.

 Normally, this would display an error in WPCS checks:
 {{{
 ----------------------------------------------------------------------
 FOUND 1 ERROR AFFECTING 1 LINE
 ----------------------------------------------------------------------
  242 | ERROR | Method name "createFragment" in class
      |       | WP_HTML_Processor is not in snake case format, try
      |       | "create_fragment"
      |       |
 (WordPress.NamingConventions.ValidFunctionName.MethodNameInvalid)
 ----------------------------------------------------------------------
 }}}

 However, WPCS — or rather PHPCS — is only aware of the current file, so,
 aside from PHP native classes being extended/interface implemented, WPCS
 cannot check whether the method is one being overloaded from the parent
 class/interface or is one native to the child class. To prevent false
 positives which aren't fixable, WPCS checks if a class extends/implements
 and bows out if it does. This false positive protection has been in place
 since WPCS 0.10.0 (2016).

 Since `WP_HTML_Processor` extends `WP_HTML_Tag_Processor`, WPCS does not
 catch the error in this case, and it should have been caught in code
 review.

 `WP_HTML_Processor::create_fragment()` would be the correct method name to
 match the coding standards.

 Follow-up to [56274].

 Props to @jrf for a clarification on the WPCS behavior.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59547>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform