If we allow post-processing of fully rendered renderable arrays this interferes with plans for Twig drillability - #2008450: Provide for a drillable variable structure in Twig templates.

CommentFileSizeAuthor
#1 2009132-1.patch1.09 KBthedavidmeister

Comments

thedavidmeister’s picture

Status: Active » Needs review
StatusFileSize
new1.09 KB

Let's just see what fails first.

tim.plunkett’s picture

Just because core doesn't use it doesn't mean we can remove it.
Webform and CTools both use #post_render.

thedavidmeister’s picture

@tim.plunkett - fair enough, I didn't even expect it to come back green for core.

What are the main use-cases for post_render in contrib at the moment?

fabianx’s picture

In light of #2047263: Provide inline_template tag within Twig that inlines a template for usage with a render array for drillability with #post_render and #theme_wrappers support, I am for closing (won't fix) this one.

thedavidmeister’s picture

Status: Needs review » Closed (won't fix)

@Fabianx is probably one of the best people to ask whether this is "ok" or not for drillability, so I'm happy to close this off.

jenlampton’s picture

Title: Remove #post_render from drupal_render() as it precludes proper Twig drillability » Remove #pre_render and #post_render from drupal_render() as it prevents proper Twig drillability
Status: Closed (won't fix) » Active

I'd like to leave this on the table, actually.

We shouldn't need #pre_render and #post_render if we can do this right (though that may be in D9). I'd like to hear what the use cases are and see if we can solve those problems in other ways - now. If we can, we should kill these to make things less complicated :)

thedavidmeister’s picture

Still getting tumbleweed on the main use-cases for #post_render. I might ping @tim.plunkett in IRC later, or just look into ctools and webform myself and report back.

I have seen #post_render_cache discussed/proposed, to allow a combination of render caching and processing - #1991684: Node history markers (comment & node "new" indicator, "x new comments" links) forces render caching to be per user

We have had some related discussion to this across #2044105: Introduce #alters for \Drupal\Core\Render\Renderer::render() and #2052253: [META] Add #render property to drupal_render() and convert #type "#pre_render -> #markup" calls to use it

tim.plunkett’s picture


/**
 * Implements hook_page_alter().
 */
function ctools_page_alter(&$page) {
  $page['#post_render'][] = 'ctools_page_token_processing';
}

/**
 * A theme post_render callback to allow content type plugins to use page
 * template variables which are not yet available when the content type is
 * rendered.
 */
function ctools_page_token_processing($children, $elements) {
  $tokens = ctools_set_page_token();
  if (!empty($tokens)) {
    foreach ($tokens as $token => $key) {
      list($type, $argument) = $key;
      switch ($type) {
        case 'variable':
          $tokens[$token] = isset($variables[$argument]) ? $variables[$argument] : ''; 
          break;
        case 'callback':
          if (is_string($argument) && function_exists($argument)) {
            $tokens[$token] = $argument($variables);
          }   
          if (is_array($argument) && function_exists($argument[0])) {
            $function = array_shift($argument);
            $argument = array_merge(array(&$variables), $argument);
            $tokens[$token] = call_user_func_array($function, $argument);
          }   
          break;
      }   
    }   
    $children = strtr($children, $tokens);
  }
  return $children;
}

Not sure when else ctools might be able to accomplish this...

fabianx’s picture

Status: Active » Closed (won't fix)

post_render stays for now.