PHPackages                             kanopi/wordpress-core-composer-scaffold - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. kanopi/wordpress-core-composer-scaffold

AbandonedComposer-plugin[Utility & Helpers](/categories/utility)

kanopi/wordpress-core-composer-scaffold
=======================================

A flexible Composer project scaffold builder.

v1.0.0(4y ago)04GPL-2.0-or-laterPHPPHP >=7.3.0

Since Oct 30Pushed 3mo ago6 watchersCompare

[ Source](https://github.com/kanopi/wordpress-core-composer-scaffold)[ Packagist](https://packagist.org/packages/kanopi/wordpress-core-composer-scaffold)[ Docs](https://www.wordpress.org)[ RSS](/packages/kanopi-wordpress-core-composer-scaffold/feed)WikiDiscussions main Synced 1mo ago

READMEChangelogDependencies (2)Versions (2)Used By (0)

WordPress Composer Scaffold
===========================

[](#wordpress-composer-scaffold)

This project provides a Composer plugin for managing WordPress core scaffold files in a Composer-based WordPress project.

This takes care of:

- Placing scaffold files (like `index.php`, `wp-config.php`, `.htaccess`, etc.) from WordPress core or custom packages into their desired location inside the web root. Only individual files may be scaffolded with this plugin.
- Writing a WordPressInstalled.php file, which holds a PHP class that defines values about the current installation as class constants.
- Writing an autoload.php file to the web root, which includes the Composer autoload.php file.

The purpose of scaffolding files is to allow WordPress sites to be fully managed by Composer, and still allow individual asset files to be placed in arbitrary locations. The goal of doing this is to enable a properly configured Composer template to produce a file layout that matches the desired WordPress project structure.

Note that the dependencies of a WordPress site are only able to scaffold files if explicitly granted that right in the top-level composer.json file. See [allowed packages](#allowed-packages), below.

Usage
-----

[](#usage)

WordPress Composer Scaffold is used by requiring `kanopi/wp-core-composer-scaffold` in your project, and providing configuration settings in the `extra` section of your project's composer.json file. Additional configuration from the composer.json file of your project's dependencies is also consulted in order to scaffold the files a project needs. Additional information may be added to the beginning or end of scaffold files, as is commonly done to `.htaccess` and `robots.txt`files. See [altering scaffold files](#altering-scaffold-files) for more information.

Typically, the scaffold operations run automatically as needed, e.g. after `composer install`, so it is usually not necessary to do anything different to scaffold a project once the configuration is set up in the project composer.json file, as described below. To scaffold files directly, run:

```
composer wp:scaffold

```

### Allowed Packages

[](#allowed-packages)

Scaffold files are stored inside of projects that are required from the main project's composer.json file as usual. The scaffolding operation happens after `composer install`, and involves copying or symlinking the desired assets to their destination location. In order to prevent arbitrary dependencies from copying files via the scaffold mechanism, only those projects that are specifically permitted by the top-level project will be used to scaffold files.

Example: Permit scaffolding from the project `upstream/project`

```
  "name": "my/project",
  ...
  "extra": {
    "wp-scaffold": {
      "allowed-packages": [
        "upstream/project"
      ],
      ...
    }
  }

```

Allowing a package to scaffold files also permits it to delegate permission to scaffold to any project that it requires itself. This allows a package to organize its scaffold assets as it sees fit. For example, if `upstream/project`stores its assets in a subproject `upstream/assets`, `upstream/assets` would implicitly be allowed to scaffold files.

It is possible for a project to obtain scaffold files from multiple projects. For example, a WordPress project using a starter kit, and installing on a specific web hosting service provider might take its scaffold files from:

- WordPress core
- Its starter kit
- A project provided by the hosting provider
- The project itself

Each project allowed to scaffold by the top-level project will be used in turn, with projects declared later in the `allowed-packages` list taking precedence over the projects named before. `roots/wordpress` is implicitly allowed and will be placed at the top of the list. The top-level composer.json itself is also implicitly allowed to scaffold files, and its scaffold files have highest priority.

### Defining Project Locations

[](#defining-project-locations)

The top-level project in turn must define where the web root is located. It does so via the `locations` mapping, as shown below:

```
  "name": "my/project",
  ...
  "extra": {
    "wp-scaffold": {
      "locations": {
        "web-root": "./public"
      },
      ...
    }
  }

```

This makes it possible to configure a project with different file layouts.

If a web-root is not explicitly defined, then it will default to `.`, the same directory as the composer.json file.

### Altering Scaffold Files

[](#altering-scaffold-files)

Sometimes, a project might wish to use a scaffold file provided by a dependency, but alter it in some way. Two forms of alteration are supported: appending and patching.

The example below shows a project that appends additional entries onto the end of the `robots.txt` file:

```
  "name": "my/project",
  ...
  "extra": {
    "wp-scaffold": {
      "file-mapping": {
        "[web-root]/robots.txt": {
          "append": "assets/my-robots-additions.txt",
        }
      }
    }
  }

```

It is also possible to prepend to a scaffold file instead of, or in addition to appending by including a "prepend" entry that provides the relative path to the file to prepend to the scaffold file.

The example below demonstrates the use of the `post-wp-scaffold-cmd` hook to patch the `.htaccess` file using a patch.

```
  "name": "my/project",
  ...
  "scripts": {
    "post-wp-scaffold-cmd": [
      "cd public && patch -p1