With choices, you have a setting to allow multiple selections. I don't know the intent behind the design of custom taxonomies, but I see this as essentially creating reusable choices fields. Constraining choices to a single selection allows for setting the front matter field to a string or an array of strings. Taxonomies should give you similar control over the resulting field type.
With choices, you have a setting to allow multiple selections. I don't know the intent behind the design of custom taxonomies, but I see this as essentially creating reusable choices fields. Constraining choices to a single selection allows for setting the front matter field to a string or an array of strings. Taxonomies should give you similar control over the resulting field type.
<!-- github-sync-id:1120643633 -->
The difference between custom taxonomy fields and choice fields is that taxonomy fields allow you to add new values and allow to store these. So you could start with an empty list, and let it fill up over time.
The limit on the taxonomy fields is a great new enhancement.
The difference between custom taxonomy fields and choice fields is that taxonomy fields allow you to add new values and allow to store these. So you could start with an empty list, and let it fill up over time.
The limit on the taxonomy fields is a great new enhancement.
<!-- github-comment-id:1027670887 -->
You will now be able to specify the taxonomyLimit field property on your tags, category, and custom taxonomy fields in order to limit the number of options you can select.
You will now be able to specify the `taxonomyLimit` field property on your tags, category, and custom taxonomy fields in order to limit the number of options you can select.
<!-- github-comment-id:1043817768 -->
This is a great enhancement, as a CMS requires user inputs to match rules in the code. As a further enhancement, it may be beneficial to allow setting the type to a string or an array. Because this is a developer concern, it may be good enough to assume that a limit of a single selection would be a string. A markdown front-matter structure has limited data types available, and I believe that enforcing a data type would make this more robust. Target parsers will output data differently based on these types. Thanks!
This is a great enhancement, as a CMS requires user inputs to match rules in the code. As a further enhancement, it may be beneficial to allow setting the type to a string or an array. Because this is a developer concern, it may be good enough to assume that a limit of a single selection would be a string. A markdown front-matter structure has limited data types available, and I believe that enforcing a data type would make this more robust. Target parsers will output data differently based on these types. Thanks!
<!-- github-comment-id:1046998565 -->
Enhanced the field to show the limit

<!-- github-comment-id:1050611891 -->
@johnfuller the further enhancement on the taxonomy field makes sense indeed, I'm not sure if the right way to output a string when the limit is set to 1 is the best option here. Maybe an extra setting is required to specify its type.
@johnfuller the further enhancement on the taxonomy field makes sense indeed, I'm not sure if the right way to output a `string` when the limit is set to `1` is the best option here. Maybe an extra setting is required to specify its type.
<!-- github-comment-id:1050614430 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
With choices, you have a setting to allow multiple selections. I don't know the intent behind the design of custom taxonomies, but I see this as essentially creating reusable choices fields. Constraining choices to a single selection allows for setting the front matter field to a string or an array of strings. Taxonomies should give you similar control over the resulting field type.
The difference between custom taxonomy fields and choice fields is that taxonomy fields allow you to add new values and allow to store these. So you could start with an empty list, and let it fill up over time.
The limit on the taxonomy fields is a great new enhancement.
You will now be able to specify the
taxonomyLimitfield property on your tags, category, and custom taxonomy fields in order to limit the number of options you can select.This is a great enhancement, as a CMS requires user inputs to match rules in the code. As a further enhancement, it may be beneficial to allow setting the type to a string or an array. Because this is a developer concern, it may be good enough to assume that a limit of a single selection would be a string. A markdown front-matter structure has limited data types available, and I believe that enforcing a data type would make this more robust. Target parsers will output data differently based on these types. Thanks!
Enhanced the field to show the limit
@johnfuller the further enhancement on the taxonomy field makes sense indeed, I'm not sure if the right way to output a
stringwhen the limit is set to1is the best option here. Maybe an extra setting is required to specify its type.It would break my code if an array data type output a string instead of an array with a single element.