Rename the operator commands to keel-wp and keel-wordpress-update #7

New issue

Closed

opened 2026-09-28 00:08:51 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 00:08:51 -03:00

(Migrated from github.com)

overlay/usr/local/bin/turnkey-wp and
overlay/usr/local/sbin/turnkey-wordpress-update are written by this
repository, and they carry another distribution's name.

Decision by the maintainer, 2026-09-28, recorded as handbook decision 0015: the
Keel name becomes the real command and the turnkey-* name is kept as a
symlink. Both keep working — an operator who pasted a command out of TurnKey's
documentation, or who scripted against turnkey-wp, must not silently lose it.

keel-wp, with turnkey-wp a symlink to it.
keel-wordpress-update, with turnkey-wordpress-update a symlink to it.
Behaviour unchanged: still runs wp-cli as www-data with an explicit
--path, never as root.
Every call site updated, not only the ones the build exercises — a caller
left on the old name still works through the symlink, which is why this is
easy to miss. conf.d/main, overlay/usr/lib/inithooks/firstboot.d/40wordpress,
tests/v19.sh and README.rst all mention one of the two names today.
tests/v19.sh coverage must not shrink, and one test must prove the
compatibility symlink actually works rather than merely exists.

How the symlink is produced matters: a symlink committed in an overlay
directory and one created in conf.d/main do not behave the same through the
overlay copy step. Verify which one lands in the built image.

Org-wide context: Keel-Linux/tracker#12.

`overlay/usr/local/bin/turnkey-wp` and `overlay/usr/local/sbin/turnkey-wordpress-update` are written by this repository, and they carry another distribution's name. Decision by the maintainer, 2026-09-28, recorded as handbook decision 0015: the Keel name becomes the real command and the `turnkey-*` name is kept as a symlink. Both keep working — an operator who pasted a command out of TurnKey's documentation, or who scripted against `turnkey-wp`, must not silently lose it. - `keel-wp`, with `turnkey-wp` a symlink to it. - `keel-wordpress-update`, with `turnkey-wordpress-update` a symlink to it. - Behaviour unchanged: still runs wp-cli as `www-data` with an explicit `--path`, never as root. - Every call site updated, not only the ones the build exercises — a caller left on the old name still works through the symlink, which is why this is easy to miss. `conf.d/main`, `overlay/usr/lib/inithooks/firstboot.d/40wordpress`, `tests/v19.sh` and `README.rst` all mention one of the two names today. - `tests/v19.sh` coverage must not shrink, and one test must prove the compatibility symlink actually works rather than merely exists. How the symlink is produced matters: a symlink committed in an overlay directory and one created in `conf.d/main` do not behave the same through the overlay copy step. Verify which one lands in the built image. Org-wide context: Keel-Linux/tracker#12.