Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#37306 closed feature request (wontfix)

WordPress doesn't support PHAR plugins

Reported by: 7he0 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.6
Component: Plugins Keywords: 2nd-opinion
Focuses: Cc:


When uploading a plugin in the phar format, the plugin related functions don't pick it up, and don't allow the admins to activate it. If the plugin is renamed to end with .php on the server, then it works.

Attachments (1)

0001-Plugins-Add-support-for-the-phar-format.patch (3.3 KB) - added by 7he0 4 years ago.

Download all attachments as: .zip

Change History (6)

#1 @7he0
4 years ago

Attached the patch for the requested feature.

#2 @SergeyBiryukov
4 years ago

  • Summary changed from Wordpress doesn't support PHAR plugins to WordPress doesn't support PHAR plugins

#3 @dd32
4 years ago

  • Keywords 2nd-opinion added

Before considering this, I'd like to pose one question:

Why? What benefit does it bring to an end user?

Some benefits of Phar archives such as multiple files are already taken care of by ZIP files used for WordPress plugins, and by using phar archives it may hide or limit a users ability to modify a plugin (as they'd have to extract it, and/or replace the files within it, which is not super easy for some users)

#4 @7he0
4 years ago

First and foremost, this feature/patch doesn't restrict anything, it allows people to distribute/use1 phar plugins only if they wish.

But I will answer this question in two folds:

  • Why do we want to support a file format that PHP supports: for completeness. If PHP supports a file format, it's regardless of the file extension. Therefore, a PHAR plugin can already be used, by simply renaming it with a .php extension. So the absence of this patch isn't limiting the developers in not distributing phar plugins; they can hack their way through. This patch only makes it clearer, cleaner, that the plugin is in the PHAR format.
  • Why do we want to support PHAR specifically: PHAR files are archives, and they are meant to stay that way on disk (i.e. not extracted). While the disk space it saves might be anecdotal for most2; it does, as you also remarked, prevent the end user from modifying a plugin. I can think of a few cases where this is desired (security related plugins, popular plugins, etc.), but mostly: a plugin shouldn't rely on being modified. Wordpress provides several facilities to manage dynamic data (store/retrieve) out of its own database/tables (or custom ones if desired), and files can also be used for that matter via PHP's functions.

So packaging plugins3 in PHAR can provide all the advantages of software packaging:

  • signatures (phar archives can be signed and therefore are more secure)
  • checksums
  • Embedded (different) CLI application (that behaves differently for the web and the CLI, therefore allowing privileged access via the CLI, for intance)
  • Single package - file equivalence: no risk of breaking it by tempering with its insides.
  • Package sealing: Enforce version consistency, there is no way to replace only part of the plugin with a different version.

Of course all of this is already implemented in PHP, so there is no need for wordpress to implement any of this to get the benefits of it (although, if you wish to display the phar signature in the admin panel rather than have people perform the checking manually with php, it might be needed to implement something in that regard).


1 in a clean way - it is already possible in a hackish way, as explained after in the text.
2 but will be welcomed with some hosters, since it can be a scarce resource sometimes.
3 I am aware that the zip format is already a package in that sense; but it doesn't support any of the features that are listed after.

#5 @DrewAPicture
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This ticket sitting idle for a year notwithstanding, there doesn't seem to be a great deal of demand for phar support.

And in lieu of demonstrated demand, I'm not sure the arguments presented here are enough of a justification to consider support for it. Closing as wontfix.

Note: See TracTickets for help on using tickets.