Composer from Zero to Hero Giuseppe Mazzapica WORKSHOP 

PHP developer since 2005, first met WordPress in 2006. Moderator 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 

What we will do here today: Presentation Part 1: Intro 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 

Introduction to Composer 

Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you. https://getcomposer.org 

Reinventing the wheel is no good. How we can (re) 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... 

Composer provides a simple and declarative way to define the 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 

Composer Concepts: Package Every project is a package. As soon 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. 

Composer Concepts: Package The root package is the package defined 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. 

Composer Concepts: Versions, Constraints and Links In the vast majority 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). 

The part, that's often referred to casually as a version 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.*" 

A version constraint represent a set of versions of the 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 

Composer supports different types of links. require and require-dev are 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 

Composer Concepts: Repositories Repositories are list of packages. For each 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. 

Composer Concepts: Repositories Composer supports different types of repositories. The 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. 

Composer Concepts: Repositories Other kind of repositories supported are: VCS 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. 

Path To pull a single package from a local path. 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: 

composer.json repositories* config* scripts* extra bin archive Others require require-dev* conflict replace provide suggest Package links name description type license authors version Metadata autoload autoload-dev* minimum-stability* prefer-stable* Autoload Stability 

Command Line Interface init install update require remove self-update create-project 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 

Hands-On 1 Your first Composer package 

In this first hands-on we will write a Composer package 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 

Composer & WordPress 

Composer For WordPress: Core WordPress core does not support Composer. 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 

Composer For WordPress: Plugins & Themes WordPress plugin and themes 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 For WordPress: Plugins & Themes Plugin and themes with 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. 

Hands-On 2 Add Composer support to a plugin 

In this second hands-on we will see how a sample 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 

Whole-site WordPress projects with Composer 

Composer For WordPress: The whole website stack The only reliable 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 For WordPress: The whole website stack The lack of 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 

Hands-On 3 A whole-site Composer project 

In this third and last hands-on we will write a 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 

Thanks to for being here. ASK ME ANYTHING