[wp-trac] [WordPress Trac] #23912: Add Composer package description
WordPress Trac
noreply at wordpress.org
Mon Jan 20 21:24:07 UTC 2014
#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
More information about the wp-trac
mailing list