WordPress super admin – three tables to update

I recently did a migration from a single site to a multisite here in WordPress. It was painful. But I did learn how to change the super admin login name.

The three tables are: wp_users, wp_usermeta, and wp_sitemeta

Upon creation of a brand-spanking-new WordPress multisite, wp_users has but one record in it. ID = 1, which is the super admin user. I changed the user_login field (and other fields) to the login name I wanted. WordPress “knew” that this did not qualify me to be a network admin, so it would present me with only the one site.

A little bit of searching told me that I needed to make sure that in table wp_usermeta, the field wp_capabilities was correct. Well, it was. But there were other parts of my login name that I wanted to update here. So I suppose that technically, only two fields must be updated, to swap out the super admin login name.

The last piece, that was not easy to find, was that the table wp_sitemeta has a field: site_admins which needs to have a PHP array entry in it. There was an entry in it already, but, it listed the default login ID, not the one I wanted to log in as. Because it’s an array, there is an index number, and a string length, that precede the actual data in quotes.

Once both wp_sitemeta:site_admins and wp_users:user_login both linked up, then I could log in with my preferred login ID and be super admin.

Bitnami WordPress multisite installation

Make an ssh connection in to your Bitnami server installation. I’m using AWS, and they had instructions for me to get the password / ssh private key. ssh bitnami@your-ip-address-here

cat bitnami_application_password

While logged in to the ssh session, execute the Bitnami configuration script that assigns a domain name to your WordPress multisite server.

cd /opt/bitnami/apps/wordpress

sudo ./bnconfig --machine_hostname your-domain-name-here.tld

sudo mv bnconfig bnconfig.disabled

First, we changed to the directory with the bnconfig script. Then we ran it, with the machine_hostname option. (I wanted to put a dash in there, between machine and hostname, but it’s an underscore). Lastly, we moved the bnconfig script out of the way. This is because if the server rebooted, and bnconfig did run, it would be as if it ran bnconfig –machine_hostname your-ip-address-here.xip.io

xip.io is a Bitnami thing, I guess.

Hopefully, you already have the domain name, and have pointed it at the static IP address of your server.

On to configuring WordPress the familiar way: point your favorite browser at the ip address and go to https://your-domain-name-here/wp-admin

This redirected me, but really it was the same as going to https://your-ip-address-here.xip.io/wp-login.php

Log in as user with the password from bitnami_application_password

Upon logging in, the administration page looks almost the same as a regular WordPress installation. However, in the upper left corner, there is now a menu named “My Sites”. Hanging off of it is “Network Admin”

Hanging off of “Network Admin” are a whole bunch more sub-menu items, but I’m going to ignore those for the moment.

Clicking on “Network Admin” actually takes me to the first sub-menu item: “Dashboard”

And here, I had made my life more complicated. I’m actually trying to move this site, gerisch.org to the multisite, under the same domain name. Tell me “good luck with that.” Part of the multisite login process is to redirect to the domain name – which is the production server on some other IP address.

I’m going to have to go into DNS, and point the gerisch.org at the multisite IP address, before I can successfully log in (and remain logged in) to the multisite server still being set up.

Of course, I’m going to have to export this (the production site) to a file, for importing later, prior to taking it’s presence off teh interwebs.

And I don’t know if there is going to be any weird http://www.gerisch.org versus http://gerisch.org versus https://

Yeah, “stuff” in the databases that will need to be cleaned out during export, for import later.