Answers.Body: <p>There are a few approaches, none perfect. It would be great to be able to export config of entities and load that into another site / instance.</p>
  
  <ol>
  <li><p>It's possible to write code to generate the various entities using the CiviCRM API. This can work, but probably has higher up-front time costs than option 4 below. It's what I'd most likely do if I wanted to be able to test the deployment of changes and had a medium-scale budget.</p></li>
  <li><p>CiviCRM offers a hook (<a href="https://docs.civicrm.org/dev/en/master/hooks/hook_civicrm_managed/" rel="nofollow noreferrer"><code>hook_civicrm_managed()</code></a>) which you could use to configure your site with the various entities mentioned. This has some challenges, eg it "locks" the managed entities to the extension in question - disabling that extension in future might then remove the managed membership type, potentially affecting recorded memberships and so forth. (I'm not sure whether editing managed entities is permitted, either?)</p></li>
  <li><p>It's possible to export the SQL entries which relate to the specific values you want, but you'd need to match up the IDs for the entities (memberships, contribution pages, price sets and options etc) on loading. Kinda ugly.</p></li>
  <li><p>You can click your way through the config. I'd guess you're asking this because you think there should be a more reliable way to deploy configuration ... as of today, I don't think there is. This is your low budget option.</p></li>
  </ol>
  
  <p>One important factor is that these entities may need to be created in a specific order to handle dependency, since the priceset / options may relate to the membership type, and that membership type may relate to an organisation contact, and ...</p>
  
  <p>This is a question which has been asked before, but IMO hasn't as yet been solved well. These previous SE questions might offer some insight?</p>
  
  <ul>
  <li><a href="https://civicrm.stackexchange.com/questions/6652/how-can-civicrm-manage-and-deploy-configuration">How can CiviCRM manage and deploy configuration?</a></li>
  <li><a href="https://civicrm.stackexchange.com/questions/4466/what-are-best-practices-for-deploying-changes">What are best practices for deploying changes?</a></li>
  <li><a href="https://civicrm.stackexchange.com/questions/7268/advice-on-moving-civicrm-configuration-only-when-launching-a-new-site">Advice on moving CiviCRM Configuration only when launching a new site</a></li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-05T03:36:28.087Z
Answers.Text: https://github.com/xurizaemon/civicrm-configexport is some work we did a few years back to explore configuration export / import. I don't recommend it as a complete solution, just linking it here in case it gives you or someone else a starting point. This might be the starting point for a "we have heaps of budget" option 
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-06T04:10:08.253Z
Answers.Text: It looks like #4 will be the way I will go. I caught the database problem before getting a lot of membership signups but recreating the membership types and contribution pages will be a PITA! I was able to transfer the Joomla parts of the site using a nice little utility named J2XML which exports/imports almost everything in Joomla to/from XML files. All that needs to be done manually is the Joomla menus and the CiviCRM stuff. Maybe the way J2XML does it could work?
Answers.UserDisplayName: Paul Andreassen
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-06T08:41:32.310Z
Answers.Text:   if you like, the github repo linked above your comment is pretty much  an example of C2YML (vs J2XML). On the project we built it for, we discovered that the dependency issues mean you'd need to map out all the potential dependency trees of Civi entities in order to reliably export any Civi entity. It works - but there's legwork to do to make it do a complete job, and for now it depends on the user knowing *a lot* about Civi's internals in order for the tool to function effectively.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-07T01:56:05.490Z
Answers.Text: Thanks. Probably easier just to build what I need from scratch.
Answers.UserDisplayName: Paul Andreassen
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-05T03:27:56.153Z
Answers.LastActivityDate: 2017-03-05T03:46:03.043Z
Answers.LastEditDate: 2017-04-13T12:53:13.207Z
Answers.UserDisplayName: Chris Burgess
Body: <p>I am rebuilding a Joomla website with a corrupt database. I would like to recreate the CiviCRM structures in the new website. That would include membership types, price sets and contribution pages.</p>
  
Tags: <export>
Title: I need to export or copy CiviCRM structures such as membership types, contribution pages and price sets to another website (Joomla)
ThreadText: # I need to export or copy CiviCRM structures such as membership types, contribution pages and price sets to another website (Joomla)
  
  (Asked by: username_0 on 2017-03-04)
  
  I am rebuilding a Joomla website with a corrupt database. I would like to recreate the CiviCRM structures in the new website. That would include membership types, price sets and contribution pages.
  
  **Tags:** export
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-03-05. Score: 1
  
  There are a few approaches, none perfect. It would be great to be able to export config of entities and load that into another site / instance.
  
  1. It's possible to write code to generate the various entities using the CiviCRM API. This can work, but probably has higher up-front time costs than option 4 below. It's what I'd most likely do if I wanted to be able to test the deployment of changes and had a medium-scale budget.
  2. CiviCRM offers a hook ([`hook_civicrm_managed()`](https://docs.civicrm.org/dev/en/master/hooks/hook_civicrm_managed/)) which you could use to configure your site with the various entities mentioned. This has some challenges, eg it "locks" the managed entities to the extension in question - disabling that extension in future might then remove the managed membership type, potentially affecting recorded memberships and so forth. (I'm not sure whether editing managed entities is permitted, either?)
  3. It's possible to export the SQL entries which relate to the specific values you want, but you'd need to match up the IDs for the entities (memberships, contribution pages, price sets and options etc) on loading. Kinda ugly.
  4. You can click your way through the config. I'd guess you're asking this because you think there should be a more reliable way to deploy configuration ... as of today, I don't think there is. This is your low budget option.
  
  One important factor is that these entities may need to be created in a specific order to handle dependency, since the priceset / options may relate to the membership type, and that membership type may relate to an organisation contact, and ...
  
  This is a question which has been asked before, but IMO hasn't as yet been solved well. These previous SE questions might offer some insight?
  
  * [How can CiviCRM manage and deploy configuration?](https://civicrm.stackexchange.com/questions/6652/how-can-civicrm-manage-and-deploy-configuration)
  * [What are best practices for deploying changes?](https://civicrm.stackexchange.com/questions/4466/what-are-best-practices-for-deploying-changes)
  * [Advice on moving CiviCRM Configuration only when launching a new site](https://civicrm.stackexchange.com/questions/7268/advice-on-moving-civicrm-configuration-only-when-launching-a-new-site)
  
  > **Comments:**
  > **username_1**: https://github.com/xurizaemon/civicrm-configexport is some work we did a few years back to explore configuration export / import. I don't recommend it as a complete solution, just linking it here in case it gives you or someone else a starting point. This might be the starting point for a "we have heaps of budget" option   
  > **username_0**: It looks like #4 will be the way I will go. I caught the database problem before getting a lot of membership signups but recreating the membership types and contribution pages will be a PITA! I was able to transfer the Joomla parts of the site using a nice little utility named J2XML which exports/imports almost everything in Joomla to/from XML files. All that needs to be done manually is the Joomla menus and the CiviCRM stuff. Maybe the way J2XML does it could work?  
  > **username_1**:   if you like, the github repo linked above your comment is pretty much  an example of C2YML (vs J2XML). On the project we built it for, we discovered that the dependency issues mean you'd need to map out all the potential dependency trees of Civi entities in order to reliably export any Civi entity. It works - but there's legwork to do to make it do a complete job, and for now it depends on the user knowing *a lot* about Civi's internals in order for the tool to function effectively.  
  > **username_0**: Thanks. Probably easier just to build what I need from scratch.  
  
  ---
  
  