You are here
Jimmi - Mon, 2024/07/01 - 05:14
I wanted to use TKL to customize the WP Twenty Twenty Four theme during my spare time anywhere.
I installed in Virtualbox the Wordpress appliance, upgraded Debian and Wordpress and connected to the server from /localhost
When I try to use the Theme Block Editor of Wordpress I always get problems in the visualization: sometime the central screen remains blank, sometime the header or part of the theme are not shown.
As suggested I used for the VM 2GB of RAM and 2 processors. I also tested Virtualbox on different PC and different OS: Win 11 and Ubuntu. The result is always the same.
Is there anything I may test or change in the VM to fix or improve the issue?
Forum:
Hi Jimmi, thanks for starting a new thread.
I had intended to reply on your intro post, but ran out of time. Regardless, it's better for your question/issue to be in it's own thread anyway.
My first suspicion is that it's because we don't set an explicit domain. It just uses whatever you put in the address bar. Historically that has always worked and in theory should still work fine, but I've recently noticed that it doesn't always work reliably.
So the thing to do would be set set 'localhost' as your domain in the wp-config.php file. Unfortunately, I don't have the details handy and I have to go now. But I'll try to get back ASAP.
If you see this before I get back, that might even be enough info for you to work it out?
Thanks for the reply :-)
Thanks for the reply :-)
While I was waiting I installed another VM using Debian 12 standard basic install and adding Maria DB and Apache2 on top of them. I them installed WP from wordpress.org and I copied your wp-config.php in it to have the address managed dynamically. With this installation everything woks like a charm, no problem at all.
I may try to change the address in your installation, shall I change the following lines?
Apologies (again) for late reply
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:
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.
Thanks Jeremy for the
BTW when the change you
Add new comment