Answers.Body: <p>Your extension needs to include an Upgrader class containing an <code>uninstall</code> function. In there you can use the api to delete the custom fields and custom group. Generate the Upgrader class in civix using the command:</p>
  
  <pre><code>civix generate:upgrader
  </code></pre>
  
  <p>Read more documentation on this at <a href="https://docs.civicrm.org/dev/en/master/extensions/civix/#add-a-database-upgrader-installer-and-uninstaller" rel="nofollow noreferrer">https://docs.civicrm.org/dev/en/master/extensions/civix/#add-a-database-upgrader-installer-and-uninstaller</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-28T01:02:44.980Z
Answers.LastActivityDate: 2017-01-28T01:02:44.980Z
Answers.UserDisplayName: Coleman
Answers.Body: <p>@coleman's answer is accurate, but there are less manual ways to approach this. See Tim's post <a href="https://civicrm.org/blog/totten/api-and-the-art-of-installation" rel="nofollow noreferrer" title="CiviCRM blog">API and the Art of Installation</a>, which outlines the use of <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/hook_civicrm_managed" rel="nofollow noreferrer" title="CiviCRM wiki"><code>hook_civicrm_managed</code></a> as well as a <code>civix</code> helper/naming convention *.mgd.php. Here's an <a href="https://github.com/civicrm/org.civicrm.volunteer/blob/012b9347b7abf94177a0f8b41b612fd683961a0c/CRM/Volunteer/Form/VolunteerReport.mgd.php" rel="nofollow noreferrer" title="CiviVolunteer GitHub">example</a> in CiviVolunteer, though it's for a different entity.</p>
  
  <p>If you're adding custom tables, you may wish to avail yourself of another <code>civix</code> helper/naming convention. Your extension's <code>Upgrader</code> class automatically scans for files named <code>*_uninstall.sql</code> in the extension's sql directory when the extension is uninstalled. Here's another CiviVolunteer <a href="https://github.com/civicrm/org.civicrm.volunteer/blob/012b9347b7abf94177a0f8b41b612fd683961a0c/sql/volunteer_uninstall.sql" rel="nofollow noreferrer" title="CiviVolunteer GitHub">example</a>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-31T20:35:31.777Z
Answers.Text: That said, I don't think I've tried this the `managed` approach with entities that depend on one another. Maybe naming them so that they run in the right order (e.g., 001_customGroups.mgd.php, 002_customFields.mgd.php) will work, but I haven't tried it.
Answers.UserDisplayName: universalhandle
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-31T20:33:23.260Z
Answers.LastActivityDate: 2017-01-31T20:33:23.260Z
Answers.UserDisplayName: universalhandle
Body: <p>As the developer of an extension that creates its own custom fields, what can I do to cause those custom fields to be removed when the extension is uninstalled?</p>
  
Tags: <custom-fields><extension><developer>
Title: Can an extension remove its custom fields on uninstall?
ThreadText: # Can an extension remove its custom fields on uninstall?
  
  (Asked by: username_0 on 2017-01-27)
  
  As the developer of an extension that creates its own custom fields, what can I do to cause those custom fields to be removed when the extension is uninstalled?
  
  **Tags:** custom-fields, extension, developer
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-01-28. Score: 2 | Accepted answer
  
  Your extension needs to include an Upgrader class containing an uninstall function. In there you can use the api to delete the custom fields and custom group. Generate the Upgrader class in civix using the command:
  civix generate:upgrader
  
  Read more documentation on this at https://docs.civicrm.org/dev/en/master/extensions/civix/#add-a-database-upgrader-installer-and-uninstaller
  
  
  ---
  
  ### Answer by username_2 on 2017-01-31. Score: 2
  
  @coleman's answer is accurate, but there are less manual ways to approach this. See Tim's post [API and the Art of Installation](https://civicrm.org/blog/totten/api-and-the-art-of-installation "CiviCRM blog"), which outlines the use of [`hook_civicrm_managed`](http://wiki.civicrm.org/confluence/display/CRMDOC/hook_civicrm_managed "CiviCRM wiki") as well as a `civix` helper/naming convention \*.mgd.php. Here's an [example](https://github.com/civicrm/org.civicrm.volunteer/blob/012b9347b7abf94177a0f8b41b612fd683961a0c/CRM/Volunteer/Form/VolunteerReport.mgd.php "CiviVolunteer GitHub") in CiviVolunteer, though it's for a different entity.
  
  If you're adding custom tables, you may wish to avail yourself of another `civix` helper/naming convention. Your extension's `Upgrader` class automatically scans for files named `*_uninstall.sql` in the extension's sql directory when the extension is uninstalled. Here's another CiviVolunteer [example](https://github.com/civicrm/org.civicrm.volunteer/blob/012b9347b7abf94177a0f8b41b612fd683961a0c/sql/volunteer_uninstall.sql "CiviVolunteer GitHub").
  
  > **Comments:**
  > **username_2**: That said, I don't think I've tried this the `managed` approach with entities that depend on one another. Maybe naming them so that they run in the right order (e.g., 001_customGroups.mgd.php, 002_customFields.mgd.php) will work, but I haven't tried it.  
  
  ---
  
  