Closed (outdated)
Project:
Drupal core
Version:
11.x-dev
Component:
forms system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
8 Apr 2010 at 08:02 UTC
Updated:
17 Apr 2025 at 15:55 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
bcn commentedScreen shot..
Comment #2
yoroy commentedNice. tagging & subscribe.
Comment #3
bcn commentedScreenshot of the other form state.
Again, this is all Nate's work, I mainly just copied and pasted from there to here.
Comment #4
amc commentedSeems like we should find a use case for this before it gets put into core. No need to add UI elements that we aren't using anywhere...
Please reopen this issue if there's general agreement on a particular place where this pattern is useful.
Comment #5
tstoecklerEhhh, this is in core.
Try adding a 'List' field to a content type. You will have to enter a list of allowed values in a weird "key|value" pair. Then apply this patch (and clear cache).
The question is rather, whether this is still possible for D7.
Comment #6
amc commentedAh. Now I see where it could be used. Not sure if this is the best UI for it, though.
Comment #7
amc commentedcorrecting tag
Comment #8
Bojhan commentedThis should have a Seven theme on the background. and a in context example.
Comment #9
yched commentedThis would indeed be an ideal UI for the 'list' field types.
[edit: hm, except that the 'Default' checkboxes wouldn't fit in this use case. In Field API / Field UI, default values are configured in a different place]
Comment #10
bcn commentedNot really.. The patch doesn't actually change anything in core to make use of the new element. So in a practical sense, it's unlikely that there's time to get this into d7.
List module does seem like the obvious candidate, but there's a good deal of changes necessary to move away from the textarea & key|value method.
@Bojan Attached are some screen's with Seven, in a potential (but not yet coded) context..
Comment #11
bcn commentedUpdated patch to latest code from options element module...
This patch also includes a dirty hack to the list module to test the options element.
Also note that I couldn't figure out how to get new files added to this patch, so they're attached (with an extra .txt extension) here and need to be dropped in the misc directory.
Comment #12
bcn commentedforgot to change status... Needs work for the changes that need to happen in list.module
Comment #13
fizk commentedWhat's the progress with this issue?
Comment #14
Bojhan commentedI wonder too, I would still like this going in.
Comment #15
simon georges commentedI suppose it's too late now that Feature Freeze has happened, isn't it?
Comment #29
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #30
smustgrave commentedSince there has been no follow up in 3 months going to close out. But don't worry this can always be re-opened!
Thanks