[wp-trac] [WordPress Trac] #23912: Add Composer package description

[WordPress Trac]

#23912: Add Composer package description
-------------------------+-----------------------------
 Reporter:  Rarst        |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Build Tools  |     Version:  3.5
 Severity:  trivial      |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by TJNowell):

 > It's obvious that using this `wordpress-core` type makes it possible to
 do
  > things we couldn't before, but this isn't a question of what's
 possible,
  > it's a question of what's appropriate.

 In which case it's just as appropriate as using git submodules and
 externals. Also keep in mind that clients can demand these kinds of
 installs, and there are real advantages to putting WP Core in its own
 folder.

  > It's about using a properly
  > designed architecture both for current use and for keeping future
  > compatibility in mind in case WordPress ever makes the decision to
  > redesign it's architecture in a way that's more "composer compatible"
 like
  > many other projects have. If we make use of a custom `type` and/or a
  > dependency on a custom installer, we're burning some of the bridges
 ahead
  > of us that we might want to use in the future (or at the least, making
 it
  > much more difficult to cross them).

 I fail to see how wordpress-core will be an issue. If in future we change
 the composer.json to 'moomin-spectacular', composer will re-arrange things
 as necessary into the vendor folder, at which point all that would be
 needed is an index.php that loads the autoloader and creates the first
 object. We may not change WP Core at all and use classmaps etc Who knows.

 In practice, having WP Core as a composer dependency has not been an
 issue. New versions of WordPress have came along and been updated and
 installed accordingly.

  > Right now, WordPress doesn't even support upgrading WordPress from
  > Composer any more than it supports upgrading from VCS.

 Actually that's not true. I can say that I need WordPress in my sites
 composer, specifically stable WordPress, and only the 3.8.x branch. I can
 specify that I want an exact version, or that I want developer builds, and
 I can say in my plugins that they need a specific version of WordPress,
 and composer will handle all of this. Git submodules do not. SVN Externals
 do not.

  > It doesn't perform
  > the same safety and security checks it doesn't perform any DB
 migrations
  > (and yes, I understand these will just happen on the next wp-admin
 request
  > after an admin has been asked to),

 It's not intended for DB migrations. Neither are Git and SVN, or
 Zip/tarballs on the download page. This is a strawman.

  > it doesn't call any plugin or theme
  > hooks designed to be triggered by core (or plugin and theme) updates,
 and
  > it doesn't flush any caches that should be flushed.

 Neither do svn/git updates, FTP'ing plugins manually, rsync, or extracting
 zip archives over the top of the filesystem.

 The difference here is that composer has a scripts section that can load a
 WordPress environment and do the necessary work. As a user of Johns
 composer installer, this has never been an issue, and I would be
 suspicious of any plugin that breaks as a result of this, however unlikely
 that is. Even then, a composer.json of that plugin can be set to execute
 necessary cleanup and upgrade scripts.

  > It's not calling any
  > core upgrader methods. It's hopefully true that most developers
 understand
  > this when they manage WP updates from a VCS, and perform those tasks
  > manually, but I want to stress that we should avoid giving users the
  > impression that they can use Composer to manage upgrades for them just
 as
  > reliably as using the built-in upgrader since offering Composer support
  > opens that user base significantly to non-developers, who aren't using
  > VCS, but are being exposed to those same developer-related limitations
 and
  > problems.

 So your argument is that by adding a file to enable the use of a
 developer-centric command line tool, we're opening ourselves up to a
 significant userbase of non-developers.

 Composer managed WordPress installs are proven to work and deployed on
 live websites, and it's likely a developer choosing to use composer knows
 a great deal more about WordPress and PHP environments than a user who
 clicked on an install button on a shared host, who doesn't know what PHP
 is, nevermind a PHP CLI tool.

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