Turns out it was not as easy as I first thought.
First, let’s define the environment:
- OpenSUSE 42.3 in a virtual machine
- Downloaded and copied into the machine:
- bitnami-wordpress-4.9.8-0-linux-x64-installer.run
- KVM / QEMU with sudo virsh snapshot-create-as every step of the way.
I should point out that during the install, it asked me where to put the web site. I told it /opt/bitnami
So actually, the WordPress code is in /opt/bitnami/apps/wordpress
Note that this is for the files on disk; it has nothing to do with the URL scheme.
The installer does it’s thing, and I get a WordPress site running on the URL scheme <ip address>/wordpress/
Irritation for me is, the production web site I’m wanting to experiment for is <ip address>/
Five changes are needed for the fix.
- Search and replace the database
- Edit the /opt/bitnami/apps/wordpress/conf/httpd-prefix.conf file
- Edit the /opt/bitnami/apps/wordpress/htdocs/wp-config.php file
- Edit the /opt/bitnami/apps/wordpress/conf/httpd-app.conf file
- Settings –> Permalinks –> Save Changes
Search and replace the database
Before, I was using the All-In-One WP Migration plugin, because it came with the Bitnami image, and, at a WordPress meetup I went to, the people there said this was a great way of doing a development site. And it was, for a while.
Problem is, the All-In-One WP Migration guy decided to change the rules, and the latest update refuses to work unless you pay up, for any site larger than 40MB. I’ve never seen a site less than 200MB, so that’s a no-go for me.
I’ve been using UpdraftPlus for backups (for free), and decided that it wouldn’t hurt to pay them for some of their premium services, which were advertised as also being able to do migration. Turns out that isn’t nearly as easy as it was with All-In-One WP Migration, but it can be wrestled to the ground and made to work, with a bit of effort.
Anyway: Settings –> UpdraftPlus Backup –> Advanced Tools –> Search / replace database. Search for /wordpress and replace with /
Note that you do not want to restart services after the search-and-replace but before the file editing below.
Edit httpd-prefix.conf
The httpd-prefix.conf file is explained here: Move WordPress to a different URL path on the same domain
The change is that the Alias setting goes from /wordpress/ to simply /
Edit wp-config.php
The wp-config.php file gets edits, so that
define(‘WP_SITEURL’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/wordpress/‘);
define(‘WP_HOME’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/wordpress‘);
define(‘WP_SITEURL’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/‘);
define(‘WP_HOME’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/‘);
Edit httpd-app.conf
The httpd-app.conf file gets edits, so that
RewriteBase /wordpress/
RewriteRule . /wordpress/index.php [L]
RewriteBase /
RewriteRule . /index.php [L]
Save Permalinks
One thing I learned during this whole ordeal, is that the Save Permalinks action creates a new .htaccess file for you, which I needed before the root /wordpress/ URL would go away.
Gotcha’s
One thing that caused me quite a bit of trouble is that just doing the edits of the files was not enough; but I didn’t know that. After doing the edits of the files (only), the WordPress Admin site worked fine. But every attempt to go to any of the content resulted in a 500 internal server error.
By the way, the WordPress community and debugging tools truly suck to help one figure out what’s wrong here. But that’s a rant for a different post.
So I thought my migrations were failing because I couldn’t get to my content after migration. But really, because I had a default-out-of-the-box installation, I never tried to check the First Post comment or any of the other links. I made the changes to httpd-prefix.conf and wp-config.php and the Admin site worked fine. After the restore, I could log in to the Admin site (with the password from the production site), and that worked fine.
But my content was always broken, and I didn’t know it until I stripped down everything back to the most rudimentry snapshot I took before I edited anything.