FWIW your reported experience following you manual install is the intention of our server. But as per your initial report it seems it's not working as expected. I have since played with WordPress a ton more and have made some discoveries.

I'll explain a little more below, but first I have a number of questions, which will give me a better understanding:

• When you say "I installed WP from wordpress.org", do you mean you manually downloaded the WP zip (or similar) and unpacked it to the server and used the interactive install via your web browser?
• Assuming so, did the manual install ask you to set a domain? Regardless, did it only work on the domain/IP (e.g. localhost) you set or used when installing before replacing the wp-config.php with ours?
• When using alternate IPs/domains, do all assets (e.g. javascript. css, images, posts, etc) are loading properly when using a different IP/domain?

Following on from that last question, it would be awesome if you could run this test for me. Try using your (self installed) WordPress server via a different domain/IP and open the web dev tools. Then browse around your site, visiting different posts and pages and check in the dev console for any 404 (not found) errors? I'd love to get a better understanding of how it's working on your system.

Context

As you can imagine, our install needs to be automated and for many years, we have generated a custom "tkl-install.php" install script that does the install for us. It's based on the manual install, but with prefilled values that we provide at build time - and are then updated on firstboot.

However, when I recently rebuilt it (for v18.1 update release), I discovered that there were some negative implications of not setting a static domain/IP. During testing I found that some of the assets were missing. IIRC it was mostly images, but it also appear to affect new user added pages/posts.

On closer inspection, using browser web dev console in my browser there were some 404 (not found) errors for some assets and pages. It seems that in some cases 'example.com' is stored as the domain if it hasn't explicitly been set. New posts/pages appear to be saved with a full URL path (inc domain) used at time of creation and saved in the DB. I spent a ton of time trying to make it work properly with a dynamic domain/IP address. But I couldn't get it to work consistently and reliably.

Following some research I discovered that the way that the WordPress architecture is designed, it actually relies on a hard coded domain/IP for some specific parts to work as expected. Technically there shouldn't be a requirement for that, but due to design decisions made many year ago that's how it is.

So after a ton of time testing, tweaking and researching, I decided to cut my losses and require a static IP/domain to be set in the firstboot scripts for our next release. For local use and/or development a dummy domain or IP address can be used and added your local hosts file, pointing to your server's IP. I haven't actually tested it, but using a domain of 'localhost' should work when running on your local system.

To change the domain in the upcoming release, you will be able to rerun the WordPress firstboot script.

Our WordPress firstboot script leverages the wp-cli tool's "search/replace" feature to replace all the hardcoded URLS in the database. More correctly, it uses our 'turnkey-wp' wrapper/helper script. FYI 'turnkey-wp' runs as the webserver users and does not change any file/folder permissions when used. Note that 'turnkey-wp' in earlier releases has some shortcomings and has been updated for the new (upcoming) v18.1 release.

Note that our firstboot script to change domain will only work reliably if you haven't changed the domain via any other method since firstboot. That is because every time the firstboot script is run, it caches the new domain that you set.

When it's rerun, it searches the DB for the cached domain and replaces instances with the new domain. So if the domain has been changed via another method, the cached domain won't be correct. The search-replace then won't work as expected and will likely make no changes, leaving the DB (and therefore the current domain) as it was.

I need to update the documentation to reflect that as well as usage of 'turnkey-wp. Regardless please ask if you want any further info and/or assistance. Hopefully I'll be able to quarantine some time each week to reply to forum posts.