With our control panel's WordPress Toolkit tool, you can easily create a parallel staging site version for your WordPress web hosting. This enables, among other things, updating the site in its separate development version - and easily bringing changes to the public site version.
To use the staging feature, your web hosting must have WordPress installed that is linked to
WordPress Toolkit (either by installing it directly through WordPress Toolkit or by linking a manual installation to it using the Scan function).
In addition, you need disk space for the staging site version. This is recommended to be implemented in a subdomain of your main domain (e.g., staging.yourdomain.com)
according to these instructions. Alternatively, the staging site can also be installed directly in a subdirectory of the main domain (e.g., yourdomain.com/staging).
Next, you can proceed to create a staging version from the production WordPress installation by clicking 'WordPress' -> 'Clone' from the control panel:
From the pop-up window, select 'Use an existing domain or subdomain' and select the subdomain address you created earlier (in the example 'staging.hostaan.help');
The control panel may also pre-fill "staging" as a subdirectory for security reasons (to avoid overwriting with the application installed on the main domain). If you use a subdomain (e.g., staging.yourdomain.com), you can remove this subdirectory, but if you implement staging directory on the main domain (yourdomain.com/staging), the subdirectory must be left in place so that your production site is not overwritten by the staging version.
Press 'Start' and the control panel clones the site content and database to your specified destination and then returns to the WordPress Toolkit view, which now has a parallel WordPress installation. You can now freely perform necessary development and update work on the staging site without affecting the actual production site:
By default, search engine indexing is disabled for the staging site, but if you wish, you can further restrict access to the staging site with the 'Password protect' function, which prevents public access to the site while still allowing you to log in to the WordPress admin interface.
Importing staging site changes to production environment
When development work has been done on the staging site and changes have been confirmed to work, you can import updates and customizations to the production version by selecting 'WordPress' from the main menu and 'Copy Data' for your staging site:
From the pop-up window, select your main domain (e.g., yourdomain.com) as the target, where the production version of the site is located. In this context, you can also select in exceptional situations which parts of the site are transferred, but typically the selections can be at their default values. The function also backs up a restore point of your site, so there should be enough free disk space available.
In the 'Select database tables to copy' section, WordPress's postmeta, posts, usermeta, and users tables are excluded by default. In this case, content changes and new user accounts that have come to the production version will not be overwritten in these parts, but during the import phase, only WordPress, plugin, and theme updates and other possible changes (for example, to the appearance) are imported from the staging site. This is the recommended import method in cases where the staging site is used only for testing and implementing WordPress updates, appearance changes, or introducing new features - and actual content production happens directly in the production version.
If, on the other hand, you have implemented new content on the staging site that you want to bring to the published site, you can then uncheck "Except for: wp_postmeta, wp_posts, wp_usermeta, wp_users".
NOTE! Using the staging feature with these settings is only suitable for a site where all production site content can be overwritten. For example, this setting should not be used as is for an online store or blogs with comments, because orders, registrations, and comments made by visitors will be overwritten and lost.
As a third option, you can also select "Only new tables" or "Selected tables" (and define the tables to import). For example, you can specify that only the contents of wp_posts and wp_postmeta tables are imported, but the contents of wp_users and wp_usermeta tables are not imported. Or you can leave, for example, wp_comments and wp_commentmeta tables unoverwritten (or, for example, the contents of WooCommerce online store or other plugin tables you use). By excluding tables from import that are updated on the published site by user action, the staging feature can be used selectively and carefully considered even in online stores and actively commented blogs.
During copying, WordPress Toolkit creates a restore point (the checkbox must be checked in 'Create restore point'), so if something goes wrong, you can return to the previous situation.
After pressing 'Start', the staging site content is transferred to the production main domain and the changes you made to the staging site are published. In the future, you can work so that you make updates and customizations directly to the staging site version and bring them to the public site with the Copy Data function at the publication stage. Depending on the type of site and the selected database import settings, you can also switch to producing content through the staging site if desired.
NOTE! Copying a WordPress site can in some cases cause the target site to break, as in larger changes, such as changing an entire theme or replacing a significant number of plugins, overwriting may not be the most suitable solution. In this case, it makes most sense to completely remove the old target site in production through WordPress Toolkit and clone a new staging site from a clean slate to the target location.
