As I pointed out in the OP, I already tried outputting {{ content }} and it did not work to output the comments (though I know it was picked up because other content fields were output). However, it is now working. I cannot say with 100% certainty why it is working now, although I did try some of the workarounds listed in 3306434. But I believe I was delayed in seeing which of those worked due to the output defined OOTB in burndown-task.html.twig.
In either case, this isn't a problem with burndown per se as you theorized, and I have achieved what I needed so I'm considering this support request fulfilled. Thank you @jeremylichtman for helping me work through the potential causes. If I find the exact fix, I will note it here for others. Otherwise, closing this and hoping it may help anybody else in trying to integrate burndown into their solution.
Thank you!
Tagging with the possible related issue.
So there may be something about the Task entity that is preventing this since it does work on other custom entities.
Hmmmm...but if I make a custom comment type and use that with my ECK custom entity, it at least renders:
Another oddity: If I delete the custom comment type and just try to add the default comment type as a field to Task, the comment type selector dropdown is empty while it's populated for Node bundles. Interestingly, adding ECK and adding a quick entity type and bundle through that, I get the same issue as with Task (see attached screenshots).
I understand this isn't a Burndown specific issue now. But got any ideas on which direction to point me to track down a workaround/fix?
Yeah, I created "Ticket comment" comment Type. And I haven't disabled any Core modules except for BigPipe (which was listed in a JS console stack trace while trying to trackdown a different Burndown issue; will have a patch coming). And I'm pretty sure BigPipe isn't a dependency for Comment to work. So, yeah, I'm completely dumbfounded.
There are no errors in the console log. No errors appear in the system logs when loading the task page, BUT I just checked the Watchdog/dblog and found the following hiding there, triggered whenever I originally hit the "manage display" for the Task entity with the comment field on there:
Entity view display 'burndown_task.task.full': Component 'field_comment' was disabled because its settings depend on removed dependencies.
Looking around, guessing it's related to 🐛 Fix access checks for bundle permissions to avoid triggering a config validation error Fixed .
DigitalFrontiersMedia → created an issue.
This patch same as #13 but incorporates the codesniffer fixes.
If for any reason one of the checkbox options is not chosen and the configuration form is saved that way, $route_names is no longer defined and you get complete page failures in Layout and the Layout Builder Modal configuration page--preventing you from being able to fix it. Thus, once done, this breaks LB on your site and requires some sort of configuration import or uninstallation of the module to reset.
Offering just a minor change to sakthi_dev's patch in #12 above that incorporates a failsafe variable initialization for $route_names to prevent this from possibly happening:
// Get the use modal settings.
$use_modal = $config->get('use_modal');
$route_names = [];
// If there are use modal settings, add the routes
// that are in the settings to the route names array.
if ($use_modal) {
@CRZDEV, Are you using the Layout Builder Modal module? If so, the context returned is different from off-canvas context and is one level lower than what is returned with off-canvas. "$('.js-layout-builder-categories', context)" returns 0 length in this situation. There could be other alters, etc. type of configurations that could result the same. I had to duplicate layout-builder.js in a custom library since Core patch in our case wasn't an easy option. The custom version used "$(context).parent()" instead of "context".
Patch no longer applies due to change in other requirements. Needs to be rerolled.