Thanks - is there any way we can present this with a checkboxes instead of a text field?
Possibly, though with checkboxes for each field that could become a UX concern with many fields. But to your point there is likely room for improving both the UX and the validation of the new form element.
Updating patch to correct missing use statement for FormStateInterface.
Here is a patch which adds an option to the Views argument to exclude field names from the argument's subquery.
coderdan → created an issue.
Thanks @jurgenhaas! I tested this on both a fresh D10 site with version 2.0 of ECA, and a production site using 1.1.5.
coderdan → created an issue.
coderdan → created an issue.
The patch in #2 prevents targeting elements outside of the time_wrapper sub-element, such as the 'make recurring' checkbox. This patch should solve for that by removing the time_wrapper as the sole parent for all elements.
coderdan → created an issue.
Attaching patch for convenience/composer purposes.
This patch is working for us, thank you.
This issue is stemming from the core change that introduced "preconfigured fields" back in D8. See https://www.drupal.org/project/drupal/issues/2446511 → .
Since ERwH is dependent on entity_reference_revisions, but not overriding the getPreconfiguredOptions() method, ERwH is picking up the preconfigured field settings from ERR, which cause these "duplicate" fields.
To reproduce the issue:
- Perform a fresh install of Drupal 9 using standard install profile
- Install the latest version entity_reference_hierarchy
- Visit /admin/structure/types/manage/article/fields/add-field
- In the 'Add new field' select list, under the 'Reference' section, see that there are two entries for 'Content', 'Taxonomy term', and 'User' entity types.
coderdan → created an issue.
Adding a patch which builds on asherry's solution to include tests.
Regarding refactoring (ie: comment #7). While I agree a refactor is in order here, it is my opinion that this would be somewhat dangerous to do given the existing lack of test coverage. I would propose working on tests first before refactoring takes place.