<p>You can get the fields that aren’t in use anywhere by running this SQL query:</p>

<pre class="lang-sql prettyprint-override"><code>SELECT f.*
FROM craft_fields f
LEFT JOIN craft_fieldlayoutfields l ON l.fieldId = f.id
WHERE l.id IS NULL
</code></pre>

<p>The easiest way to delete them would be from the Control Panel, but if you really want to limit your work to the database, you would need to delete those fields’ rows in <code>craft_fields</code>, and their corresponding column (“field_TheFieldHandle”) in <code>craft_content</code>. For Matrix fields, you would also need to drop the corresponding DB table (“craft_matrixcontent_TheFieldHandle”).</p>

CC BY-SA 3.0
2014-10-11T16:09:34.313Z
2014-10-11T16:09:34.313Z
Brandon Kelly
<p>I have one section with different <a href="http://buildwithcraft.com/docs/sections-and-entries#entry-types" rel="nofollow">entry types</a>. One entry type uses two matrix fields, another one only one, and so on.</p>

<p>Since the frontend layout is always the same, I use one template for the whole section: </p>

<pre class="lang-twig prettyprint-override"><code>{% extends "_layouts/main" %}

{% set title = entry.title %}

{% block content %}
    {% include "_fields/content__circles" %}
    {% include "_fields/content__body" %}
    {% include "_fields/content__links" %}
{% endblock %}
</code></pre>

<p>This works great, except when I change an entry to another entry type: Because the field-data isn't deleted from the db and shows up anyway, even though the field isn't added to the new entry type.</p>

<p>This is actually great, because that way your data isn't gone if you delete a field by mistake etc., but over time the db gets bloated, which I want to prevent.</p>

<p><strong>Question:</strong> How can I delete data of fields which aren't used without editing each entry by hand or going in the db?</p>

<p><strong>Clearification:</strong> entrytype 1 has <code>content__circles</code> and <code>content__body</code>, entrytype 2 has only <code>content__body</code>. After switching from type 1 to 2, the data of <code>content__circles</code> is still kept in the database, and is even accessible inside the <code>entry</code>-variable.</p>

CC BY-SA 3.0
2014-10-10T17:25:34.083Z
@DouglasMcDonald I'm not sure it's the same question. He's talking about swapping entry types, not field types.  But I'm still confused what the OP is asking. Can you clarify some more, Victor?
Brad Bell
CC BY-SA 3.0
2014-10-10T20:18:17.357Z
@BradBell I added edited the question, is it clearer now?
Victor
CC BY-SA 3.0
2014-10-11T04:21:36.170Z
I think so... if there is a common field between entry types, then they'll share the same data by design. All of that data (for every entry type a section has) is stored in the craft_content table, so I don't think there is "bloat" where you think there is, unless I'm missing something.
Brad Bell
CC BY-SA 3.0
2014-10-11T05:05:11.383Z
@BradBell You're right brad. Sorry. Completely miss read that. I deleted my comments to avoid confusion.
Douglas McDonald
CC BY-SA 3.0
2014-10-11T13:29:41.633Z
@BradBell But after switching the entry-type why is it still available in the `entry`-object? The field had content in entrytype1, but this field isn't available anymore in the entrytype2, so shouldn't the old field-data be excluded/deleted?
Victor
<entries><database><field>
How to clear the database of unused fields?
# How to clear the database of unused fields?

(Asked by: username_0 on 2014-10-10)

I have one section with different entry types. One entry type uses two matrix fields, another one only one, and so on.
Since the frontend layout is always the same, I use one template for the whole section: 
{% extends "_layouts/main" %}

{% set title = entry.title %}

{% block content %}
    {% include "_fields/content__circles" %}
    {% include "_fields/content__body" %}
    {% include "_fields/content__links" %}
{% endblock %}

This works great, except when I change an entry to another entry type: Because the field-data isn't deleted from the db and shows up anyway, even though the field isn't added to the new entry type.
This is actually great, because that way your data isn't gone if you delete a field by mistake etc., but over time the db gets bloated, which I want to prevent.
Question: How can I delete data of fields which aren't used without editing each entry by hand or going in the db?
Clearification: entrytype 1 has content__circles and content__body, entrytype 2 has only content__body. After switching from type 1 to 2, the data of content__circles is still kept in the database, and is even accessible inside the entry-variable.

**Tags:** entries, database, field
> **Comments:**
> **username_1**: @DouglasMcDonald I'm not sure it's the same question. He's talking about swapping entry types, not field types.  But I'm still confused what the OP is asking. Can you clarify some more, Victor?  
> **username_0**: @BradBell I added edited the question, is it clearer now?  
> **username_1**: I think so... if there is a common field between entry types, then they'll share the same data by design. All of that data (for every entry type a section has) is stored in the craft_content table, so I don't think there is "bloat" where you think there is, unless I'm missing something.  
> **username_2**: @BradBell You're right brad. Sorry. Completely miss read that. I deleted my comments to avoid confusion.  
> **username_0**: @BradBell But after switching the entry-type why is it still available in the `entry`-object? The field had content in entrytype1, but this field isn't available anymore in the entrytype2, so shouldn't the old field-data be excluded/deleted?  

---

## 1 answers

### Answer by username_3 on 2014-10-11. Score: 7

You can get the fields that aren’t in use anywhere by running this SQL query:
SELECT f.*
FROM craft_fields f
LEFT JOIN craft_fieldlayoutfields l ON l.fieldId = f.id
WHERE l.id IS NULL

The easiest way to delete them would be from the Control Panel, but if you really want to limit your work to the database, you would need to delete those fields’ rows in craft_fields, and their corresponding column (“field_TheFieldHandle”) in craft_content. For Matrix fields, you would also need to drop the corresponding DB table (“craft_matrixcontent_TheFieldHandle”).


---

