This is a follow-up task that was mentioned in #2074 (where we removed the tag default
from all core views).
Now with Views in core and also with admin_views in core, I think that it would make sense to be adding:
- a core
tag for all views provided by core
- a custom
tag for all views manually added to the site
- a %module name%
tag for all views regardless of whether they are core/contrib/custom (we currently have a "Default (module-provided)" indication in the "Storage State" column, which is not very useful, but it would be if the module providing the view was also indicated). If not a tag, this could be a new provided-by
property.
As it is now, these tags would have no value, but if we added an instant search filter at the top of the views list (#503), then it would be very useful, because as you must have also experienced yourselves, most sites end up with a few dozens of views.
Anyways, I have previously filed #1897 in which I mention the same issue. Similar/related but different problems.
Recent comments
I think Olaf's suggestion is probably best for your use case. Multiple values will be much cleaner and less error prone than a long field with multiple values. I have once enlarged a...
Expanding a field
Years later: I have been overlooking the fact that fields in content types can have more 'numbers of values'. It was hidden under 'Global settings'. Setting this to more than one I...
Views & external relational databases
Hi Egmund, I guess this is a text field, right? Instead of allowing more characters you could change the field settings to allow multiple values, so that an editor has the option to use the...
Expanding a field