Some more learnings on the GoDaddy Managed WordPress platform... This is our SOP (standard operating procedure) for deploying websites and maintaining them.
More details on all-important staging functionality on GoDaddy Managed WordPress is here: https://ca.godaddy.com/…/what-are-staging-environments-12292
Staging environments are only available on Deluxe, Ultimate, and Developer plans.
This is the suggested development lifecycle we follow:
1. Pull your production site to the staging environment to create an up to date snapshot staging site before any development is commenced. This way you are ensured of having a complete repository of content. Note: "overwrite content" checkbox will destroy any content or settings on your staging site.
2. Develop and test your site in the staging environment. Distribute only the staging link to ensure the latest version is being reviewed by the customer. All user accounts will be sync'd with the production website.
3. Once a set of improvements or features are ready on staging Push your staging environment to production. Note: "overwrite content" checkbox will destroy any content or settings on your production site. This includes widget settings, menu options and configuration options well beyond posts and pages. You must ensure that any new content published on the production site is exported and then imported into staging manually. You can use the standard WordPress export/import features of WordPress to migrate posts, pages and any other custom post types or content.
4. Test the production system with the changes introduced. If there are any settings that were set in production that have not been carried over to staging they will need to be reset on staging and pushed to production.
TODO AFTER TESTING:
Make sure these 2 directives are set and uncommented into the production wp_config.php file:
// this turns off the file editor in production as a security precaution
define( 'DISALLOW_FILE_EDIT', true );
// this turns of DEBUG messages
define( 'WP_DEBUG', false );
We set these settings to ensure admins on production cannot edit any child theme files or any other files. This is a small security precaution as well. The file editor in WordPress can be a very dangerous thing in the wrong hands.
We turn of DEBUG messages to ensure PHP/WordPress generated errors are not shown to end users. We enable both settings on staging.
The timing of a staging->production deployment should be done after the daily backup has completed at 4am Eastern. The deployment window is 5-7am Sunday morning to ensure a full backup is available before a staging deployment occurs.
Repeat steps 2-4 when you need to develop your site further.
NOTE: Any Posts/Pages/Comments/Events/Custom Post Types created on production may have to be manually transferred manually or via export/import to staging after the initial pull done in step 1.
EMERGENCY NOTES: If production is damaged in anyway or partially completes, you must restore using the Backups->Restore Type Files & Database option to switch back to the last snapshot (from 4am of the current day). This rolls back the production site to the last known previous stable version, enabling another attempt at a deployment from a known quality version.
Thanks so much for the process. I have a question for you on #3.
"3. Once a set of improvements or features are ready on staging Push your staging environment to production. Note: "overwrite content" checkbox will destroy any content or settings on your production site. This includes widget settings, menu options and configuration options well beyond posts and pages. You must ensure that any new content published on the production site is exported and then imported into staging manually. You can use the standard WordPress export/import features of WordPress to migrate posts, pages and any other custom post types or content."
If you do a pull from production before each development cycle and do a push when testing is done, it should be OK to check "Overwrite Content" correct? There shouldn't be anything new on production that has to be exported/imported separately, or am I reading this incorrectly?
@prosper_dev - this is the assumption I was making too -- just do a production pull to staging, but the issue is really timing and changes made in production in the meantime. If your production system does not change in any way you should be able to create a fresh staging system, make changes and push them. In my experience though this is just not the case for any amount of time more than a few days.
Production changes are inevitable, and the staging -> production with "overwrite content" checked effectively destroys the production system. Any changes you made in production after you do the pull to staging will be erased only recoverable with a backup restore.
In many production systems, there are minimum blog posts entered during the development cycle going on staging, so the export/import to staging is required to essentially sync content + new dev changes on staging which will all be transferred to production during a push.
You really want to experiment with this before you actually use it for real to get a hang of it. If you do it wrong, it's a bit of a mess
We are developing an entirely new WordPress site. I would like to use the staging feature but also want to make sure that when I go from staging to production 100% of the production environment is removed. No old database, etc. Like it was a brand new site. Is staging good for this or am I better off with building a new site independent of GoDaddy hosting. Killing the current site and then importing what was developed outside of GoDaddy and making it the production site. I would use a plugin called UpDraft for all of this. Export/Import
@ck-4XOA - the full production environment is updated with the staging ONLY if overwrite content is selected. That means all content, pages, plugin content -- ALL of it erases the production site. Any changes left on production that are NOT on staging are removed.
Technically speaking that's a full overwrite. Whether byte for byte they are identical after the staging->production push I could not tell you, but I do know OVERWRITE CONTENT is effective.
If you don't OVERWRITE CONTENT then no database changes in terms of content perspective are pushed and only code level changes are made (any .php files, new/updated plugins and themes). In fact any plugin configuration changes, widget changes in staging are also NOT transferred to production. That tells me no database updates are mode when OVERWRITE CONTENT is NOT checked.
I want to clone an existing WordPress site that I have in a subfolder of the root to another subfolder so that I can rebuild and test before changing the main site. I want the original to keep working and I will use a test domain for building the new site. Has anyone else done that? If so, what are the steps?
Step 1: Save a copy of the original wordpress site
Step 2: Create a new WordPress install in the subfolder of the root for testing
Step 3: Once the new WP Install completes OVERWRITE the wp-content folder with the backup
Step 4: Import Database into phpmyadmin
Step 5: Update URL in phpmyadmin to the new subfolder URL
Step 6: Log In and Start Working!
I pulled production to staging and then back after changes were made and unable to login as admin on live site? I had to do a back up back to the previous version as several attempts to get in as admin were unsuccessful with the error ''you are not allowed to access this area''.
How can I resolve this as it seems not to be recognising me as admin?
Hi- This is the first time I'm using WordPress, and have a couple questions I hope someone could answer for me.
My client currently has a Godaddy hosted website, let's call it domain.com, but are looking to convert it to a WordPress site. What they would like to do is test and prepare their new WordPress site in the background before making it live, and then flipping the switch for domain.com to look at WordPress when they're ready.
I see inside the Godaddy panel that I can install Wordpress into a certain domain. How/what paths would I have to select to have Wordpress install into a "temporary" location that can be accessed by something like wordpress.domain.com or domain.com/wordpress. I can't take down their current site, and I need to somehow in Godaddy change the pointer for where the live site is once it's ready. Is this possible?
Thanks for any help you can provide!
I have a website (domain.com) for which we are getting a new design. We want the new design to be updated in a subfolder (domain.com/domain1) so that we could test before we move it to domain.com.
But, I am unable to do so on our subdomain, though the same design is working in some other domains.
Background: My plan
Windows web hosting plan with PHP version 5.3
Website is on Wordpress