Category: WordPress

WordPress multisite and Let's Encrypt certificates for multiple sites

I’m using the Bitnami images for my WordPress installations, and am very happy with them. However, it got a little weird when I added a new site to my WordPress multisite instance.

The secret was to run a few commands by hand:

sudo /opt/bitnami/ctlscript.sh stop apache
sudo /opt/bitnami/letsencrypt/lego  --path="/opt/bitnami/letsencrypt/" --email="david@some-domain-name-i-am-not-publishing-here" --domains="gerisch.org" --domains="www.gerisch.org" --domains="test.gerisch.org" --http run
sudo /opt/bitnami/ctlscript.sh start apache

Earlier, I had run the Bitnami bncert-tool which wrangled my Apache configuration so that all attempts to go to an http:// address were re-written to go to an https:// address. This is very good. But when I added the test.gerisch.org web site, the certificate provided by Let’s Encrypt did not have a SAN (Subject Alternative Name) entry for “test”. So trying to visit that site got the ominous “this site is insecure – nothing provides for an SSL certificate for it”. True enough.

By running the /opt/bitnami/letsencrypt/lego script with multiple –domains arguments, I could update the requested certificate to have the additional SANs I wanted. Very nice. It was the Bitnami community support web site that gave me this information. The same page warns me that more than five requests for new certificates puts the certificate issuer into a time-out corner for one week. So that is something to be aware of.

All-in-One WP Migration prior to being crippled by it's authors

Newer versions of the WordPress plugin All-in-One WP Migration have been re-written to refuse to work if the migration file is larger than 512MB. The plugin has been deliberately crippled to induce you to pay for an upgrade that unlocks larger file sizes.

One thing that is (in my opinion) a little sleazy is that the export function will create and download any size file you have. It’s only after you need to import that you get mugged for the upgrade.

The nice lady at https://marionblackonline.com/all-in-one-wp-migration-plugin-hack/ showed how to get the old version of the All-in-One WP Migration plugin. Version 6.77, although it has the artificial limit, can be edited to a different limit. Getting the file is slightly opaque, as the plugin page on wordpress.org does not let you go back that far, version -wise. But the file is on the servers, and downloadable.

https://downloads.wordpress.org/plugin/all-in-one-wp-migration.6.77.zip

Once you’ve installed it (by uploading it from a .zip file instead of from the WordPress Plugins store), WordPress will constantly nag you to update to the crippled version. Edit the file wp-content/plugins/all-in-one-wp-migration/all-in-one-wp-migration.php and change the Version string to an impossibly high number.

As long as you are editing files, you might as well edit wp-content/plugins/all-in-one-wp-migration/constants.php

Original file size limit: 

define( 'AI1W†M_MAX_FILE_SIZE', 2 << 28 );

Make it your preferred file size limit:

define( 'AI1WM_MAX_FILE_SIZE', 4294967296 ); // 4 GB file size limit

Bitnami WordPress automatic start of services

First off, KVM and QEMU are wonders of technology, and I’m thankful for those projects and their magic.

Background is that I made a default install of OpenSUSE 42.3.  I also tried OpenSUSE 15 (which is newer than 42.3, but whatever).

OpenSUSE 15 really did not like the Bitnami invocation of MySQL; but, it could be that I tried the initial install as a LAMP server, running at level 3.  With OpenSUSE 42.3, I tried an initial install as a KDE Desktop running at level 5, plus the LAMP server pattern.  That had worked in the past, so I wasn’t going to fight “well, at least this works”.

I did get the Bitnami stack installed and running.  I even got the default URL changed from “/wordpress/” to just “/”

Next step to accomplish, so I have a nice snapshot to revert to, is for the Bitnami stack to automatically start.  For whatever reason, searching for this information never easily comes up with results.  So I’m writing it down here.

cp installdir/ctlscript.sh /etc/init.d/bitnami-APPNAME

Edit the file /etc/init.d/bitnami-whatever-you-named-it

Add this near the top:

#
# chkconfig: 2345 80 30
# description: Bitnami services

And run this:

chkconfig --add bitnami-whatever-you-named-it

Test with an init 6, and if you can get to your web site without having to start MySQL and Apache with the ctlscript.sh, then you’re good.

Take that snapshot!

How I moved a local development Bitnami WordPress to the root of the web server

What it took to move WordPress from /wordpress to just /

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.