Wordpress Development Environment

Composer and WP CLI

Before anything else, we need to install WP CLI and Composer globally.

Install Composer globally

1
2
3

curl -sS https://getcomposer.org/installer -o composer-setup.php
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
rm composer-setup.php

Or alternative:

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
# try sudo install composer.phar /usr/local/bin/composer
# as that should set proper permission also
# [cp vs install](https://unix.stackexchange.com/questions/104982/why-use-install-rather-than-cp-and-mkdir)

chmod +x /usr/local/bin/composer

Install WP-CLI globally

1
2

sudo curl https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar --output /usr/local/bin/wp
sudo chmod +x /usr/local/bin/wp

Test installation with: wp --info or update by typing wp cli update.

How to properly run WP CLI / Composer

It is very important to run those tools as the right user and not to have permission problems later on. Idea came from this article but I’m using in much simplified variation.

File and folder permissions are usually set to “no-login” user and that also presents an obstacle. Best way to switch to proper user (www-data for example) is to execute U=web2; runuser $U -s /bin/bash and there are also alternative ways like sudo -u $U -s sh or su $U -s /bin/bash

But the final solution, and the best one is to execute this:

runuser $(stat -c %U .) -s /bin/bash

This will first run stat -c %U . to get the owner of the current folder, then it will pass this to runuser to execute the command as this user.

Setup Wordpress

Dockerized install

Dockerising WP environment is another great option and this article is a great way to explore it.

Standard install using WP CLI

This is the fastest way to install classic Wordpress with WP-CLI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

wp core download # download
wp core config --dbhost=example_com --dbname=example_com --dbuser=example_com --dbpass="example_password" --dbprefix="examplewp_" # create wp-config.php
wp db reset --yes  # not reqired to empty database
wp core install --url="https://www.example.com" --title="Example Ltd" --admin_name=example_user --admin_password=example_password --admin_email=user@example.com # install

# set basic debugging variables in wp-config.php
# clear; tail -f wp-content/debug.log -n0
#
wp config set --raw WP_DEBUG true
wp config set --raw WP_DEBUG_LOG true
wp config set --raw WP_DEBUG_DISPLAY false

You can check installed WP version with wp core version

Composer based setup

There are a couple of Composer based WP boilerplates and they all feature improved folder structure among other great features.

1. roots/bedrock
2. wordplate/wordplate
3. wecodemore/wpstarter

After careful research, I’ve decided on Bedrock as it is updated regularly and it is also the most famous with most articles around the net. It also supports enabling classic plugin upload and there are quite a good solutions to solve problems like that; paid plugins and such.

Trellis is deployment tool for remote and local WordPress LEMP stack, Sage is WordPress starter theme with templating support and such

Configure HTTP server

For composer based installs the WP folder is moved to a more secure place. Therefore, we need to make a small modifications in our nginx configuration.

Specifically, we need to set different site root.

There are new directives in ISPConfig that enable us to do just that: ##merge##, ##delete## and ##subroot _folder_## but the one we are using is simply to add this line

##subroot web ##

to ISPConfig’s nginx options (for Bedrock it’s web, for WP Starter it’s public, etc).

Install with WP Starter boilerplate

I’m using a package inpsyde/wpstarter-boilerplate to speed-up procedure

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# cd to web directory

# allow proper cache folder for composer (or use composer without cache)
chattr -i .. # needed for ispconfig
mkdir ../.cache # cache folder composer is using
chown -R --reference . ../.cache # set proper permission

runuser $(stat -c %U .) -s /bin/bash
composer create-project dnaber/wpstarter-boilerplate:dev-master .
exit

mv .env.example .env

Install with Bedrock boilerplate

Bedrock has a great folder structure

The beginning is same as in WP Starter, to allow composer’s cache to work properly:

1
2
3
4

# cd to web directory
chattr -i .. # needed for ispconfig
mkdir ../.cache # cache folder composer is using
chown -R --reference . ../.cache # set proper permission

Now we can install bedrock

1
2
3
4
5
6

runuser $(stat -c %U .) -s /bin/bash
composer create-project roots/bedrock .
cp .env.example .env
exit

nano .env

Enable plugin & theme uploads

Does bedrock/trellis disable the ability to add/install plugins via admin?

Postoji slično kao SatisPress, samo iz Zip fajlova: GitHub - Rarst/release-belt: Composer repository implementation for ZIPs.

Private package repository with SatisPress

To mantain paid and private plugins and themes, you could create a repo for everyone of them and distribute and update them in that way. But better option is to have a private composer repository for private plugin management

There are multitude of ways to create a private composer repository, but the most clever one is a plugin named SatisPress. The same authors are announcing some more modern alternative in the future, Crate, but for me now this is almost perfect.

The most tricky part form me was to discover that you must visit Settings → Permalinks page and set them to Post name or similar. That will force a flushing of the site’s permalinks and enable the SatisPress URL for packages.json to start working.

As for the SatisPress security the basic HTTP authentication is used by default.

Create a token in Satispress and confirm it’s working:

curl https://token:satispress@wpack.savioko.com/satispress/packages.json

Now we can instruct composer to install that repository with a <token> specified as username and satispress as password.

satispress/composer.md composer/handling-private-packages-with-satis.md at master · composer/composer

We could specify it like the following, but then this token will be exposed in Git for everybody.

composer config repositories.satispress composer https://<token>:satispress@wpack.savioko.com/satispress/packages.json

Much better way is to have credentials in separate file, out of Git:

composer config repositories.satispress composer https://wpack.savioko.com/satispress/packages.json
composer config http-basic.wpack.savioko.com <token> satispress

This will create auth.json file sitting besides your composer.json with your credentials as explained in this example.

As everything is working now, type the following to install some theme or plugin:

composer require satispress/anahata satispress/anahata-child

Wordpress Testing

Introduction - wp-browser Setting up WPBrowser on Bedrock – theAverageDev

Wordpress tweaks

Decide on .gitignore file! Template .gitignore file for WordPress projects gitignore/WordPress.gitignore at master · github/gitignore

Local Development

Sources & Articles

Comparing modern MVC WordPress frameworks

Ovaj autor je super! Woow! WP Emerge: A modern Framework and Starter Theme - WP Emerge

OVO JE SAVRŠENO! Bolje od BEDROCK-a za mene Personal WordPress boilerplate based-on Bedrock by Roots WOOW! feryardiant/wpdev: Personal WordPress boilerplate based-on Bedrock by Roots.

Odlično o OOP i WP

Why object-oriented programming is your next step as a WordPress developer | The Man in the Arena

Category: Programming | The Man in the Arena

Introduction to WordPress acceptance testing | The Man in the Arena PHP reflection API fundamentals | The Man in the Arena

Conclude

What is exclusive to local development?

• I can execute PhpStorm IDE and use all it’s advanced functionality Please, try to emulate that on VSCode

• Can edit local graphic files. This is no reason as I would never keep it online, anyway

• I’m independent from internet for developing. This is completely obsolete now because I can’t write a line of code without internet.

Must do from now on

1. History of files using Git. Simple git init is enough. Use gitignore not to backup shit.
2. Backup database manually via WP-CLI on regular basis (some cronjob or something)

Why I like bedrock?

• root not configs are not publicly accessed so I can keep documentation

What setup to use where?

1. Use Bedrock. If a have SSH access and can change root folder of a site
2. Use classic setup, if I won’t have real SSH access

Postoji još jedan način!

lucanos/WordPress-Remote-Installer: Remote install WordPress, Plugins and Themes - Only 1 file uploaded via FTP je najbolji! vuče pluginove i theme sa github-a

Interesting script to auto-install Wordpress: WP Quick Install, by WP Rocket in 2014 GeekPress/WP-Quick-Install: WP Quick Install is the easiest way to install WordPress.

Ustvari super način za instalaciju WP-a The Fastest WordPress Installation - WP Quick Install