Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The docs say:
* @param $variables
* An associative array containing:
* - label_hidden: A boolean indicating to show or hide the property label.
* - title_attributes: A string containing the attributes for the title.
* - label: The label for the property.
* - content_attributes: A string containing the attributes for the content's
* div.
* - content: The rendered property value.
* - attributes: A string containing the attributes for the wrapping div.
but 'content' is not respected.
Comment | File | Size | Author |
---|---|---|---|
#1 | 2109825.entity.theme_entity_property-content.patch | 588 bytes | joachim |
Comments
Comment #1
joachim CreditAttribution: joachim commentedComment #2
claudiu.cristeaYes, it's so weird that the properties content its actually prepared in theme layer. Shouldn't take place in the 'build' phase
hook_entity_view()
orEntityAPIControllerInterface::buildContent()
? And then the theme engine should receive the already built content that it can alter in process/pre-process phase.Comment #3
claudiu.cristeaComment #4
claudiu.cristeaWorks nice for me. RTBC but still think that the property values must be prepared in the 'buildContent' phase. I opened a ticket for that in #2361465: Property values to be built in the 'build' phase (not in theme).
Comment #6
fagoThanks - committed. I agree with #4 - but that seems to be a worthwhile fix meanwhile anyways.
Comment #8
Jelle_SFYI: This commit is not backwards compatible, this broke something on a production site of ours.
We had a preprocess function that ran before
template_preprocess_entity_property
and themed dates as formatted dates (instead of a timestamp) and stored it in$variables['content']
. Took me a while before I found what was wrong. Now the preprocess function stores it in$element['#content']
. I hope this helps others who might experience the same problem.