Problem/Motivation

The documentation for table.html.twig says that you can pass an array containing the contents of a cell. Each cell is itself an array, with keys 'tag', 'attributes' and 'content' to specify exactly how to build that cell. Unfortunately, passing an array does not appear work.

I recently tried to make a table with some row headers, and quickly got bogged down when it failed to render. Here is sample code:

$build['clientDetails'] = [
  '#type' => 'table',
  '#rows' => [],
];

$build['clientDetails']['#rows'][] = [
  [
    '#tag' => 'th',
    '#attributes' => ['scope' => 'row'],
    '#content' => 'Client',
  ],
  'Glinda'
];

$build['clientDetails']['#rows'][] = [
  [
    '#tag' => 'th',
    '#attributes' => ['scope' => 'row'],
    '#content' => 'Profession',
  ],
  'Sorceress'
];

The expected output would be:

<table>
<tbody>
	<tr>
		<th scope="row">Client</th>
		<td>Glinda</td>
	</tr>
	<tr>
		<th scope="row">Occupation</th>
		<td>Sorceress</td>
	</tr>
</tbody>
</table>

The actual output is:

<table>
<tbody>
<tr>
  <td #tag="th" #attributes="row" #content="Client"></td>
  <td>Glinda</td>
</tr>
<tr>
  <td #tag="th" #attributes="row" #content="Profession"></td>
  <td>Sorceress</td>
</tr>
</tbody>
</table>

And the logs contain an error about implicitly converting an array to a string (the attributes sub-array that gets converted to "row").

I spent about fourteen hours struggling with this last week. I tried specifying 'cells' as the name of the array, which did not help. I tried it with and without a '#' at the front of the keys. I tried a whole bunch of stuff that did not help. I posted on the forums asking for assistance and Jaypan was kind enough to try it out and report that they're seeing the same behavior.

The twig template appears to be set up to handle this correctly, and the renderer is producing data that follows the structure. But somewhere between the module and the theme layer, the renderer is taking the manually-specified cell arrays and treating them as attributes arrays for a generic TD element. I spent some time trying to track down exactly where in the code this is happening, with no luck. The data seems to be intact through the end of early rendering, and that's where I lost the trail. I'm not sure where to look for the next stage of the rendering pipeline.

If this is a misunderstanding on my part and there is some way to make it work, I would be grateful for an example demonstrating how to do it.

Steps to reproduce

Pass some of the example code above to the renderer and observe the results.

Proposed resolution

Either correct the issue in the rendering pipeline, or update the documentation for table.html.twig to reflect that it is not currently possible to specify a cells array manually. Or if it is, explain how to do it.

Issue fork drupal-3437166

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

wdmartin created an issue. See original summary.

jaypan’s picture

I have done some debugging and determined what is happening.

The Twig template states:

tag: The HTML tag name to use; either 'th' or 'td'.

From within the context of the Twig template, this is correct. However, the template does not document how to set this variable, and digging through the code, it does not actually appear that this variable can be manually set. Instead, the variable is automatically set in code.

In theme, inc. I can see that the tag type is set here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/includes/them...
With the $is_header value being set here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/includes/them...

So, to set a table cell to use a TH tag, the header attribute for the cell must be set. Here is a simple example:

$table = [
  '#theme' => 'table',
  '#rows' => [
    [
      [
        'data' => 'Header cell',
        // Setting header to TRUE will cause this cell
        // to be a <th/> rather than the default <td/>.
        'header' => TRUE,
      ],
      [
        'data' => 'Normal cell',
      ],
    ],
  ],
];

Maybe an update to the table.html.twig documentation to indicate how to set a table cell as a header, would be beneficial to developers.

Utkarsh_33 made their first commit to this issue’s fork.

utkarsh_33’s picture

Version: 10.2.x-dev » 11.0.x-dev

Utkarsh_33 changed the visibility of the branch 3437166-rendering-engine-disregards to hidden.

utkarsh_33’s picture

Status: Active » Needs review

Updated the docs stating the use of header flag to identify whether a cell can be used a

or tag.
smustgrave’s picture

Title: Rendering engine disregards manual table cells » Update documentation for table.html.twig around table cells
Status: Needs review » Reviewed & tested by the community

Updated the title to more lineup with the solution but seems straight forward.

jaypan’s picture

Status: Reviewed & tested by the community » Needs work

The updated documentation listed the header attribute as a child of a header cell, but it is not. It is a sibling to data. Also, there are multiple instances of table.html.twig in core, and each instance needs to be updated.

utkarsh_33’s picture

Status: Needs work » Needs review
smustgrave’s picture

Status: Needs review » Needs work

Can the MR be updated to point to 11.x vs 11.0.x

And sorry I didn't catch that earlier.

utkarsh_33’s picture

Version: 11.0.x-dev » 11.x-dev
utkarsh_33’s picture

Status: Needs work » Needs review
jaypan’s picture

'header' is an key of the 'cells' array, so I think the documentation should set it as a child of that array.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Feedback appears to be addressed. Thanks @Utkarsh_33 for updating that target

nod_’s picture

Status: Reviewed & tested by the community » Needs work

Can someone update the comment so that it wraps at 80 chars? after that it's good to go.

nod_’s picture

smustgrave’s picture

Status: Needs work » Reviewed & tested by the community

Wrapped to 80

  • nod_ committed 39239159 on 10.3.x
    Issue #3437166 by Utkarsh_33, smustgrave, Jaypan, wdmartin: Update...

  • nod_ committed 34abc72b on 10.4.x
    Issue #3437166 by Utkarsh_33, smustgrave, Jaypan, wdmartin: Update...

  • nod_ committed 8a300d43 on 11.0.x
    Issue #3437166 by Utkarsh_33, smustgrave, Jaypan, wdmartin: Update...

  • nod_ committed 8778ac18 on 11.x
    Issue #3437166 by Utkarsh_33, smustgrave, Jaypan, wdmartin: Update...
nod_’s picture

Version: 11.x-dev » 10.3.x-dev
Status: Reviewed & tested by the community » Fixed

Committed and pushed 8778ac1801 to 11.x and 8a300d4337 to 11.0.x and 34abc72b52 to 10.4.x and 3923915994 to 10.3.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.