If a site launch did not complete as expected, and assistance is still needed after following the troubleshooting steps below, create a request with VIP Support to restore the site to the most recent backup.
Site Not Found error
For WordPress multisite environments, verify that the domain has been correctly entered in the Network Admin. If the domain was mapped without the
www prefix, accessing the site at www.example.com will return a “Site Not Found” error because redirects for subsites must be handled by adding custom code to the vip-config.php file.
“Site Not Found” errors can also occur for sites set up with a reverse proxy.
Incomplete search and replace for domain values
The “Site Note Found” error and other related URL issues may be caused by an incorrect or incomplete search and replace process.
When running a
search-replace process for a site launch the first parameter must match the site’s previous domain, and the latter parameter must match the newly mapped domain. The value of the newly mapped domain must match exactly what was added to the VIP Dashboard, especially the
www prefix or lack of.
For most launches, a site’s previous domain value is the convenience domain. If a site previously replaced the convenience domain with a temporary custom domain prior to launch, run the
search-replace to replace the temporary custom domain with the newly mapped domain.
Refer to the search-replace guide to format the appropriate WP-CLI command for a single site or a multisite environment, and be sure to test each command with the
--dry-run option first.
URLs not updated with launched domain
If instances of the old domain are found in the site or in the database, try flushing the object cache via VIP CLI.
VIP-CLI command examples
For demonstration purposes, the
mytestsite and the
production are used in the VIP-CLI command examples below. Read more about how to target environments in VIP-CLI commands.
The commands may need to be run with several different URL parameters to clear out any persistent objects:
vip @mytestsite.production --yes -- wp cache flush --url=mysite.go-vip.net
vip @mytestsite.production --yes -- wp cache flush --url=www.mysite.com
wp cache flush command can be run without the
--url parameter, however doing so will only flush the cache for subsite 1 of the multisite network.
vip @mytestsite.production --yes -- wp cache flush
The page cache of URLs can be cleared at the edge by running:
vip @mytestsite.production --yes -- wp vip cache purge --url=www.mysite.com
The site’s DNS records can be queried via the command line:
Example output for
$ dig wpvip.com ; <<>> DiG 9.10.6 <<>> wpvip.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16517 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;wpvip.com. IN A ;; ANSWER SECTION: wpvip.com. 3600 IN A 18.104.22.168 ;; Query time: 44 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Feb 15 13:52:48 PST 2022 ;; MSG SIZE rcvd: 54
ANSWER SECTION, the
3600 denotes the domain’s Time to Live (TTL), whereas the
A denotes the DNS record type (queries the A record by default if no type is specified in the command).
Ensure that the domain’s DNS is pointed to VIP, but that the domain’s nameservers are pointed to the DNS provider. A service like DNS Checker can be used to track progress of propagation of the domain’s updated DNS.
Unable to access the WordPress Admin
If the WordPress Admin dashboard is not accessible after launch, or the options on the dashboard appear unfamiliar or incorrect, verify that the logged in user account has a role assigned to them with sufficient capabilities. VIP-CLI can be used to run WP-CLI commands to retrieve information about a user, and if needed, update the user’s role.
For subsites on a WordPress multisite that were previously single sites, Administrators become promoted to Super Admins, which have access to all subsites and can create new subsites. These are different from site-specific Administrators, which only have admin capabilities and access for the designated sites.
Data sync does not work after a subsite launch
For subsite launches performed on multisite networks, data syncs from production environments to develop or preprod environments will continue to work as expected if the launched site is the root site (site ID 1).
If a subsite other than the root site has been launched, the YAML-based domain mapping config file must be updated in the site’s code repository to reflect the newly launched site before data syncing between environments will work as expected.
Reverse proxies can add another layer of complexity when launching multisite subsites. Investigating the specific configuration of the reverse proxy setup, including the required headers and proxy return values, will help debug any errors that may occur.