at wordpress.stackexchange.com Giuseppe Mazzapica Biggest German WordPress Agency WordPress.com Featured Service Partner Gold Certified WooCommerce Expert https://gmazzap.me @gmazzap github.com/gmazzap
to Composer. What, why, how. 20 min Hands-on 1: Your first Composer package 15 min Presentation Part 2: Composer and WordPress. The basics. 10 min Hands-on 2: Add Composer support to a plugin. 10 min Presentation Part 3: Composer and WordPress. Whole-site stacks. 5 min Hands-on 3: Write a whole-site Composer project for WordPress 20 min
use code in different projects? Copy and paste is not viable Git submodules are «unfriendly» and have issues ...and what about conflicts and incompatibilies? ...not to mention shareability and repeatability...
project «dependency graph», taking care of «building» the project in affordable, shareable, and repeatable way preventing conflicts and incompatibilities. And that’s not all: It provides a convenient autoloader It provides scripting utilities It is written in PHP for PHP It is the de-facto industry standard
as a directory has a , that directory composer.json is a package. Every project has «versions» and might have «dependencies», which are other packages. When a projects requires another package, there’s a «link» between them. The link is made of a source package, a target package, and a version constraint.
by the at the root of the project. composer.json It is the main that defines the project composer.json requirements. Certain package properties are relevant when in the root package context. Every package can be used as root package, or as a dependency of other packages.
of cases packages are managed using a version control system like git, svn, hg or fossil. A «tag» in VCS is considered a stable version in Composer, a «branch» in VCS is considered a development version of the package. Composer infers packages version from VCS systems (even if there are way to set version manually).
is 1.0.* actually more specifically a version constraint. A link between two packages is created in Composer by adding in a package a pointer to another composer.json package that looks like: Composer Concepts: Versions and Constraints and Links some-vendor/some-package": "1.0.*"
target package that the source package want to link to. Composer Concepts: Versions, Constraints and Links Composer supports different ways to define constraint: Exact version 1.0.15 Version range >=1.0 >=1.0 <2.0 >=1.0 || >=1.2 Hyphenated Version Range 1.0 - 2.0 Wildcard Version Range 1.0.* 2.* * Caret Version Range ^1.1 Tilde Version Range ~1.1 ~1.2.1
the most common, but there’s also confict, replace, provide, and suggest. On installation/update Composers recursively resolves the the constraints of all the links declared by all the packages. Only if a set of packages that satisfies all constraints is found Composer proceeds by pulling packages. To pull packages, Composer needs to know where and how, and these information are provided by packages repositories. Composer Concepts: Versions, Constraints and Links
package, the repository holds: the name (which usually is in the form vendor/name) the type (the most common and default is «library») a list of available versions, and for each version: an URL of the dist (which is in archive form) an URL of the source (which is the SVN URI) It is not required for repositories to hold both the dist and the source URL for packages, but one of them is required.
most common is the repository of type «composer». It takes the form of an URL to a packages.json file, which contains an array of packages information in JSON format. packagist.org is a repository of this type, it is the only repository that Composer uses by default. It is open and free for anyone to register packages which must be publicly accessible via a service like GitHub, BitBucket or GitLab.
Allows to use a VCS repository as Composer repository for a package. Useful for packages not available on packagist.org, or to use a fork of a package. Package Allows to define package informations manually. Useful for libraries that does not support Composer (don’t have a ). composer.json PEAR For packages available in any PEAR channel.
The package path is symlinked, so any edit on the source affects the requiring package withou the need of any update. Useful for development. Artifact A repository that consist in a local folder that contains any number of zip archives, each containing a package (with composer.json in the root folder). Composer Concepts: Repositories Other kind of repositories supported are:
conflict replace provide suggest Package links name description type license authors version Metadata autoload autoload-dev* minimum-stability* prefer-stable* Autoload Stability
dump-autoload Must know Useful Others search show check-platform-reqs browse suggests status licenses exec diagnose archive global config validate help run-script outdated why why-not
which will print «developer quotes» from the command line. What you need: a local environment with: recent version of Composer git client an active internet connection 15min
All its dependencies are embedded in source code. Composer can however be used to install core: declaring as custom package using a custom repository that points to its source URL via unofficial packages like johnpbloch/wordpress-core
can be written with Composer support. «Composer Installers», an official Composer project, provides support for plugin and themes. The lack of core support bring many issues for users who want to use Composer; the most relevant are: the needs to often ship folder vendor the possibility of dependencies version conflicts
Composer support if publicly accessible on GitHub, BitBucket or Gitlab, can be added to packagist.org and installed via Composer. However, to make them available on official wp.org repository, they need to contain all the code of dependencies (the folder) which means the same library could be vendor added multiple times by different plugins. Which also means isses of version conflict among different versions of same library might arise.
plugin that uses a 3rd party library can be edit to support Composer. This will be more a sort of «mob programming» where all attendees collaborates in editing the plugin, but the actual coding with be done on the presenter machine. 10min What you need: don’t forget to bring your brain
way to let Composer do its job, and avoid conflicts and other issues is to use it to manage the dependency graph of all the website, having a single vendor folder for all the dependencies. For plugins and themes be compatible with this approach a little extra care is required in the development.
Composer support of core caused the proliferation of various 3rd party, unofficial services and libraries which are commonly used to ease the WordPress-Composer integration. Worth a mention: wpackagist.org wp-languages.github.io roots.io/bedrock wecodemore.github.io/wpstarter
Composer project to manage a whole site, including core, plugins and themes. What you need: a local environment with: recent version of Composer git client an active internet connection 20min a webserver to test the site on the browser
gmazzap
maaretp
goyoki
konokenj
manfredsteyer
happymana
fukubaka0825
qnighy
notfounds
murabayashi
kakao
thehaigo
hollycummins
bkeepers
panda_program
irinanazarova
tammyeverts
eileencodes
nonsquared
malarkey
speakerdeck
kneath
carmenintech
reverentgeek
