Answers.Body: <p>If the reason you want to delete the data is because of privacy issues, you could just scramble it. There are a few ways to do that, e.g. this extension: <a href="https://github.com/adixon/ca.civicrm.testsite" rel="nofollow">https://github.com/adixon/ca.civicrm.testsite</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-18T18:10:45.270Z
Answers.LastActivityDate: 2016-10-18T18:10:45.270Z
Answers.UserDisplayName: Alan Dixon
Answers.Body: <p>The API approach you're using is the "best" approach - but agreed it can be slow.  There are alternative approaches though:</p>
  
  <ul>
  <li>Delete all the records in <code>civicrm_contact</code> with a direct SQL call - except the default organization and logged-in user.  This will remove most of the other records (e.g. contributions) via cascading deletes.  However, it doesn't delete all records - e.g. activities.  With a similar delete of <code>civicrm_event</code>, I would usually call this "good enough", if the resulting database will never see production use.  I'd avoid this if your dev work involves reporting on activities, financial line items, or other tables that lack foreign keys.</li>
  <li>Store your CiviCRM config in code.  <a href="https://civicrm.org/blog/erikhommel/extension-to-configure-civicrm-items">CiviConfig</a> is an option; others have written a "Features CiviCRM" extension for Drupal folks, and of course you could do this with <code>hook_civicrm_managed</code>.  However, the tools for creating these configs are weak!</li>
  <li>Depending on my staging site's requirements, I'll often use a RAM disk for MySQL and store it all there.  This usually gives me a 250% speedup on API calls compared to raw SSD - if your database is stored on spinning disks the improvement will be far more dramatic.  Just remember to dump the db before shutdown!</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-18T03:07:01.327Z
Answers.LastActivityDate: 2016-10-18T03:07:01.327Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>I would like to make a copy of our production site that includes all the custom changes that we have made (fields, event templates, tags, groups, etc). I need this copy for development purposes, but do not want any of the data relating to contacts, events or contributions.</p>
  
  <p>I have tried transferring the schema and running data comparisons but I always seem to run into some sort of issue. </p>
  
  <p>Does anyone have any experience dealing with this?</p>
  
  <p>Currently I have a custom extension that makes various API calls to clear out content. This is quite slow, but seems to work.</p>
  
Tags: <migration>
Title: Copy a Sites Customizations (Custom Fields, report instances, etc)
ThreadText: # Copy a Sites Customizations (Custom Fields, report instances, etc)
  
  (Asked by: username_0 on 2016-10-17)
  
  I would like to make a copy of our production site that includes all the custom changes that we have made (fields, event templates, tags, groups, etc). I need this copy for development purposes, but do not want any of the data relating to contacts, events or contributions.
  
  I have tried transferring the schema and running data comparisons but I always seem to run into some sort of issue.
  
  Does anyone have any experience dealing with this?
  
  Currently I have a custom extension that makes various API calls to clear out content. This is quite slow, but seems to work.
  
  **Tags:** migration
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2016-10-18. Score: 4 | Accepted answer
  
  The API approach you're using is the "best" approach - but agreed it can be slow. There are alternative approaches though:
  
  * Delete all the records in `civicrm_contact` with a direct SQL call - except the default organization and logged-in user. This will remove most of the other records (e.g. contributions) via cascading deletes. However, it doesn't delete all records - e.g. activities. With a similar delete of `civicrm_event`, I would usually call this "good enough", if the resulting database will never see production use. I'd avoid this if your dev work involves reporting on activities, financial line items, or other tables that lack foreign keys.
  * Store your CiviCRM config in code. [CiviConfig](https://civicrm.org/blog/erikhommel/extension-to-configure-civicrm-items) is an option; others have written a "Features CiviCRM" extension for Drupal folks, and of course you could do this with `hook_civicrm_managed`. However, the tools for creating these configs are weak!
  * Depending on my staging site's requirements, I'll often use a RAM disk for MySQL and store it all there. This usually gives me a 250% speedup on API calls compared to raw SSD - if your database is stored on spinning disks the improvement will be far more dramatic. Just remember to dump the db before shutdown!
  
  
  ---
  
  ### Answer by username_1 on 2016-10-18. Score: 2
  
  If the reason you want to delete the data is because of privacy issues, you could just scramble it. There are a few ways to do that, e.g. this extension: <https://github.com/adixon/ca.civicrm.testsite>
  
  
  ---
  
  