- Issue created by @xurizaemon
- ๐ณ๐ฟNew Zealand xurizaemon ลtepoti, Aotearoa ๐
Steps to configure term-based behaviour
- Create a content type "page"
- Create a term "page subtype"
- Add two terms, "standard" and "complex"
- Add an entity reference field "page subtype" to the page content type, referencing the term
- Add a field "complex field" to the page content type
- Configure rules so that "complex field" is shown when the term selected is "complex" (class is "selected-standard" or "selected-complex" on the node create form
- Go to node edit or node create, use term selector to determine field visibility
- @xurizaemon opened merge request.
- ๐ณ๐ฟNew Zealand xurizaemon ลtepoti, Aotearoa ๐
Adding related issue ๐ selected-xxx classes not removed on select updates Active where test coverage for fields hidden by select option conditions is added.
- ๐ณ๐ฟNew Zealand xurizaemon ลtepoti, Aotearoa ๐
What threw me about this was that the rules syntax seems to ask you to incorporate a space, OR to add an additional selector inside the square brackets.
Actual usage "in the wild" appears to be like this (now "documented" in the test coverage):
.node-page-form:[.selected-standard-page .field--name-field-intro]
This will generate:
form.advanced-form-filtered.node-page-form.selected-standard-page .field--name-field-intro { display: none; }
Which works because
.selected-standard-page
is applied to the create/edit form when term "Standard Page" is selected in a term<select>
.Without the class inside the square brackets, I found I had to include an additional space to make the selectors work, and that felt unintuitive.
Honestly the whole "rules to CSS" thing feels unintuitive and I'd probably use SASS today and keep the JS, but that's another issue.