Problem/Motivation

Some option fields are currently implemented as taxonomy reference or List (Text) which makes them hard to maintain/update by config. Might be better to put the management of these into a setting (textarea or similar) which is used as source. Perhaps a list field also allows to use a function as values source?

In some cases like colors it might make sense to put them into a separate dedicated small module (not theme as we don't want that large dependency) to also make them centrally available for other modules.

In general our list_string fields shouldn't use the configuration to provide the values and instead better use callbacks, so we don't need update hooks to add new values and can also delegate this to a central settings page for example (if needed).

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Anybody created an issue. See original summary.

anybody’s picture

Issue summary: View changes
anybody’s picture

Status: Active » Postponed

I'll postpone this for the future... after upgrades to 4.x are solved.

anybody’s picture

Title: Move central options from taxonomies and select lists into module settings » Move central options from taxonomies and select lists into (separate) module settings
anybody’s picture

Note to myself: Perhaps this is a better option for the future than UI: http://www.noreiko.com/blog/defining-bundle-fields-code

anybody’s picture

Title: Move central options from taxonomies and select lists into (separate) module settings » Move central options from taxonomies and select lists into (separate) module settings by callbacks
Issue summary: View changes

Lists should presumably use callbacks instead of reading the value from configuration.

anybody’s picture

@thomas.frobieter should we close this with https://www.drupal.org/project/drowl_paragraphs_bs implemented now?

anybody’s picture

Status: Postponed » Closed (won't fix)

Yes I think we can close this with _bs released.