[wp-trac] [WordPress Trac] #42264: Systematic way of dealing with compat code and polyfills

WordPress Trac noreply at wordpress.org
Wed Mar 28 20:30:40 UTC 2018


#42264: Systematic way of dealing with compat code and polyfills
----------------------------+------------------------------
 Reporter:  schlessera      |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Bootstrap/Load  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by jrf):

 @schlessera I've been thinking about this a little more and while I
 support the basic premise of this proposal - splitting out the back-compat
 functionality into several files which are selectively loaded -, I don't
 think the currently proposed logic would work.

 A significant number of the back-fills are related to PHP extensions - in
 contrast to the PHP Core -.
 Depending on the PHP version, certain extensions ship with PHP by default.
 However, this is no guarantee that those extensions will actually be
 available in that PHP version or not available in versions where the
 extension was not (yet) included by default.

 - Webhosts, or any PHP installer for that matter, do not have to use the
 default distribution.
 - Some webhosts backport security fixes to old PHP versions and at times,
 these fixes may contain functionality which has been backfilled.
 - A custom PHP compilation using PECL extensions may be used.
 - etc etc

 So the fact that WP is running on a system running PHP 7.2, is no
 guarantee that the `Sodium` extension is available, PHP 5.x is no
 guarantee that `bcmath` is available (shipped with PHP since 4.0.4), and
 running PHP 7.0 is no guarantee that `Sodium` will *not* be available.

 Over the last x years I've been amazed (and frustrated) more times than I
 can count by bug reports for plugins where it turned out that a non-
 default PHP install missing some essential extension was the underlying
 cause of the issue.

 So, having said that, I think a more extension based approach is needed
 here using `extension_loaded()` to check whether, for instance, the back-
 fills related to `MBString` need to be loaded or not.

 Presuming all back-fill related files will live in a `wp-
 includes/phpcompat` directory, I imagine the loading mechanism could be
 something along the lines of (pseudo-code, untested, just to demonstrate
 the idea):
 {{{#!php
 <?php
 $php_backfills = array(
         'CSPRNG',
         'MbString',
         'Sodium',
         'Curl',
 );

 require_once 'wp-includes/phpcompat/core-functions-and-constants.php';

 foreach ( $php_backfills as $extension ) {
         if ( extension_loaded( $extension ) === false ) {
                 require_once 'wp-includes/phpcompat/' . $extension .
 '.php';
         }
 }
 }}}


 Where necessary, this could be enhanced with a call to `phpversion(
 $extension )` to check that the extension complies with a minimum required
 version of that extension.

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


More information about the wp-trac mailing list