[wp-trac] [WordPress Trac] #40934: Allow PHP version requirements for plugins & themes

WordPress Trac noreply at wordpress.org
Wed Jun 7 02:59:07 UTC 2017

#40934: Allow PHP version requirements for plugins & themes
 Reporter:  joostdevalk     |       Owner:  joostdevalk
     Type:  enhancement     |      Status:  assigned
 Priority:  normal          |   Milestone:  4.9
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  dev-feedback    |     Focuses:
Changes (by blobfolio):

 * type:  task (blessed) => enhancement
 * focuses:  ui, administration =>
 * component:  Plugins => Administration


 I, for one, am not comfortable supporting versions of PHP that have
 reached End of Life. If software dependencies aren't receiving security
 patches, the software running on top of it isn't safe either. I do it, but
 only because WordPress provides no safe mechanism for allowing its hosted
 plugins to advance (in the way that virtually all other software is able

 In a word, "security". PHP 5.2 was released ''more than 10 years ago''. In
 tech years, that's older than most religions. The security problems
 technologies released a decade ago were built to defend against are
 laughable today. WordPress still supports single MD5 password hashes.

 And I get that there's an opposing philosophy, "Technology should be
 available to as many people as possible." That isn't wrong, but as a
 plugin author, that is something I like to help augment. "The base
 technology works for everyone, but if you can swing it, this will keep you

 As-is, the WordPress plugin ecosystem is dangerous. WordPress has no
 ability to resolve conflicts prior to executing the full install/upgrade
 routines, takes no pre/post snapshots, maintains no history, gives users
 no innate ability to manage version control. Each update is a game of
 Russian Roulette, particularly for casual blog authors who aren't familiar
 with the underlying tech and don't realize that their servers are at best


 I recently came to a difficult decision for one of my plugins upon
 discovering certain innate security limitations in the minimum
 requirements I had set forth years earlier (long since resolved by
 subsequent PHP releases). My choice was to either progressively address
 the issue, leaving a subset of users vulnerable, or bump the requirement,
 alienating that same subset of users. I wasn't willing to risk exploding
 their sites, and since WordPress provided no framework (not even a proper
 upgrade hook), here is what I had to do:

 1. Push and tag an intermediate release that A) presents an admin notice
 warning users if their system won't support future releases (and, btw, it
 is not safe to keep using this... update or find an alternative) and B)
 suppresses update notifications in such cases. I released this before work
 began on the rewrite, a good month ahead of time, but couldn't rely on
 users actually installing it (very few people apply regular updates),

 2. Release a new version that includes a red pill/blue pill index file,
 either loading the real plugin code a fallback. The fallback version
 produces a notice and either A) deactivates the plugin (if a new install)
 or B) hijacks the upgrade feature to turn it into a ''downgrade'' feature
 (using an artificially inflated version number and a link to the tagged
 legacy release). The fallback also has to supply semi-functional userspace
 functions so that themes referencing them wouldn't explode, but since the
 relevant codebase isn't loaded, these instead submit notices via email to
 the site administrator alerting them to the problem, just in case they
 didn't see the wp-admin notices.

 It ended up being an insane hoop, and very difficult to adequately test.
 At the time I thought, "Boy, wouldn't it be swell if WP had basic
 PHP/extension requirements baked into the API?" Haha.

Ticket URL: <https://core.trac.wordpress.org/ticket/40934#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list