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
  
  @username_1'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.  
  
  ---
  
  