Typically we would begin building up a site in a local server. At that point, we transfer it to an arranging webpage, and in the wake of everything are affirmed, we push the site to the live server. As basic as that sound, adding to a site can be an extremely long process. In this post, we will see how to deploy and configure these stages effectively when developing for WordPress using a handy plugin called WP Local Toolbox.
Once the plugin is activated, it exposes a number of PHP constants. To name but a few, these constants will let us know if we are currently in a live site or in local site, ensure unnecessary plugins in certain stage remain deactivated, and notify us when new content has been added in the live site.
What is an Staging Environment?
To work on a WordPress site, we recommend our users to install WordPress locally on their Windows or Mac computers. Once you are done and satisfied with your website, then you can upload it from localhost to live server.
There is one problem with this approach. What if something that worked on your localhost does not work on the live server? This would cause errors which can be a problem for established sites because it can affect search engine rankings, sales, first impression on users, etc.
Instead of uploading your changes to the live site, you can upload them to a staging site on the same server. A staging site is a separate development area on your site (usually a sub-domain) with restricted access. This is where you can test your changes or use it for all your development. Once you have thoroughly tested your site, you can then upload it to your live site.
Stage of Development
This is the place we begin. We construct our site in a localhost: a web server running in our PC. On the off chance that you are utilizing OS X, you can without much of a stretch set one up with MAMP. Windows clients have a couple of more choices, for example, MAMP (for Windows), WAMP, and XAMPP.
At this stage, you can use development tools like Codekit, and Grunt or Gulp. You can work together with your colleagues using Git version control; you can also freely conduct some experiments, and safely make errors along the way.
In the development period, I encourage you to enable the
WP_DEBUG and to install a few WordPress plugins such as Query Monitor, RTL Tester, and User Switching in addition to the plugins that we would deploy in the live site. These few extra plugins are meant to facilitate the development as well as testing process. That said, we will not activate these plugins at the staging or live site.
wp-config.php, and add the following line after
This line marks our WordPress install in localhost as “development”. When you log in to the WordPress dashboard, you will notice that the Admin bar, by default, now returns green with the server stated as
DEV SERVER. Setting it
dev enables the “Discourage search engines from indexing this site” option to prevent the site accidentally being indexed in Search Engine, although it is only accessible in our computer.
Additionally, you might also want to forcefully deactivate few plugins that are not needed during development, like the caching plugin, backup plugin and Akismet.
To do so, specify each plugin in an array with
WPLT_DISABLED_PLUGINS. define(‘WPLT_DISABLED_PLUGINS’, serialize( array( ‘w3-total-cache/w3-total-cache.php’, ‘akismet/akismet.php’, ) ));
How To set up an Staging Stage
The staging site is the place we test our site. In a perfect world it ought to be in a domain that is nearly impersonates (the content, the server particular, and so forth.) the live site to catch bugs and mistakes that we may have missed in the development stage. The webpage as a rule ought to just be open to a few individuals including the customers, to demonstrate to them the last form of the sites.
Some plugins are better deactivated such as the plugins that we have used in the development stage, a caching plugin, and a backup plugin. Staging site could be set in a subdomain, for example,
staging.coolsite.com or in a separate domain like
We define the staging site in
define(‘WP_DEBUG’, true); define(‘WPLT_SERVER’, ‘testing’); define(‘WPLT_DISABLED_PLUGINS’, serialize( array( ‘w3-total-cache/w3-total-cache.php’, ‘akismet/akismet.php’, ‘debug-bar/debug-bar.php’, ‘debug-bar-extender/debug-bar-extender.php’, ‘debug-bar-console/debug-bar-console.php’, ‘simply-show-ids/simply-show-ids.php’, ‘monster-widget/monster-widget.php’, ‘theme-check/theme-check.php’, ‘wordpress-beta-tester/wp-beta-tester.php’, ) ));
We now set the server as
testing. The Admin bar color should now turn orange.
At this stage, we can likewise deactivate a couple of plugins that we use for development. We keep a couple of other improvement plugins enacted and WP_DEBUG empowered as we have to discover lapses while testing in the arranging server.
This is the last stage where we publish our website in a live server and let everybody and anybody see the site. In this stage, we ought to additionally deactivate all the plugins for development lastly activate cashing and make a backup of all the plugins in addition to other things.
define('WP_DEBUG', false); define('WPLT_SERVER', 'live'); define('WPLT_DISABLED_PLUGINS', serialize( array( 'developer/developer.php', 'debug-bar/debug-bar.php', 'debug-bar-extender/debug-bar-extender.php', 'debug-bar-console/debug-bar-console.php', 'simply-show-ids/simply-show-ids.php', 'regenerate-thumbnails/regenerate-thumbnails.php', 'rewrite-rules-inspector/rewrite-rules-inspector.php', 'rtl-tester/rtl-tester.php', 'user-switching/user-switching.php', 'monster-widget/monster-widget.php', 'theme-check/theme-check.php', 'query-monitor/query-monitor.php', 'wordpress-beta-tester/wp-beta-tester.php', ) ));
The live stage Admin bar defaults to red (this can be changed). Keep an eye for new content in the live server to keep the testing server database updated with the new content as in the live server; it will make testing more accurate, and ensure that the new contents are displayed OK.
Add the following line in the live server
wp-config.php to do so.
Once set, we will receive notification through email when our client add new content (posts and pages) in the live server. When they do, copy the content database from live.
live server are hosted in the same server, go to phpMyAdmin. Then, select the wp_posts database and select the Operations tab. Within the Copy table to (database.table) box, select the staging site database and make sure that the Add DROP TABLE option is checked so that it will overwrite the existing database.