CommentFileSizeAuthor
#6 2572397-override-template-6.patch470 bytesSam152
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sam152 created an issue. See original summary.

Sam152’s picture

Sam152 CreditAttribution: Sam152 commented

Currently it's overridden by doing a hook_theme_registry_alter, but this doesn't allow a theme to override the field template. This is tricky because in a lot of cases we actually want to forcefully override the field template provided by a theme which doesn't support fences. Classy for example overrides the field template, but we want fences to work with all sub-themes of classy.

I believe that any more specific template using theme_hook_suggestions are still overridden so this might be a case of wont fix?

david.gil’s picture

david.gil CreditAttribution: david.gil commented

Hi,

any idea in how can i override fences tpl in my custom theme?. In lots of cases we want to have a light field classes and fences tpl adds classes that we want to override.

Best
David

JohnAlbin’s picture

JohnAlbin
he/they/他
Primary language English
Location Taipei, Taiwan
CreditAttribution: JohnAlbin for ImageX commented
Category: Feature request » Bug report
Priority: Normal » Critical

We won't release an official Drupal 8 version of this module without this ability.

Sam152’s picture

Sam152 CreditAttribution: Sam152 commented

You see the dilemma though right? We want to specifically override the field templates provided by themes which don't support fences, but then allow more specific themes to override the fences template, provided they are aware of the extra logic required to make the configuration meaningful.

It might be something like an arbitrary line in the sand that says "override anything from stable, classy or core, but then defer to anything more specific, hoping it was intentionally overriden with fences in mind". In this case if Zen shipped with a custom field template would fences kick in or simply be incompatible with Zen?

Personally I find override field templates an anti-pattern. Fences provides control over everything you might want to change, and anything else should go in a field formatter. Just my 2c.

Sam152’s picture

Sam152 CreditAttribution: Sam152 commented
Status: Active » Needs review
FileSize
2572397-override-template-6.patch470 bytes

Implements the suggestion in #5, but also has the issues described in #5.

Given more specific overrides work as expected (like field__node__field_name), I'd mark this as "works as designed" and allow others to implement hook_theme_registry_alter in exceptional circumstances. Installing fences is akin to staying "allow me to control field markup in config" and thus should ignore the "allow me to control field markup in code" use case.

As far as #3 goes, extra classes don't hurt anyone? I'm a selfish contrib maintainer and prefer my way or the highway ;-)

Sam152’s picture

Sam152 CreditAttribution: Sam152 at PreviousNext commented
John Pitcairn’s picture

John Pitcairn CreditAttribution: John Pitcairn commented

extra classes don't hurt anyone?

I disagree. For a tightly integrated site that will only ever run one specific theme, clean markup with classes only where necessary has benefits in readability and maintainability.

The lack of a global config page to remove classes from default markup means achieving this is more difficult than it should be. If the intent is that Fences handles it all in config, then marking this "works as designed" is OK but makes that global config essential. See #2841841: Global configuration missing

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody as a volunteer and commented
Status: Needs review » Reviewed & tested by the community

Patch #6 works great and makes the situation much better. We should separate further features into a separate issue and get this committed for more flexibility.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody as a volunteer and commented

Any plans for a new dev release? :)

thomas.frobieter’s picture

thomas.frobieter
Primary language German
Location EU
CreditAttribution: thomas.frobieter commented

We are working with this patch for 7 month now, without any problem. So +1 RTBC.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody as a volunteer and commented

Any active maintainer here or plans for a new release?

  • Sam152 committed df8ef93 on 8.x-2.x 
    Issue #2572397 by Sam152: Allow themes to override the field template
Sam152’s picture

Sam152 CreditAttribution: Sam152 at PreviousNext commented
Status: Reviewed & tested by the community » Fixed

Okay, lets see if this solution works. It might be disruptive for existing installations, but the current stability is alpha after all.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody as a volunteer and commented

Thank you Sam! That's great news :) Looking forward to alpha2!

Status: Fixed » Closed (fixed)

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

chuck_theobald’s picture

chuck_theobald CreditAttribution: chuck_theobald commented

FYI, I think alpha2 broke our relatively new installation, it has been in production for about a year. It uses a custom theme based on standard, but I think it is not aware of Fences. I've spent a fair amount of time trying to diagnose this over the last two weeks. I started looking at Views config, then at the theme. I figured that production must surely be using some variation on the theme. Finally determined today that that was not the case. Finally, running a grep through the modules/contrib directory led me to Fences.

This is a new site to me. I am also fairly new to D8, and new to twig theming. So, this issue report leads me to believe that the theme field.html.twig file will override Fences as of version alpha2, whereas in alpha1, Fences would override the theme. Is this a correct assessment? And, more to the point, how do I get Fences to do its job again?

scottsawyer’s picture

scottsawyer
Primary language English
Location Atlanta
CreditAttribution: scottsawyer commented

Yep, this just broke a site layout for me. I am using a base theme that has a field.html.twig that I specifically wanted Fences to override. Now I have extra markup that is breaking my CSS framework. I was trying to avoid writing complex field.html.twig files everywhere and just wanted to set the markup for the wrappers in the UI for the paragraphs.

Maybe it would be nicer if there was a configuration option to prevent the theme from overriding the field templates?

scottsawyer’s picture

scottsawyer
Primary language English
Location Atlanta
CreditAttribution: scottsawyer commented

This seems to be the solution for me, copy the fences field.html.twig into your own theme template directory, rebuild cache. Glad that worked.

AdamBernstein’s picture

AdamBernstein CreditAttribution: AdamBernstein commented

Please add the instructions in #19 to readme or RC release notes, it's a significant change to functionality since alpha1. I spent a day troubleshooting layout issues after upgrading, please don't make other users have to find a solution buried in a bug report from years ago.

Sam152’s picture

Sam152 CreditAttribution: Sam152 at PreviousNext commented

@AdamBernstein, if you write up a paragraph explaining the problems I raised in #5 and the solution in #19, I'll happily add it to the release notes.