[wp-trac] [WordPress Trac] #60491: Fix handling of plugins with unmet requirements

[WordPress Trac]

#60491: Fix handling of plugins with unmet requirements
--------------------------+-----------------------------
 Reporter:  azaozz        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Plugins       |     Version:  5.1
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------------

Comment (by azaozz):

 > what if WP was deciding when to initialize a plugin

 Thinking this is (probably) the best way forward for supporting all plugin
 requirements, current and future.

 To be able to do this WP will need access to the plugin's meta (the
 headers) before it can decide to load/initialize the plugin or not. Seems
 there are two more or less straightforward ways to accomplish this:

 1. Store all of the plugin's meta in the DB, and update it when installing
 or updating a plugin (and maybe when activating to catch cases where a
 plugin was installed from FTP).

 Advantages: Getting the plugins meta from the DB (or from persistent
 cache) will be super fast compared to "reading" the plugin's headers every
 time. Also this method will not need any changes to how plugin meta is
 currently stored in the plugin's main file (plugins headers).

 Disadvantages: Edge case when updating an activated plugin outside of WP,
 through FTP or git/svn. That will bypass updating of the stored plugin
 meta and possibly result in loading a plugin with unmet requirements (like
 the case described above). Seems it's possible to solve this by storing
 the "last modified" time for the plugin's main file together with the
 plugin's meta, and check it every time to detect updates. As far as I see
 doing `filemtime()` for about 30-40 files will not introduce a noticeable
 delay. On my test site these are super fast, take few nanoseconds per
 file.

 2. Introduce a new way to store the plugin's meta in the main plugin file.
 Seems an associative array would work well. This can be in addition to the
 current headers or instead of them. Something like:

 {{{
 $plugin_meta = array(
     plugin_name       => 'My plugin',
     requires_at_least => '6.3',
     requires_PHP      => '8.0',
     version           => '1.2.345',
     init_callback     => 'my_plugin_init',
 );
 }}}

 (Note the new `init_callback` meta key.)

 Then when WP is loading the main plugin file, it can do something like:

 {{{
 $plugin_meta = null;

 foreach ( $plugins as $plugin ) {
     if ( is_array( $plugin_meta ) ) {
         if (
             // Check PHP version requirement if set
             // Check WP version requirement if set
             // Check for plugin dependencies if set
             // Check any other (new) requirements if set
          ) {
             if ( is_callable( $plugin_meta['init_callback'] ) ) {
                 call_user_func( plugin_meta['init_callback'] );
             } else {
                 // Throw error depending on WP_Dev constants
             }
         } else {
             // Show a "plugin requirements not met" error/warning.
             // The error should also explain that the plugin has been
 disabled
             // until the problem is resolved.
             // (Note that the plugin is still activated at this point
             // but WP is not loading/initializing it)
         }
     } else {
         // Load the plugin the old way (existing code)
     }

     $plugin_meta = null; // The meta array needs to be reset for the next
 plugin
 }
 }}}

 Advantages: Fast and easy way to access the plugin's meta before
 initializing the plugin. This solves the edge case when an activated
 plugin is updated outside of WP, through FTP or git/svn.

 Disadvantage: Requires the new `$plugin_meta` var to be defined in the
 main plugin file.

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