Recently, we made the switch from WP Engine to WPMUDev, migrating most of our hosted clients along with us. The transition has been relatively smooth, but as we familiarize ourselves with the new environment and its capabilities, we’ve encountered some unexpected hiccups. One such challenge is with the staging site on WPMUDev.

There have been three main challenges we’ve faced with the staging setup. While these challenges may not be significant for everyone, they posed an issue for us. Thus, we wanted to share our experiences and solutions, providing guidance for those encountering similar problems.

This article addresses the first issue we encountered: multi-site staging.

Multi-Site Staging

The initial issue we ran into was the lack of changes to the blog URLs for multi-sites. While the main URL was updated, allowing access to the site admin, any additional sites remained with their original URLs.

Unlike WPEngine, which automatically incorporates the staging environment URL into all multi-site URLs, WPMUDev does not perform such a rewrite. Consequently, without manual adjustments, users are redirected to the production environment for all sites except the main one.

For sporadic use of the staging environment, manually updating the URLs in the database might suffice. However, for us, conducting monthly updates on numerous sites, some of which are multi-sites, this manual process became time-consuming.

As a wise lead developer once said, “Why spend five minutes every month when you can automate it in an hour?” Automating this process would streamline the transition between production and staging, eliminating the need for developers to ensure the environment’s functionality before commencing work.

To address this, we integrated the functionality into our Pie Plugin, which was already deployed across many of our sites. Leveraging the plugin’s deployment system facilitated the quick and efficient release of this feature. Once deployed, it would automatically update across all sites, simplifying the process for our team.

   function update_domain_mapping() {
       $sites         = get_sites();
       $main_site_url = get_site_url( 1 );


       $main_site_url = str_replace( 'http://', '', $main_site_url );
       $main_site_url = str_replace( 'https://', '', $main_site_url );


       foreach( $sites as $site ){
           $site_id  = absint( $site->blog_id );
           $site_url = $site->domain;


           if ( 1 === $site_id || strpos( $site_url, 'staging.tempurl.host' ) ) {
               continue;
           }


           $site_domain = $site_url . '.' . $main_site_url;
           $site_url    = 'https://' . $site_url . '.' . $main_site_url;
           update_blog_details( $site_id, array(
               'domain' => $site_domain,
               'path'   => '/',
           ));
           update_blog_option( $site_id, 'siteurl', $site_url );
           update_blog_option( $site_id, 'home', $site_url );
       }
   }

This code, encapsulated within an ‘if’ statement to ensure it only operates on multi-site staging setups, automates the URL updates. With this solution in place, whenever production is synchronised into staging, the process is executed seamlessly. Developers can dive straight into site checks and debugging without any additional setup.

While developing this solution, we sought assistance from WPMUDev’s support team, who directed us to their staging setup documentation. However, this documentation lacked specific guidance on the necessary updates, prompting us to craft our solution.

This instance highlighted a rare shortcoming in WPMUDev’s documentation, prompting the need for this blog article. We hope that by sharing our experience, we can assist others grappling with multi-site staging transitions on WPMUDev.