DEV Community: Florian Stolzenhain

Bulk-create editor users in Drupal by mail address

Florian Stolzenhain — Fri, 14 Feb 2025 15:03:41 +0000

Original post on my blog, happy to include feedback!
Cover: Biblioteca de Arte / Art Library Fundação Calouste Gulbenkian, via New Old Stock

This creates a user according to it's email, sets a role and creates a 24h valid one-time-login.
The link can be transmitted for easy setup of password and account settings.

drush user-create [username] --mail="[user@mail]" &&\
    drush user-add-role "[editor]" [username] &&\
    drush uli --uri="[https://example.com]" --name="[username]"

For adding a role to multiple users, use comma separated arguments:

drush user-add-role "[editor]" [username1,username2]

Documentation

HTML whitespace control

Florian Stolzenhain — Tue, 04 Feb 2025 16:56:04 +0000

Original post on my blog, happy to include feedback!
Cover: NASA, via New Old Stock

Assuming you're wrangling with whitespace-critical code like

<a href="#">
    <!-- will display an additional space character -->
    my link text
</a>

you could either remove whitespace in your template

<a href="#">my link text</a>

or use your templater's whitespace control:

Handlebars

<a href="#">
    {{!-- will remove whitespace on each side of the tilde --}}
    {{~ text ~}}
</a>

Twig

<a href="#">
    {# remove whitespace on each side of the tilde #}
    {{- text -}}
</a>

<a href="#">
    {# remove whitespace on each side of the tilde – not newlines #}
    {{~ text ~}}
</a>

{# suppress whitespace in this region #}
{% spaceless %}
<a href="#">
    {{ text }}
</a>
{% endspaceless %}

Poor man's parallel in Bash

Florian Stolzenhain — Fri, 10 Jan 2025 19:43:34 +0000

Original post on my blog, happy to include feedback!
Cover: Paris bibliothéques, via Clawmarks

Topics:

Running scripts in parallel
Tools to limit concurrent jobs
Shell process handling cheatsheet
Limit concurrent jobs with Bash
Bonus: One-liners

1) Running scripts in parallel

does not take much effort: I've been speeding up builds by running commands simultaneously with an added & ampersand:

# stuff can happen concurrently
# use `&` to run in a sub-shell
cmd1 &
cmd2 &
cmd3 &
# wait on sub-processes
wait
# these need to happen sequentially
cmd3
cmd4

echo Done!

Job control is a shell feature: commands are put into a background process and run at the same time.

Now assuming you want to loop over more than a few commands, e.g. converting files:

for file in *.jpg; do
    # start optimizing every file at once
    jpegoptim -m 45 "${file}" &
done
# finish queue
wait

Running a lot of processes this way is still faster than a regular loop. But compared to just a few concurrent jobs there are no speed gains – even possible slowdowns on async disk I/O [Quotation needed].

So you'll want to use

2) Tools to limit concurrent jobs

by either 1) installing custom tools like parallel or xjobs or 2) relying on xargs, which is a feature-rich tool but more complicated.

Transforming wait to xargs code is described here: an example for parallel batch jobs. The article notes small differences between POSIX flavours – e.g. different handling of separators on BSD/MacOS.

We'll be choosing option 3) – digging into features of wait and jobs to manage processes.

Quoting this great summary, here are some example commands for

3) Shell process handling

# run child process, save process id via `$!`
cmd3 & pid=$!
# get job list
jobs
# get job ids only
# note: not available on zsh
jobs -p
# only wait on job at position `n`
# note: slots may turn up empty while
#       newer jobs rest in the queue's tail
wait %n
# wait on last job in list
wait %%
# wait on next finishing process
# note: needs Bash 4.3
wait -n

Taking our example from before, we make sure to

4) Limit concurrent jobs with Bash

each time a process is finished using wait -n:

for file in *.jpg; do

    jpegoptim -m 45 "${file}" &

    # still < 3 max job -l ines? continue loop
    if [[ $(jobs|wc -l) -lt 3 ]]; then continue; fi

    # with 3 jobs, wait for -n ext, then loop
    wait -n

done
# finish queue
wait

Sadly, this won't work in MacOS, because Bash environments are frozen on old versions. We replace the wait -n command with wait %% to loop on the 3rd/last job in queue – an ok compromise on small groups (1/3 chance of fastest/slowest/medium job):

for file in *.jpg; do

    jpegoptim -m 45 "${file}" &

    # still < 3 max job -l ines? continue loop
    if [[ $(jobs|wc -l) -lt 3 ]]; then continue; fi

    # with 3 jobs, wait for last in line, then loop
    wait %%

done
# finish queue
wait

To further develop the code, one could check for Bash version or alternative shells (zsh on MacOS) to switch code depending on context. I keep using these:

5) Bonus: One-liners

# sequential, slow
time ( for file in *.jpg; do jpegoptim -m 45 "${file}" ; done )

# concurrent, messy
time ( for file in *.jpg; do jpegoptim -m 45 "${file}" & done; wait )

# concurrent, fast/compatible
time ( for file in *.jpg; do jpegoptim -m 45 "${file}" & if [[ $(jobs|wc -l) -lt 3 ]]; then continue; fi; wait %%; done; wait )

# concurrent, fastest
time ( for file in *.jpg; do jpegoptim -m 45 "${file}" & if [[ $(jobs|wc -l) -lt 3 ]]; then continue; fi; wait -n; done; wait )

Fun Fact

As the 20th birthday post by parallel author Ole Tange explains, the original version was leveraging make because it allows asynchronous processes as well.

Ports for ssh, scp, rsync

Florian Stolzenhain — Tue, 20 Feb 2024 13:48:02 +0000

Original post on my blog, happy to include feedback!
Cover: Théophile Steinlen, via Clawmarks

Have to look¹ this² up³ every time⁴:

Assuming you're connected to a machine like

ssh user@my.host.server

and want to transfer files afterwards, you'll likely update your recent command to

scp user@my.host.server:/my/folder/my.file dest/folder

rsync -a user@my.host.server:/my/folder dest/

for copying said files. So far, so good.

When relying on ports, this gets way more complicated due to differing parameter styles for each command which are

# `-p[port]`
ssh -p222 user@my.host.server

# `-P [port]`
scp -P 222 user@my.host.server:/my/folder/my.file dest/folder

# set port on custom remote shell
rsync -a -e "ssh -p222" user@my.host.server:/my/folder/my.file dest/folder

(Note that rsync has more options for defining TCP daemon ports with --port=[PORT] which is probably not what you want)

You're welcome!

ssh manpage ↩
scp manpage ↩
rsync manpage ↩
Find offline documentation tools on Stackoverflow … or use Dash on Macs and Zeal man docsets on Windows ↩

Automate Wordpress setups via WP-CLI

Florian Stolzenhain — Fri, 03 Nov 2023 15:56:57 +0000

Original post on my blog, happy to include feedback!
Cover: U.S. National Archives, via New Old Stock

These examples assume a working local WP-CLI helper –
for installing and file structure advice, see 4) installing WP-CLI.

Setup vanilla Wordpress from scratch
Migrate an existing instance
Update an instance
1. Specify version and locale
See also
Further reading

1) Setup vanilla Wordpress from scratch

Assumes an existing local database and host.

# root dir is project dir
mkdir -p wordpress
cd wordpress

# download to current folder, see
# https://developer.wordpress.org/cli/commands/core/download/
wp core download --locale=en_GB

# TODO: using the password on the shell is not ideal, see
# https://developer.wordpress.org/cli/commands/config/create/#examples
wp config create --dbname=[name] --dbuser=[user] --dbpass=[pass]

# this will return a user password
wp core install --url=website.local --title="Website title" --admin_user="janitor" --admin_email="foo@bar.local"

# create local wp-cli config for htaccess generation, see
# https://developer.wordpress.org/cli/commands/rewrite/structure/
printf "apache_modules:\n\
  - mod_rewrite\n" >> ../wp-cli.local.yml

# create htaccess
wp rewrite structure '/%year%/%monthnum%/%postname%/' --hard

TODO: add SQLite example

2) Migrate an existing instance

wp db reset --yes
gunzip [file.sql.gz] --stdout | wp db import -

# reset pw of user `admin` to `test`
wp eval "wp_set_password( 'test', get_user_by( 'login', 'admin' )->ID );"

# set local url
# needs http[s]:// protocol and quotes
wp option update siteurl 'http://domain.local'
wp option update home 'http://domain.local'

# flush redirects
wp rewrite flush

3) Update an instance

# update core
wp core update
# update all themes
wp theme update --all
# update all plugins
wp plugin update --all
# update language
wp language core update
wp language plugin --all update
wp language theme --all update
# update db scheme
# otherwise, an admin user will be prompted
wp core update-db

Note: paradoxically, a working wp-config.php is mandatory for WP-CLI to work. You can use the helper command wp config create if you don't want to clone wp-config-sample.php manually.

Specify version and locale

wp core update --version=5.4 --locale=en_GB

Check locale availability via WP translation platform

4) See also

Globally installing WP-CLI vs keeping a local version

You can

move wp-cli.phar to a global wp binary

keep a local install in you're projects root folder e.g. at /bin/wp-cli.phar

which makes sure each script continues to work on a remote installation.

Downloading core programmatically without WP-CLI

# grab and unpack the latest locale-specific release
curl https://de.wordpress.org/latest-en_GB.tar.gz -o latest-en_GB.tar.gz
tar -xvzf latest-en_GB.tar.gz
cd wordpress

5) Further reading

alternative to downloading core: the Wordpress Skeleton
applying --allow-root: php - Setting WordPress siteurl using wp-cli with WAMP virtual host - Stack Overflow
13 Useful WordPress SQL Queries You Wish You Knew Earlier