Download the PHP package gaambo/deployer-wordpress without Composer

On this page you can find all versions of the php package gaambo/deployer-wordpress. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package deployer-wordpress

Deployer WordPress Recipes

A collection of Deployer Tasks/Recipes to deploy WordPress sites. From simple sites deployed via copying files up to building custom themes/mu-plugins and installing npm/composer vendors - It handles all kinds of WordPress installation types.

Table Of Contents

Installation

  1. Run composer require gaambo/deployer-wordpress --dev in your root directory
  2. Choose one of the recipes and copy the corresponding example files (examples/base or examples/advanced) into your root directory - or write your own.
  3. Read through the recipe and customize it to your needs - here's a checklist:
    • [ ] Check localhost configuration
    • [ ] Set paths to your directory structure
    • [ ] If you have a custom theme set it's name - if not remove the configuration and the theme build-tasks
    • [ ] If you have a custom mu-plugin set it's name - if not remove the configuration and the mu-plugin build-tasks
    • [ ] Check if the deployment flow meets your needs and maybe delete/add/overwrite tasks
  4. Make your remote hosts ready for deployment (install composer, WP CLI; setup paths,...). Allthough the library checks for most of them and installs them.
  5. Make a test deployment to a test/staging server. Do not directly deploy to your production site, you may break it.
  6. Develop, deploy and be happy :)

Requirements

Obviously:

Most of the tasks only run in nix shells - so a nix operating system is preferred. If you run Windows have a look at WSL to run Ubuntu Bash inside Windows.

Some tasks have additional requirements, eg:

Configuration

All tasks are documented and describe which options/variables need to be configured. set.php is included in all example recipes - This and the example recipes should have you covered regarding all required configurations. Further variables which need to be set by you are marked accordingly in the recipes.

To help understand all the configurations here are the thoughts behind theme: The tasks are built to work with any kind of WordPress setup (vanilla, composer, subdirectory,..) - therefore all paths and directorys are configurable via variables. set.php contains some sane defaults which makes all tasks work out of the box with a default installation.

Default Directory Structure

My Vanilla WordPress Boilerplate uses this library. You can find a example configuration in the GitHub repository.

wp-config.php

To make WordPress deployable you need to extract the host-dependent configuration (eg database access) into a seperate file which does not live in your git repository and is not deployed. I suggest using a wp-config-local.php file. This file should be required in your wp-config.php and be ignored by git (via .gitignore). This way wp-config.php can (should) be in your git repository and also be deployed. The default wp/filter configuration assumes this. Another advantage of using a wp-config-local.php is to set WP_DEBUG on a per host basis.

Rsync filters/excludes/includes

The default rsync config for syncing files (used by all *:push/*:pull tasks) is set in the rsync variable. By default it set's a filter-perDir argument as .deployfilter - which means rsync will look for a file named .deployfilter in each directory to parse filters for this directory. See rsync man section "Filter Rules" for syntax.

This can be handy to put int your custom theme or mu-plugin - for example:

This prevents any development files/development tools from syncing. I strongly recommend you put something like this in your custom theme and mu-plugins or overwrite any of the themes/filter or mu-plugins/filter configurations.

Tasks

All tasks reside in the src/tasks directory and are documented well. Here's a summary of all tasks - for details (eg required variables/config) see their source. You can also run dep list to see all available tasks and their description.

Database Tasks (tasks/database.php)

File Tasks (tasks/files.php)

Theme Tasks (tasks/theme.php)

Uploads Tasks (tasks/uploads.php)

Plugin Tasks (tasks/plugins.php)

MU Plugin Tasks (tasks/mu-plugins.php)

WordPress Tasks (tasks/wp.php)

WP-CLI

Handling and installing the WP-CLI binary can be done in one of multiple ways:

  1. The default bin/wp in set.php checks for a usable WP-CLI binary and if none is found it downloads and installs it to {{deploy_path}}/.dep/wp-cli.phar (this path is checked in the future as well).
  2. If you want this behaviour (check if installed, else install) but in another path, overwrite the bin/wp variable with a function and change the path it should be installed to.
  3. Set the bin/wp variable path on the host configuration, if WP-CLI is already installed.
  4. Install the WP-CLI binary manually with the wp:install-wpcli task and set the path as /bin/wp afterwards. You can pass the installPath, binaryFile and sudo usage via CLI: dep wp:install-wpcli stage=production -o installPath='{{deploy_path}}/.bin -o binaryFile=wp -o sudo=true

See original PR for more information.

There's a task for downloading core and --info. You can generate your own tasks to handle other WP-CLI commands, there's a util function Gaambo\DeployerWordpress\Utils\WPCLI\runCommand (src/utils/wp-cli.php);

Recipes

Deployer WordPress ships with two base recipes which handle my use cases. Both recipes are based on the default PHPDeployer common recipe and have their own recipe file which you can include in your deploy.php as a start. The examples folder provides examples for each recipe. Both recipes log the deployed versions in PHPDeployers default format (.dep folder). Both recipes overwrites the deploy:update_code Deployer task with a deploy:update_code task to deploy code via rsync instead of git

Base

This is for WordPress sites where you don't need symlinking per version or atomic releases. This means that on your remote/production host you just have on folder which contains all of WordPress files and this is served by your web server. Since this is still based on the default PHPDeployer recipe which uses symlinking and to provide compatibility with all tasks, this just hardcodes the release_path and current_path.

Advanced

This uses symlinking like the default common recipe from PHPDeployer. Each release gets deployed in its own folder unter {{deploy_path}}/releases/ and {{deploy_path}}/current is a symlink to the most current version. The symlink is automatically updated after the deployment finishes successfully. You can configure your webserver to just server {{deploy_path}}/current.

Custom Theme

Set custom theme name (= directory) in variable theme/name. By default it runs theme:assets:vendors and theme:assets:build locally and just pushes the built/dist files to the server (--> no need to install Node.js/npm on server). The theme:assets task (which groups the two tasks above) is hooked into before deploy:push_code.

Installing PHP/composer vendors/dependencies is done on the server. The theme:vendors task is therefore hooked into after deploy:push_code.

Custom MU-Plugin

Set custom mu-plugin name (=directory) in variable mu-plugin/name. Installing PHP/composer vendors/dependencies is done on the server. The mu-plugin:vendors task is therefore hooked into after deploy:push_code.

Changelog

See CHANGELOG.md.

Contributing

If you have feature requests, find bugs or need help just open an issue on GitHub. Pull requests are always welcome. PSR2 coding standard are used and I try to adhere to Deployer best-practices.

Testing

  1. Download my Vanilla WordPress Boilerplate or set up a local dev environment with a deploy config
  2. Setup a remote test server
  3. Configure yml/deploy.php
  4. Run common tasks (deploy, plugins:pull/push, db) for both base as well as advanced recipe

Built by

Gaambo and Contributors

All versions of deployer-wordpress with dependencies

PHP Build Version
Package Version
Requires php Version ^8.0|^7.3
deployer/deployer Version ^7.3
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package gaambo/deployer-wordpress contains the following files

Loading the files please wait ....