8 |
9 | Composer works best with code accompanied by `composer.json` and that is something WordPress core hadn’t adopted yet. There is a bit of tinkering involved to create shim package for core.
10 |
11 | ## Create Custom Package
12 |
13 | Package description follows same rules as `composer.json` file, with addition of version and where to download distribution and/or source from.
14 |
15 | With Composer-aware projects these are usually automagically inferred from combination of `composer.json` and version control. Tags and branches serve as versions, version control itself and APIs for archives (for GitHub and Bitbucket) as downloads.
16 |
17 | For Composer-unaware project the mechanics are much the same, but the downside is that we need to define package for every version individually.
18 |
19 | ### Release Package
20 |
21 | Package for a specific release version of WordPress can be defined like this:
22 |
23 | ```json
24 | {
25 | "type" : "package",
26 | "package": {
27 | "name" : "rarst/wordpress",
28 | "type" : "wordpress-core",
29 | "version": "3.6",
30 | "dist" : {
31 | "url" : "http://wordpress.org/wordpress-3.6.zip",
32 | "type": "zip"
33 | },
34 | "source" : {
35 | "url" : "https://github.com/WordPress/WordPress",
36 | "type" : "git",
37 | "reference": "3.6"
38 | },
39 | "require": {
40 | "johnpbloch/wordpress-core-installer": "~0.1"
41 | }
42 | }
43 | }
44 | ```
45 |
46 | - for name I am declaring it in my own `rarst/*` vendor namespace, so it doesn’t conflict with anything
47 | - `wordpress-core` type and `johnpbloch/wordpress-core-installer` dependency serve to allow clean path customization (otherwise Composer will try to nest core in a vendor directory), see [site stack recipe](/recipe/site-stack) for details
48 | - distribution points to simple direct download from official site
49 | - source points to the release tag at official GitHub mirror, although original Subversion repository would work as well
50 |
51 | ## Require Package in Project
52 |
53 | Now that you have package definition you can drop it into right into `composer.json` of site package, [`repositories : []` field](https://getcomposer.org/doc/04-schema.md#repositories). Easy, but gets bulky fast for multiple versions.
54 |
55 | More organized approach is to [host your own Satis repository](https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md) and have it process packages.
56 |
57 | Then making use of it in project becomes:
58 |
59 | ```json
60 | {
61 | "repositories" : [
62 | {
63 | "type" : "composer",
64 | "url" : "http://rarst.net"
65 | }
66 | ],
67 | "require" : {
68 | "rarst/wordpress" : ">=3.6"
69 | }
70 | }
71 | ```
72 |
73 | This will have Composer look at [rarst.net/packages.json](https://www.rarst.net/packages.json) during install and pick appropriate package version to use.
74 |
75 | ## Documentation Links
76 |
77 | - [package links](https://getcomposer.org/doc/04-schema.md#package-links)
78 | - [package repository](https://getcomposer.org/doc/05-repositories.md#package-2)
--------------------------------------------------------------------------------
/recipe/paths-control.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Paths Control
3 | subtitle: recipe
4 | description: How to use composer/installers to control WordPress theme and plugin paths
5 | ---
6 |
7 | The default type of Composer package is `library`. Composer puts such packages in `vendor/[vendor]/[name]`, which does not fit typical WordPress directory layout well.
8 |
9 | However it is easy adjust it.
10 |
11 | ## Require composer/installers
12 |
13 | [`composer/installers`](https://github.com/composer/installers) is a package of special `composer-installer` type. It catches packages with non-`library` types during installation and (if they match types it supports) adjusts their paths.
14 |
15 | To make use of it your extension's `composer.json` should contain:
16 |
17 | ```json
18 | {
19 | "type" : "wordpress-plugin",
20 | "require" : {
21 | "composer/installers" : "~1.0"
22 | }
23 | }
24 | ```
25 |
26 | Type can also be `wordpress-theme` and `wordpress-muplugin`.
27 |
28 | When used in root [site stack package](/recipe/site-stack) it would make packages go into `wp-content/*` directories as WordPress things usually do.
29 |
30 | ## Customize paths
31 |
32 | If you don't like defaults you can override them in root package (and there only, one of things only root one gets to decide) individually or in bulk:
33 |
34 | ```json
35 | {
36 | "extra" : {
37 | "installer-paths" : {
38 | "content/plugins/{$name}/": ["type:wordpress-plugin"]
39 | }
40 | }
41 | }
42 | ```
43 |
44 | Note that this **only** works for packages that declare `composer/installers` support. You cannot customize paths for generic `library` packages. However you can customize location of `vendor` directory to rename and/or move from default root location:
45 |
46 | ```json
47 | {
48 | "config" : {
49 | "vendor-dir" : "wp-content/vendor"
50 | }
51 | }
52 | ```
53 |
54 | ## Documentation Links
55 |
56 | - [package type](https://getcomposer.org/doc/04-schema.md#type)
57 | - [package links](https://getcomposer.org/doc/04-schema.md#package-links)
58 | - [extra property](https://getcomposer.org/doc/04-schema.md#extra)
59 | - [config property](https://getcomposer.org/doc/04-schema.md#config)
--------------------------------------------------------------------------------
/recipe/site-stack.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Site Stack
3 | subtitle: recipe
4 | description: composer.json example for whole WordPress site Composer stack
5 | ---
6 |
7 | The whole site stack package is end game of using Composer with WordPress.
8 |
9 | ## composer.json
10 |
11 | It would depend on your project what exactly to put in a package and how to configure it.
12 |
13 | For example it can be something like this ([original gist](https://gist.github.com/Rarst/5300767)) :
14 |
15 | ```json
16 | {
17 | "name" : "rarst/install-test",
18 | "description" : "Test project for WordPress stack via Composer",
19 | "authors" : [
20 | {
21 | "name" : "Andrey Savchenko",
22 | "homepage": "https://www.Rarst.net/"
23 | }
24 | ],
25 | "type" : "project",
26 | "repositories": [
27 | {
28 | "type": "composer",
29 | "url" : "https://wpackagist.org"
30 | }
31 | ],
32 | "config" : {
33 | "vendor-dir": "wp-content/vendor"
34 | },
35 | "require" : {
36 | "johnpbloch/wordpress" : ">=4.9",
37 | "rarst/fragment-cache" : "^1.3",
38 | "rarst/update-blocker" : "^1.1"
39 | },
40 | "require-dev" : {
41 | "rarst/laps" : "^1.4.4",
42 | "rarst/toolbar-theme-switcher" : "^1.5",
43 | "wpackagist-plugin/a-fresher-cache" : "*",
44 | "wpackagist-plugin/core-control" : "*",
45 | "wpackagist-plugin/monster-widget" : "*",
46 | "wpackagist-plugin/theme-check" : "*",
47 | "wpackagist-plugin/user-switching" : "*",
48 | "wpackagist-plugin/wcm-user-language-switcher": "*"
49 | },
50 | "extra" : {
51 | "wordpress-install-dir": "wp"
52 | }
53 | }
54 | ```
55 |
56 | ## Breakdown
57 |
58 | - name is within my `rarst/*` vendor namespace
59 | - `type` is set to `project` (rather than default `library`), it is mostly semantic hint that this is root package
60 | - `repositories` declare [WordPress Packagist](https://wpackagist.org/) proxy for Composer access to official WordPress plugin repository
61 | - `vendor` directory is relocated inside `wp-content`
62 | - WordPress core, custom theme and number of plugins are listed as dependencies, part of them as for optional development context
63 | - WordPress [core package](/recipe/core-package) is configured to go into `wp` subdirectory (using custom `wordpress-install-dir` configuration option of core installer, required by core package)
64 |
65 | ## Installation
66 |
67 | ### From Local File
68 |
69 | 1. [Download `composer.json` from gist](https://gist.githubusercontent.com/Rarst/5300767/raw/composer.json) into empty directory
70 | 2. Run `composer install --prefer-dist` in that directory
71 |
72 | ### From Remote Repository
73 |
74 | Run:
75 |
76 | ```bash
77 | composer create-project rarst/install-test wordpress dev-master --repository-url=https://www.rarst.net --prefer-dist
78 | ```
79 |
80 | This will tell Composer to create project:
81 |
82 | - from `rarst/install-test` package
83 | - in `wordpress` directory
84 | - at `dev-master` version
85 | - using custom [`rarst.net/packages.json`](https://www.rarst.net/packages.json) Composer repository
86 | - favor direct downloads of packages over cloning from version control
87 |
88 | ### Result
89 |
90 | After install the project directory will have the following content:
91 |
92 | - `wp` WordPress core
93 | - `wp-content`
94 | - `plugins`
95 | - packages of `wordpress-plugin` type
96 | - `themes`
97 | - packages of `wordpress-theme` type
98 | - `vendor`
99 | - packages of `library` type
100 | - `autoload.php` combined class autoload file for all packages
101 | - `composer.json` project file we ran install for
102 | - `composer.lock` file with exact current state of packages
103 | - `wp-config.php` was not created by this example, but should be placed here
104 |
105 | In one command we have neat and nearly complete subdirectory install! The example package we used only lacks properly set up `wp-config.php` and `index.php` for complete WordPress site.
106 |
107 | ## WordPress configuration
108 |
109 | ### Directories
110 |
111 | Notably we made changes to the default WordPress directory structure, which you might be used to. This enables us to update parts of it separately, without worry that core update erases content packages inside of it.
112 |
113 | This is supported natively by WordPress configuration, see documentation in Codex:
114 |
115 | 1. [Giving WordPress Its Own Directory](https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory) (you likely want Method II with simpler and more robust rewrite setup)
116 | 2. [Moving wp-content folder](https://wordpress.org/support/article/editing-wp-config-php/#moving-wp-content-folder)
117 |
118 | ### Autoload
119 |
120 | Since our whole stack shares single Composer–driven autoload for classes — we need to include it into WordPress boot process.
121 |
122 | There is no native WordPress convention for autoload and in practice `wp-config.php` is most appropriate place to set it up.
123 |
124 | For example it might look like this at the top of `wp-config.php` (created at the root, one level above core subdirectory):
125 |
126 | ```php
127 | require __DIR__ . '/wp-content/vendor/autoload.php';
128 | ```
129 |
130 | ## Documentation Links
131 |
132 | - [package properties](https://getcomposer.org/doc/04-schema.md#properties)
133 | - [`composer install` command](https://getcomposer.org/doc/03-cli.md#install)
134 | - [`composer create-project` command](https://getcomposer.org/doc/03-cli.md#create-project)
135 |
--------------------------------------------------------------------------------
/resources.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Resources
3 | excerpt: Links to resources about Composer and its integration with WordPress
4 | ---
5 |
6 | Compilation of links to online resources about, for, and near Composer.
7 |
8 | ## Documentation
9 |
10 | - [Composer documentation](https://getcomposer.org/doc/)
11 | - Composer [GitHub project](https://github.com/composer/composer) and [issue tracker](https://github.com/composer/composer/issues)
12 | - [interactive `composer.json` cheat sheet](http://composer.json.jolicode.com/)
13 |
14 | ## Specifications
15 |
16 | - [`composer.json` technical schema](https://github.com/composer/composer/blob/master/res/composer-schema.json) — check against with [`composer validate` command](https://getcomposer.org/doc/03-cli.md#validate)
17 | - [SPDX license identifiers](https://github.com/composer/spdx-licenses/blob/master/res/spdx-licenses.json) recognized by Composer
18 | - [Semantic Versioning](https://semver.org/)
19 |
20 | ## Repositories
21 |
22 | - [Packagist](https://packagist.org/) ([GitHub](https://github.com/composer/packagist))
23 | - [WordPress Packagist](https://wpackagist.org/) ([GitHub](https://github.com/outlandishideas/wpackagist))
24 |
25 | ## Packages
26 |
27 | - [composer/installers](https://github.com/composer/installers) ([Packagist](https://packagist.org/packages/composer/installers)) — custom installer for frameworks’ paths (including WordPress extensions)
28 | - [johnpbloch/wordpress](https://github.com/johnpbloch/wordpress) ([Packagist](https://packagist.org/packages/johnpbloch/wordpress)) — automated fork of WordPress core, adding Composer support
29 | - [johnpbloch/wordpress-core-installer](https://github.com/johnpbloch/wordpress-core-installer) ([Packagist](https://packagist.org/packages/johnpbloch/wordpress-core-installer)) — custom installer for WordPress core to cleanly customize subdirectory path
30 | - [rarst/locate-vendor](https://github.com/Rarst/locate-vendor) ([Packagist](https://packagist.org/packages/rarst/locate-vendor)) — small experimental helper to resolve vendor folder location
31 |
32 | ## People
33 |
34 | - [Nils Adermann](http://www.naderman.de/) ([@naderman](https://twitter.com/naderman)) — Composer developer
35 | - [Jordi Boggiano](http://nelm.io/jordi) ([@seldaek](https://twitter.com/seldaek)) — Composer developer
36 | - [Andrey Savchenko](https://www.rarst.net/) ([@Rarst](https://twitter.com/Rarst)) — made this site so gets to plug himself all over it
37 | - [Tamlyn Rhodes](https://tamlyn.org/) ([@tamlyn](https://twitter.com/tamlyn)) — WordPress Packagist developer
38 | - [John P Bloch](https://johnpbloch.com/) — WordPress core installer developer
39 | - [#ComposerPHP](https://twitter.com/search/%23ComposerPHP) on Twitter
40 |
41 | ## Stacks
42 |
43 | - [WordPlate](https://wordplate.github.io/)
44 | - [Bedrock](https://roots.io/bedrock/)
45 |
46 | ## Tools
47 |
48 | - [Satis](https://github.com/composer/satis) ([Packagist](https://packagist.org/packages/composer/satis)) — static Composer repository generator
49 | - [Private Packagist](https://packagist.com/) — Composer package archive as a service for private source code and redundant infrastructure
50 | - [Release Belt](https://github.com/Rarst/release-belt) — Composer repository implementation to easily host ZIP release archives.
51 |
52 | ## IDE
53 |
54 | - [PhpStorm](http://www.jetbrains.com/phpstorm/)
55 | - [Composer support](http://www.jetbrains.com/phpstorm/webhelp/composer.html)
56 |
--------------------------------------------------------------------------------
/serve.cmd:
--------------------------------------------------------------------------------
1 | bundle exec jekyll serve
--------------------------------------------------------------------------------
/slides.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: null
3 | sitemap: false
4 | ---
5 |
6 |
7 |
8 |
9 |
10 |
13 |
14 | Better Site Stacks with Composer
15 |
16 | If you are not redirected automatically, follow the link.
--------------------------------------------------------------------------------