ideasonpurpose / docker-wordpress-dev Goto Github PK

Things break with v2.

See also the possible compose v2 trailing path fix: docker/compose#8558

Error reading variables from .env:

unexpected character "@" in variable name near "[email protected] -p 8765\n# SSH_LOGIN should be set to the SSH Login string from WP Engine's or Kinsta's\n# admin backend. Look like this:\n# - wpengine: [email protected]\n# - kinsta: ssh [email protected] -p 54321\n# In the above examoples the elements map like this:\n# ${SSH_USER}@${SSH_HOST}\n# Each item can also be entered individually, and individual entries will take\n# precedence over components extracted from SSH_LOGIN.\n\n\nSSH_USER=\n# The user account which connects to the server. For WP Engine, this matches the\n# environment name.\n\n\nSSH_HOST=\n# The server address to connect to.\n\n\nSSH_PORT=\n# The server port listening for SSH connections\n\n\nSSH_WP_CONTENT_DIR=public/wp-content\n# default: sites/${SSH_USER}/wp-content\n# SSH_WP_CONTENT_DIR is the path to the wordpress wp-content directory. This will\n# most likely match the WP_CONTENT_DIR WordPress constant and does not include\n# a trailing slash.\n# Path can be relative to the SSH user home folder or an absolute path.\n# Examples:\n# - wpengine: sites/${SSH_USER}/wp-content\n# - kinsta: public/wp-content\n\n\nDATA_MODEL_PLUGIN=../nrmp-data-model:/var/www/html/wp-content/plugins/nrmp-data-model\nBLOCKS_PLUGIN=../nrmp-blocks:/var/www/html/wp-content/plugins/nrmp-blocks\n# Additional development plugins can be mounted into the WordPress environment as\n# individual volumes. The local relative path to the working plugin directory should\n# be pointed to the absolute path inside the container. In the following example,\n# a data-model plugin is being developed in a sibling directory to the theme:\n#\n# DATA_MODEL_PLUGIN=../example-plugin:/var/www/html/wp-content/plugins/example-plugin\n\nWORDPRESS_DEBUG=1\n"

After running docker run --rm -it -v ${PWD}:/usr/src/site ideasonpurpose/wordpress:0.7.8 init the project's package.json file should be sorted. It wasn't?

WordPress does not show theme version numbers by default. This makes it very difficult to tell one theme apart from another. We should inject the theme version number into the theme title so they display on the default themes page.

This doesn't seem to be working anymore

Either fix that, or just run npm install in new projects as a workaround. (will that cause architecture conflicts? eg. amd64 vs. arm64?)

https://docs.docker.com/compose/profiles/

This should allow for assigning services to a "utility" profile, which would still allow for docker compose up on the main file (though we never do that).

Having one less file would be nice, and would shorten most of the commands in package.json

Everything works, but this is messy. Should be set to www-data:www-data (33:33)

https://www.php.net/manual/en/ini.core.php#ini.short-open-tag

Just ran into a bug which did not appear when WP_DEBUG was set. This means it only shows in production (or staging, but close enough)

Add something to the .env file which overrides the default WP_DEBUG setting so it can be disabled locally.

IOP's media library, for example, is currently over 5GB and takes an extraordinarily long time to sync down. Needing to implement something quickly could be seriously hindered by having to wait.

Not sure how to do this, but since the uploads directory has a known format, maybe the script could request the current year by default, and then add some sort of pull:uploads-all command to grab everything before that

Do something similar to how the the package.json config.port value is passed to docker:start with cross-env-shell.

We could use env vars for the WordPress and PHP versions to build the desired image, something like:

ARG WP_VERSION=5
ARG PHP_VERSION=8-apache

ARG BASE_IMAGE=wordpress:${WP_VERSION}-php${PHP_VERSION}

# $BASE_IMAGE will be something like `wordpress:5.9.1-php8.0-apache`
# and would fallback to wordpress:5-php8-apache
FROM $BASE_IMAGE

Can these pull from the environment? Config in package.json?

References:

• https://docs.docker.com/engine/reference/builder/#arg
• https://www.jeffgeerling.com/blog/2017/use-arg-dockerfile-dynamic-image-specification

See docker-library/wordpress#685, the php intl extension is included now

This is in use on the IOP site. Should probably just add it:

//.eslint.js
module.exports = {
  env: {
    es2021: true,
    node: true,
  },
  extends: ["eslint:recommended", "plugin:react/recommended"],
  parserOptions: {
    ecmaFeatures: { jsx: true },
    ecmaVersion: "latest",
    sourceType: "module",
  },
  plugins: ["react"],
  rules: {
    "react/react-in-jsx-scope": "off",
    "sort-imports": ["error", { allowSeparatedGroups: true }],
  },
};

Check that the image exists before bumping. v5.9.2 currently does not exist on DockerHub, but it's the latest release returned from the WordPress API.

There are some notes here:

Might not be able to catch the 404, but checking for a name might be enough?

Here's the DockerHub error JSON for a non-existent image:

{
  "errinfo": {
    "namespace": "library",
    "repository": "wordpress",
    "tag": "5.9.5"
  },
  "message": "tag '5.9.5' not found"
}

A successful request is much bigger, but includes a top-level name key.

https://github.com/settings/tokens/new

Kinsta's SSH commands copy something like this:

ssh [email protected] -p 23456

If that's pasted directly into .env it should work correctly, including the randomized SSH port.

What's missing or not working? Seems like this could already be 1.0.0.

Getting a "Connection Information" dialog asking for FTP login.

https://hub.docker.com/settings/security

It's trying to run postversion after versioning. Silly. Split the scripts into a separate file, boilerplate-package.json or something

Add cd /usr/src to .bashrc

The message at launch prints the wrong port.

Also add a note about appending the ?XDEBUG_PROFILE=1` query to generate a profile

https://webpack.js.org/migrate/5/

WP Engine keeps a copy of the most recent DB snapshot in the site's wp-content directory. Kinsta doesn't. Both block serving of *.sql files.

The pull script should be smarter about missing *.sql files and fail with a descriptive message.

Cron works on Kinsta though, so a workaround is simply to add a cron job which dumps the DB hourly. Something like this:

# dump db hourly for dev mirrors
59      *       *       *       *       mysqldump --default-character-set=utf8mb4 -udbuser -pDBPASSWORD db-name > ~/public/wp-content/mysql.sql

The generated package.json file has a leftover in versionFiles:

    "wp-content/themes/THEME_NAME/style.css",

Something changed with how the npm run start (webpack serve) process is exiting. It now throws an error which prevents the poststart script from being called.

I still think it's primarily related to the change in signal propagation in npm v7, briefly touched upon in npm#2124.

But there are also slight changes in how docker-compose is working, especially as Docker migrates away from docker-compose cli towards the new compose command.

Finally, the webpack-dev-server v4 beta release notes mention a new setupExitSignals option which might have something to do with this?.

Too many variables with too many new releases, so I'm shelving this for now (2021-08). Will check back after webpack-dev-server ships v4 -- which looks like it's going to be a lot of work based on how much they're changing.

2021-08-15T20_13_32_302Z-debug.log

When pulling changes, files in wp-content/themes/<theme>/acf-json often switch to 644 mode -rw-r--r-- . This causes a permission denied error when ACF tries to write updates to those files. Files should be 664 -rw-rw-r--

What exactly is causing those files to switch to 644?
Add group-write to umask?

Warning: file_put_contents(/var/www/html/wp-content/themes/iop-nrmp/acf-json/group_60de150bd0cd2.json): failed to open stream: Permission denied in /var/www/html/wp-content/plugins/advanced-custom-fields-pro/includes/local-json.php on line 223

https://xdebug.org/docs/install

These files are created with www-data user:group ownership and 664 permissions, and can't be modified by the active WSL user. They should be owned by the current user.

-rw-rw-r-- 1 www-data www-data 50656 Jun  7 22:48 group_60bec34eaff71.json

When a theme pushes a semver tag, that should trigger an action which records the tag as a proper release with a link to the packaged zip archive.

ref: https://github.com/ncipollo/release-action

This was probably to avoid errors if the lock files didn't exist, but running the script immediately dirties the tree when setting up an existing site, which is a waste of time.

If possible, use npm ci and composer install instead.

If not possible, revert changes to the lock files as a last step.

Set initial version to 0.0.0

https://github.com/ideasonpurpose/docker-wordpress-dev/blob/master/README.md#alternate-devserver-ports

This broke in npm v7, based on RFC 21

Alternate DevServer Ports

Webpack devserver runs on port 8080 by default. Multiple projects can be run simultaneously by using npm config to assign different ports the the project's package.json name. For example, three projects named csr-site, pro-bono and ar-project could be run simultaneously on custom ports, after running these commands:

npm config set csr-site:port 8080
npm config set pro-bono:port 8081
npm config set ar-project:port 8082

See also:

• npm/cli/#3475
• npm RFC 0021

When running the bump script, we should also bump the version of our docker-build image.

The latest tag can be requested from Docker Hub with something like this:

 wget -q -O- https://registry.hub.docker.com/v2/repositories/ideasonpurpose/docker-build/tags  | jq '.results[1]["name"]'

Might be one-line? How to test?

     -  name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: true
          tags: user/app:latest

https://github.com/docker/build-push-action/blob/master/docs/advanced/multi-platform.md```

The handling of multiple instances is kind of clumsy. After cancelling out of the dev server, both the database and wordpress images are still active, and still occupying ports. Needing to run docker-compose down before switching projects is tedious and forgettable

The default 40MB is too low for heavy plugins like WPML.

View settings here: Tools > Site Health > Info Tab > WordPress Constants

Both WP Engine and Kinsta appear to leave the default at 40MB, sites on WP Engine with WPML installed report WP_MEMORY_LIMIT as 512M.

Clean start lists the following:

1. Create a project folder and cd into it: mkdir my-wp-site && cd $_
2. Run docker run --rm -it -v ${PWD}:/usr/src/site ideasonpurpose/wordpress init
3. Run npm install
4. Run npm run composer
5. Run npm run docker:start

Show steps 3-5 after step 2 so we don't have to reference the README again.

WordPress 5.5 added native support for environment types:

https://make.wordpress.org/core/2020/07/24/new-wp_get_environment_type-function-in-wordpress-5-5/

might as well switch to that instead of the WP_ENV workaround.

On Ubuntu/WSL, ownership on a newly cloned project came up as root:root, then the script failed while trying to sync down the dumpfile from the remote.

After a lot of development on many sites, cookies will sometimes swell up and cause server errors because the cookies are too big for the header fields.

Workaround: In the Web Inspector, Remove all cookies from the Applications tab.

Can this be fixed by using a repeated value in the WordPress config.php salts?

Docker Compose "v2" now uses python-dotenv for dotenv parsing and (as of Compose v2.1.1) handles whitespace slightly differently than plain docker. Specifically, quotes are now supported for values.

This is definitely better but existing values with whitespace or special characters now throw errors. So far, all of those errors can be corrected by enclosing values in quotes.

I suspect the errors are a bug in Docker's implementation since the .env file validates using python-dotenv and dotenv-linter with and without quoted values.

Ref: #33 & docker/compose#8964

This might not be us. https://wordpress.org/support/topic/wordpress-database-error-table-wp_options-doesnt-exist-2/

image/avif

Probably this line

find /usr/src/site/wp-content -type f -exec chmod -f 0664 {} \+

That will generate a single chmod command with however-many files exist in wp-content. On our site, that's about 36k files with the uploads directory. (which is its own problem)

For testing, might want to run time for all the commands in permissions.sh

If the composer service runs but there is not yet a ~/.composer directory Docker will create the directory but leave it owned by root and then fail when the user the composer service is running as tries to write to it.

If possible, the composer service should create the mount with the correct owner.

https://getcomposer.org/2