How Wordpress nearly killed me.

It's October 2018, I haven't slept for 3 months. We have just delivered two multisite network sites which include a total of 160 subsites. At this point, I never want to look at WordPress again.

Rewind 4 years and I had just agreed to work on our first website in Wordpress. I had spent the previous decade avoiding it like the plague. I had been curious a couple of times but each time I would become frustrated within minutes of trying to use it and it would be closed down with extreme prejudice.

The deciding factor was the number of people who needed help with updating their existing websites. Updating in every sense of the word. Themes and plugins, as well as updating their design and making them responsive. Enough of the history lesson, back to July 2018.

By complete coincidence, we were speaking to two franchise businesses who needed new websites for their networks 90 & 70 respectively.

First thing first. Wordpress is not cloud-native. It’s designed to live and be connected to the disk where the install files live. So when you’re trying to use con owners on Google Kobe notes you have to jump thrown a lot of hoops to make it work. We lost days of time trying to figure out the most basic issues.

Unsurprisingly there was very little information or guidance on how to proceed if you're reading this because you're in the same position we were. I'd suggest you hastily reconsider Wordpress multisite as a solution to building a network of sites.

But if you are a sadist then proceed but also note this experience was so bad that we spent the last year building Nocode as therapy.

So let us save you some sleepless nights. Serialised data.

Many Wordpress themes + plugins use serialised data.to save their settings in single database fields in Wordpress. When you are spinning up new instances of WP with different domains the standard procedure is to use find and replace in the entire database. But unless you know about deserialising serialised data before you find + replace. You'll be banging your head against the wall for a very long time.

Once you've got the database under control and arranged your disk storage in an efficient manner you then move on to designing the website that is easy to update and accommodate the data from hundreds of different websites.

Due to having some experience with the DIVI theme we decided to use this for both projects. The main advantage of DIVI is its very easy to use front-end editor. However, using this for the reason of making the site easy to update was wrong. Primarily because the actual users of the websites only need to create a few different custom post types only. The second problem with DIVI in multisite (this has now been rectified with the new DIVI theme builder) is DIVI saves the theme settings for each subsite, but by creating a ridiculous mess of MySql commands to update each site. This was mind-numbing.

After what felt like a year both projects were completed! Yay!!

But… then a whole other bunch of issues came to light.

When the project started there was a clear definition of what would be central content + what would be local content for each site. This is where the flexibility of DIVI is a liability because as soon as the clients got their hands on the system they diverged multiple subsites and we had to find another solution to be able to make charges cross the entire network of sites.

Enter the Broadcast plugin. This lets you broadcast pages + posts from one site to all or any subsites.