I was trying to figure out a way to solve #1968, but I see no way to target all these elements effectively in a single CSS rule. It would be easy if the #states elements had a generic .has-states class and perhaps also a second class with the specific state per element case. So a .states-[state] class where [state] would be one of:
- enabled
- disabled
- required
- optional
- visible
- invisible
- checked
- unchecked
- expanded
- collapsed
- relevant
- irrelevant
- valid
- invalid
- touched
- untouched
- readwrite
- readonly
Perhaps also a .states-lvl-x class if possible (where x is the numeric level of how many parent elements the element in question has).
I would file a PR, but this touches the Field API and I am not even remotely ready for than yet, so I rely on somebody else to tackle this. Once implemented, I think it will be easy(ier) for me to sort #1968
Recent comments
Thank you very much for your fast answers and clear explanations ! I understand that the site is not corrupted and that there is no danger in leaving the code and the database in their...
Base table or view not found upgrading to 1.32.0, TRUNCATE {cache_book}
Until the official new release (coming soon), the error will ALSO show up when you clear caches, unless you fix this manually as above.
Base table or view not found upgrading to 1.32.0, TRUNCATE {cache_book}
If you want to try to fix it yourself now, I think you can manually set the schema version for the book module (in the system table) to 7000, and then try running the updates again. Test on a...
Base table or view not found upgrading to 1.32.0, TRUNCATE {cache_book}