Due to the risk of duplicate rendering and negative performance impact we currently have this:
/**
* Ensure $value is rendered.
*
* Helper function to ensure the given value is rendered to be able
* to check its real contents.
* See core issue
🌱
[meta] Themes improperly check renderable arrays when determining visibility
Needs work
for details.
*
* @param mixed $value
*
* @return string
*
* @throws \Drupal\twig_real_content\Exceptions\TwigRealContentException
*/
protected function ensureRendered($value) {
// The following would allow us to render the content given,
// but that would lead to hidden performance implications,
// so until now we decided not to do this.
// Perhaps we could combine the implementation with
// https://www.drupal.org/project/twig_capture and only run it
// if enabled later on.
// if (is_array($value)) {
// // Return early if the element is empty:
// if (Element::isEmpty($value)) {
// return '';
// }
// return \Drupal::service('renderer')->render($value);
// }
if (!is_string($value) && !$value instanceof MarkupInterface) {
throw new TwigRealContentException('"Twig Has Content Filter" expects rendered strings as value, ' . gettype($value) . ' given. Did you forget to |render / capture the twig variable before?');
}
return $value;
}
and disallow use on render arrays. If we combine this with https://www.drupal.org/project/twig_capture → optionally or find any other solution, we might also allow this directly on unrendered render arrays.
A further benefit could be to use Element::isEmpty() before rendering the array at all and return early, if the element is detected as empty?
Run |real_content directly on a render array
TBD
TBD
None
None
None
Active
1.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I think allowing this when twig_capture is available would be a simple solution. That's what it's for.
Also note "As rendering a render array multiple times has negative impact on performance," is not the full extent of the problem, once again https://www.drupal.org/project/twig_capture → lists some actual bugs you can hit besides performance which the render cache might or might not mitigate -- but the bugs are real.