Answers.Body: <p>Staff changes should happen on the live server.  This is doubly true if you have any public-facing pages, which will mean the database on the live server is updated by members of the public.</p>
  
  <p>Traditionally, <em>code</em> travels from dev to staging to prod.  <em>Data</em> travels from live to dev/staging.</p>
  
  <p>I prefer referring to "dev/test/live" server, since this better illustrates the flow, and is less jargon-y to non-tech staff.</p>
  
  <p>Some changes don't flow well this way - for instance, you may want to create a contribution page on your test server, then transfer it to live.  In practice, this should be relatively infrequent, and you can redo your work on the live server.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-25T21:10:03.093Z
Answers.LastActivityDate: 2017-10-25T21:10:03.093Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>Key is configuration...</p>
  
  <p>I do a straight file copy (can use git as well to deploy with a CI if you want...).</p>
  
  <p>Important files are configuration... you can set your location dependent settings in</p>
  
  <pre><code>/Library/WebServer/Documents/ccfrdev2/wp-content/plugins/civicrm/civicrm.settings.php
  </code></pre>
  
  <p>Wordpress is wordpress... so moving the wordpress part is pretty well documented. The database side is straight forward with Civi... just copy the database (re-import) ... the settings are in the settings file. </p>
  
  <p>I save the settings file, copy the entire site, replace the settings file... then manage the URLs ... then bob's your uncle... You could automate it somewhat with git and a CI if you prefer, but it is so simple I just hack at it at the command line... </p>
  
  <p>Hope this helps.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-07T01:12:55.083Z
Answers.Text: Thank you. My upvote should appear here as soon as my reputation allows it. :)
Answers.UserDisplayName: asciimo
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-26T00:58:28.047Z
Answers.LastActivityDate: 2017-10-26T00:58:28.047Z
Answers.UserDisplayName: Serge
Body: <p>I'm setting up a new CiviCRM and web site on WordPress. I'm used to working on dev/staging sites and pushing changes to production after they are tested and approved. What's the best way to do this with CiviCRM on WordPress? Here's what I would do without any advice:</p>
  
  <h2>Setup</h2>
  
  <ol>
  <li>Install WordPress and CiviCRM fresh on the production site.</li>
  <li>Make a complete copy of the filesystem and database to create a staging site</li>
  <li>Globally replace domain names in WP and CiviCRM files and DB tables, using guidance from the <a href="https://docs.civicrm.org/sysadmin/en/latest/misc/staging-production/" rel="nofollow noreferrer">docs</a> and 
  <a href="https://civicrm.stackexchange.com/questions/9756/how-should-i-copy-a-site-from-production-to-staging">this answer</a>.</li>
  </ol>
  
  <h2>Deployment</h2>
  
  <p>At this point, should staff use CiviCRM in production, or on staging? I think WordPress changes should be made on staging, and pushed to production. Maybe CiviCRM changes should be made in production and synced to staging? Should everything be done on staging, and then deployed by reversing the Setup steps? </p>
  
Tags: <wordpress><deployment>
Title: Staging and Production with WordPress
ThreadText: # Staging and Production with WordPress
  
  (Asked by: username_0 on 2017-10-25)
  
  I'm setting up a new CiviCRM and web site on WordPress. I'm used to working on dev/staging sites and pushing changes to production after they are tested and approved. What's the best way to do this with CiviCRM on WordPress? Here's what I would do without any advice:
  
  ## Setup
  
  1. Install WordPress and CiviCRM fresh on the production site.
  2. Make a complete copy of the filesystem and database to create a staging site
  3. Globally replace domain names in WP and CiviCRM files and DB tables, using guidance from the [docs](https://docs.civicrm.org/sysadmin/en/latest/misc/staging-production/) and
     [this answer](https://civicrm.stackexchange.com/questions/9756/how-should-i-copy-a-site-from-production-to-staging).
  
  ## Deployment
  
  At this point, should staff use CiviCRM in production, or on staging? I think WordPress changes should be made on staging, and pushed to production. Maybe CiviCRM changes should be made in production and synced to staging? Should everything be done on staging, and then deployed by reversing the Setup steps?
  
  **Tags:** wordpress, deployment
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-10-25. Score: 1 | Accepted answer
  
  Staff changes should happen on the live server. This is doubly true if you have any public-facing pages, which will mean the database on the live server is updated by members of the public.
  
  Traditionally, *code* travels from dev to staging to prod. *Data* travels from live to dev/staging.
  
  I prefer referring to "dev/test/live" server, since this better illustrates the flow, and is less jargon-y to non-tech staff.
  
  Some changes don't flow well this way - for instance, you may want to create a contribution page on your test server, then transfer it to live. In practice, this should be relatively infrequent, and you can redo your work on the live server.
  
  
  ---
  
  ### Answer by username_2 on 2017-10-26. Score: 1
  
  Key is configuration...
  I do a straight file copy (can use git as well to deploy with a CI if you want...).
  Important files are configuration... you can set your location dependent settings in
  /Library/WebServer/Documents/ccfrdev2/wp-content/plugins/civicrm/civicrm.settings.php
  
  Wordpress is wordpress... so moving the wordpress part is pretty well documented. The database side is straight forward with Civi... just copy the database (re-import) ... the settings are in the settings file. 
  I save the settings file, copy the entire site, replace the settings file... then manage the URLs ... then bob's your uncle... You could automate it somewhat with git and a CI if you prefer, but it is so simple I just hack at it at the command line... 
  Hope this helps.
  
  > **Comments:**
  > **username_0**: Thank you. My upvote should appear here as soon as my reputation allows it. :)  
  
  ---
  
  