In OpenBSD fashion, this is not going to be a copy-pasta recipe for installing WordPress on OpenBSD and having no idea how you got there. Instead, it aims to be a self-help guide, addressing the common gotchas you are likely to encounter.
We won’t go through the stuff that works easily (acme-client(1), package installation, etc). You already know where to find that info!
Here are the issues you may encounter that are not so intuitive.
I look forward to suggestions/corrections to any fallacies I’m spreading!
Using links like index.php?p=1 or sticking everything under /posts/ are not viable permalink solutions. c’mon, this isn’t the Arch linux wiki!
Unfortunately, there seems to be an issue (still present as of 6.5), that prevent at least one needed CGI variable to be passed from httpd.
Luckily the fix from Tim Baumgard still works on -current: https://github.com/tbaumgard/openbsd-httpd-rewrite
You may also need to fiddle with your location and match directives, so that wp-admin gets rewritten to wp-admin/index.php and that the php files are passed to the fastcgi socket.
Keep an eye on your rewrites between upgrades and know where to look when they stop working.
Where Nginx will detect and serve static files, you will likely need to stop httpd sending them all to PHP. location match directives for CSS, image types, fonts, etc telling them not to be rewritten is my solution, but produces unwieldly httpd.conf files.
If you’re developing a theme/plugin and need to symlink it to various sites, ensure it’s accessible within www’s chroot and link to it relatively. ie, there is probably no /home/bobina/myplugin/ within your /var/www/ dir.
If working on multiple sites, you’ll likely be including them from the main httpd.conf file. What you may not realise is that the default timeout settings, even if not present in the main conf file, are not able to be overridden in the included confs.
Use an IP vs localhost or a socket to make life easier.
Don’t forget that your website knows nothing outside of it’s chroot (even if PHP-FPM still does). So hosts and resolv.conf are likely needed to be copied to your chroot, easy to forget after updating/switching network configs.
Much easier than in sudo land, allow your user to run WP-CLI as www. For DB touching commands, it’s less of a concern, but when you action filesystem changes as a non-web user, you can face unexpected permissions issues.