<p>It sounds to me like a category is what you want - you just need to expand the user's concept of what categories are for.</p>

<p>If you want the choices to appear more like a drop down, you could use <a href="https://github.com/lewisjenkins/craft-lj-dynamicfields/" rel="nofollow noreferrer">LJ Dynamic Fields</a>, but you would still probably want to use categories for the underlying choices.</p>

CC BY-SA 3.0
2017-04-21T16:45:50.337Z
Yep, this is what we ended up doing.
Mike
CC BY-SA 3.0
2017-04-21T05:22:57.943Z
2017-04-21T05:22:57.943Z
Marion Newlevant
<p>I'm not 100% I follow, so I apologize if this isn't what you are looking for. Are these values being managed/edited within the CP? Or are the editors adding these values from a front-end form?</p>

<p>A project I worked on needed a base set of values in a drop-down field for each entry. But each entry that was created by the author could have additional values (or less). The way I did this was to create a <code>table</code> field in the CP. It consisted of two columns <code>label</code> and <code>value</code>.</p>

<p>This way I could have a "default" set of values that each entry would inherit. The author could then add additional rows (or remove) as they needed.</p>

<p>In the template, I just treated the table as a drop-down (in your case it will be a multi-select).</p>

<pre><code>&lt;option value=""&gt;Select&lt;/option&gt;
    {% for option in entry.myField %}
        &lt;option value="{{ option.value }}"&gt;{{ option.label }}&lt;/option&gt;
    {% endfor %}
&lt;/select&gt;
</code></pre>

<p>Hope this helps!</p>

<p><strong>Edit/Update</strong></p>

<p>I still think if you don't want to go the category route, you could do this within a field. I've attached a screenshot of what this looked like on a similar project. The label is the left column, and the value is the right. Each row is a new value in my drop-down field that is created on the front-end.</p>

<p>By default all of these values are in the dropdown for each entry. The author can add/remove whatever they want in addition to the default data. But, whenever "New Entry" is pressed, each entry starts with the same data.</p>

<p>Where it might get tricky is if you want these added/removed values to persist from entry to entry. You'd probably have to write some sort of plugin that saved the new values back to the original field.</p>

<p><a href="https://i.sstatic.net/1kWau.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/1kWau.png" alt="enter image description here"></a></p>

CC BY-SA 3.0
2017-03-21T09:08:44.623Z
Thanks Damon. I edited the question to hopefully make it more clear as to the fact this is all about doing this in the CP. Further, the idea is to allow the editor to maintain one definitive set of values - from which they select whenever creating a new entry in the CP (which is why we're thinking categories are the only way to achieve this).
Mike
CC BY-SA 3.0
2017-03-23T18:27:32.907Z
Thanks Again Damon. You're right, we need things to persist from entry to entry but your solution might work with a plugin. However, since posting, we've set this up with categories and it seems to be working well so far. If we run into issues I didn't think about, I'll post them back here.
Mike
CC BY-SA 3.0
2017-03-23T19:19:08.863Z
Right on! Sorry I was unable to help.
Damon
CC BY-SA 3.0
2017-03-21T04:08:02.470Z
2017-03-21T17:03:07.410Z
2017-03-21T17:03:07.410Z
Damon
<p>Trying to figure out the best way of handling this scenario:</p>

<p>We have a data field for a entry type that should allow an editor in the CP to select one option from many (ie. a dropdown). However, we want to give the editors the ability to modify the options for this select list - and can't let them into a superadmin mode in the CP where they'd edit the original field parameters (if this were a dropdown field).</p>

<p>To do so, we're considering using categories. That presents easy UI in the CP to allow them to manage the list of options as needed, from which they'll select one when creating a new entry in the CP.</p>

<p>However, this piece of data isn't a category (as far as a user would think of it) so I am not certain if there is a more elegant way to handle this and avoid using categories? I looked for a field type that might do something like that but couldn't find one.</p>

<p>Thanks!</p>

<categories><drop-down>
How to create a user editable dropdown field?
# How to create a user editable dropdown field?

(Asked by: username_0 on 2017-03-20)

Trying to figure out the best way of handling this scenario:

We have a data field for a entry type that should allow an editor in the CP to select one option from many (ie. a dropdown). However, we want to give the editors the ability to modify the options for this select list - and can't let them into a superadmin mode in the CP where they'd edit the original field parameters (if this were a dropdown field).

To do so, we're considering using categories. That presents easy UI in the CP to allow them to manage the list of options as needed, from which they'll select one when creating a new entry in the CP.

However, this piece of data isn't a category (as far as a user would think of it) so I am not certain if there is a more elegant way to handle this and avoid using categories? I looked for a field type that might do something like that but couldn't find one.

Thanks!

**Tags:** categories, drop-down

---

## 2 answers

### Answer by username_1 on 2017-04-21. Score: 0 | Accepted answer

It sounds to me like a category is what you want - you just need to expand the user's concept of what categories are for.

If you want the choices to appear more like a drop down, you could use [LJ Dynamic Fields](https://github.com/lewisjenkins/craft-lj-dynamicfields/), but you would still probably want to use categories for the underlying choices.

> **Comments:**
> **username_0**: Yep, this is what we ended up doing.  

---

### Answer by username_2 on 2017-03-21. Score: 0

I'm not 100% I follow, so I apologize if this isn't what you are looking for. Are these values being managed/edited within the CP? Or are the editors adding these values from a front-end form?
A project I worked on needed a base set of values in a drop-down field for each entry. But each entry that was created by the author could have additional values (or less). The way I did this was to create a table field in the CP. It consisted of two columns label and value.
This way I could have a "default" set of values that each entry would inherit. The author could then add additional rows (or remove) as they needed.
In the template, I just treated the table as a drop-down (in your case it will be a multi-select).
Select
    {% for option in entry.myField %}
        {{ option.label }}
    {% endfor %}


Hope this helps!
Edit/Update
I still think if you don't want to go the category route, you could do this within a field. I've attached a screenshot of what this looked like on a similar project. The label is the left column, and the value is the right. Each row is a new value in my drop-down field that is created on the front-end.
By default all of these values are in the dropdown for each entry. The author can add/remove whatever they want in addition to the default data. But, whenever "New Entry" is pressed, each entry starts with the same data.
Where it might get tricky is if you want these added/removed values to persist from entry to entry. You'd probably have to write some sort of plugin that saved the new values back to the original field.

> **Comments:**
> **username_0**: Thanks Damon. I edited the question to hopefully make it more clear as to the fact this is all about doing this in the CP. Further, the idea is to allow the editor to maintain one definitive set of values - from which they select whenever creating a new entry in the CP (which is why we're thinking categories are the only way to achieve this).  
> **username_0**: Thanks Again Damon. You're right, we need things to persist from entry to entry but your solution might work with a plugin. However, since posting, we've set this up with categories and it seems to be working well so far. If we run into issues I didn't think about, I'll post them back here.  
> **username_2**: Right on! Sorry I was unable to help.  

---

