Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Entity render controllers and form controllers are not responsible for checking view and edit access on the entity. Calling code needs to do that where appropriate.
So then, why should formatters and widgets be responsible for checking field access? For symmetry, shouldn't that be the caller's responsibility?
Comment | File | Size | Author |
---|---|---|---|
#1 | field_decouple_access.patch | 3.17 KB | effulgentsia |
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedStarter patch for field_attach_*(). Not sure how to handle field_view_field() and field_view_value() yet: should that implement the access check or make it the caller's responsibility? For symmetry with node_view(), I'm leaning towards it also being the caller's responsibility.
Comment #3
yched CreditAttribution: yched commentedHmmm. Not sure about that one. Those two are what we recommend for "display one off values" near the theme layer (tpls or preprocess).
FWIW, I didn't look very deeply into it, but I'd like to move those to view() methods on the Field (field_view_field()) / FieldItem (field_view_value()) classes at some point.
Just sayin' - not sure how that informs the decision here :-)
Also, the effect of the patch is that render arrays are not generated at all if field_access is denied - unlike current HEAD where it's just #access = FALSE. This might possibly impact the feasibility of a render cache ? Also, means $render_array['field_foo'] cannot be trusted to be present, which might be considered a DX pain in some places (alters, render($render['foo']) in templates) ?