<p>Let's start by saying what you <strong>don't</strong> want to do...</p>

<ul>
<li>Don't use Matrix blocks to solve this problem. As you mentioned, the Matrix field would get pretty crazy, and you couldn't prevent people from using the wrong blocks in the wrong places.</li>
<li>Don't use Globals to solve this problem. Global fields get loaded automatically on every page load, so you're bound to add a lot of extra page weight that doesn't need to be there.</li>
</ul>

<p>To me, it sounds like <strong>entry types</strong> are the perfect solution. You can have multiple entry types which all share the same fields, but then add extra fields to the entry types which specifically need them. If I'm understanding your problem correctly, it's exactly what entry types were created to solve.</p>

<p>Lastly, you mention needing a Channel or Structure to use entry types. This is 100% true, but it makes me wonder... Are you currently just using Singles? If you're currently using Singles, then this should be a non-issue... each Single is basically a unique entry type anyway.</p>

<p>Hope that helps, let me know if I missed something.</p>

CC BY-SA 3.0
2016-06-29T03:12:12.500Z
2016-06-29T03:12:12.500Z
Lindsey D
<p>Consider a site with a very flat hierarchy that has a lot of basic pages. Most pages on the site are extremely similar, so they can all share the same entry type (and thus, fields) without problems.</p>

<p>The problem is, there are a few pages that have <em>wildly</em> unique content layouts. There's special content that will only ever be used on these pages.</p>

<p>From my understanding, there's a few solutions to this:</p>

<ul>
<li>Use a Matrix field in the Page entry type and add a block for each special page you need. This lets you build the unique pages, but for the dozens of other "normal" pages it becomes very weird and unnatural (plus there's nothing stopping the client from erroneously adding the 'special page' Matrix blocks on non special pages).</li>
<li>Using multiple entry types, but this is also a bit clunky and would mean have to using a Channel or Structure.</li>
<li>Use Global sets (one for each special page). Also a bit of a dirty workaround.</li>
</ul>

<p>Is there a cleaner way to achieve "one-off" fields that are used only by a specific entry? </p>

<p>Another CMS - Bolt - has a solid solution to this: <a href="https://docs.bolt.cm/2.2/templates/building-templates#template-specific-fields" rel="nofollow">Template Specific Fields</a>. As another example: using WordPress with ACF, you can assign field layouts on a per-entry basis if required.</p>

<p>I was hoping something similar could be achieved in Craft.</p>

CC BY-SA 3.0
2016-06-29T06:24:37.583Z
Maybe this plugin could support you as well: https://github.com/mmikkel/Reasons-Craft This hides or shows fields based on a lightswitch. This could be practical to further increase usability in your case.
KSPR
<entries><field>
Defining fields on a per-entry basis?
# Defining fields on a per-entry basis?

(Asked by: username_0 on 2016-06-29)

Consider a site with a very flat hierarchy that has a lot of basic pages. Most pages on the site are extremely similar, so they can all share the same entry type (and thus, fields) without problems.

The problem is, there are a few pages that have *wildly* unique content layouts. There's special content that will only ever be used on these pages.

From my understanding, there's a few solutions to this:

* Use a Matrix field in the Page entry type and add a block for each special page you need. This lets you build the unique pages, but for the dozens of other "normal" pages it becomes very weird and unnatural (plus there's nothing stopping the client from erroneously adding the 'special page' Matrix blocks on non special pages).
* Using multiple entry types, but this is also a bit clunky and would mean have to using a Channel or Structure.
* Use Global sets (one for each special page). Also a bit of a dirty workaround.

Is there a cleaner way to achieve "one-off" fields that are used only by a specific entry?

Another CMS - Bolt - has a solid solution to this: [Template Specific Fields](https://docs.bolt.cm/2.2/templates/building-templates#template-specific-fields). As another example: using WordPress with ACF, you can assign field layouts on a per-entry basis if required.

I was hoping something similar could be achieved in Craft.

**Tags:** entries, field
> **Comments:**
> **username_1**: Maybe this plugin could support you as well: https://github.com/mmikkel/Reasons-Craft This hides or shows fields based on a lightswitch. This could be practical to further increase usability in your case.  

---

## 1 answers

### Answer by username_2 on 2016-06-29. Score: 3

Let's start by saying what you **don't** want to do...

* Don't use Matrix blocks to solve this problem. As you mentioned, the Matrix field would get pretty crazy, and you couldn't prevent people from using the wrong blocks in the wrong places.
* Don't use Globals to solve this problem. Global fields get loaded automatically on every page load, so you're bound to add a lot of extra page weight that doesn't need to be there.

To me, it sounds like **entry types** are the perfect solution. You can have multiple entry types which all share the same fields, but then add extra fields to the entry types which specifically need them. If I'm understanding your problem correctly, it's exactly what entry types were created to solve.

Lastly, you mention needing a Channel or Structure to use entry types. This is 100% true, but it makes me wonder... Are you currently just using Singles? If you're currently using Singles, then this should be a non-issue... each Single is basically a unique entry type anyway.

Hope that helps, let me know if I missed something.


---

