Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This can be a refactor of entityreference_field_formatter_view and start using the theme system. This allow to handle or override much easier some features. Like the label link can be easily manipulate to add class and uri extra extensions.
This help for sitebuilders to use own hook_preprocess_entityreference_label(&$variables) and hook_preprocess_entityreference_entity_id(&$variables) as well you can do hook_theme_registry_alter() to override all.
Please take this in consideration.
Comment | File | Size | Author |
---|---|---|---|
#1 | refactoring-field_formatter-theme-2088387-1.patch | 3.18 KB | killua99 |
Comments
Comment #1
killua99 CreditAttribution: killua99 commentedAs well this is the patch to apply this feature.
Comment #2
rozh CreditAttribution: rozh commentedIt is very usefull. Thanks for the patch!
Comment #3
tyler.frankenstein CreditAttribution: tyler.frankenstein commented+1 on the RTBC status!
Comment #4
DamienMcKennaComment #5
bisonbleu CreditAttribution: bisonbleu commentedI'm trying to add a button class to the A tag of the entityreference link as follows.
Can this patch help me achieve that?
If so what would be the best way to do this ?
Comment #6
jdleonard+1 RTBC. It's working on 7.x-1.2.
Comment #8
spotzero CreditAttribution: spotzero at Coldfront Labs Inc. commentedTook a little massaging to get it on to 7.x-1.x, but committed.
Comment #9
DamienMcKennaMight this need a change notice?
Comment #10
spotzero CreditAttribution: spotzero at Coldfront Labs Inc. commentedI can write one. I think this change only affects you if you're using template preprocess field to directly modify the "#markup" value directly if you're using the field formatter for label or entity id. Do you think this affects anyone else?
I had mixed feeling about this one because it could break stuff, but it does give the people whose stuff it breaks a much better way of doing what they were trying to do.
Comment #12
blasthaus CreditAttribution: blasthaus commented+1 for a notice. this tripped us up for a minute since we were indeed theming reference fields with icons.
Comment #13
ladybug_3777 CreditAttribution: ladybug_3777 commented+1 for a notice. This completely caught me off guard and broke a large section of my site unexpectedly. My theme commonly uses the #markup field in order to compare and change the output of a taxonomy term.
The totally screwed up my working hook_preprocess_entity and hook_preprocess_field functions.
I simply had to change all my references from #markup to #label, but it caused a moment of panic for sure.
Comment #14
ladybug_3777 CreditAttribution: ladybug_3777 commentedHmmm.... actually just changing over to label isn't as straightforward as I thought... here's an example of a section of code I'm using to output the value of some custom fields in my taxonomy:
My return statement now is invalid, but ONLY when an entity reference field is passed to the function. Any other field type, #markup needs to be used. So now I'm going to have to try and check the type and then decide if I should be using #markup or #label.
It feels wrong that the field_view_value function should behave so differently based on field type now.....
Comment #15
spotzero CreditAttribution: spotzero at Coldfront Labs Inc. commentedWithout knowing what that code is actually trying to do, it looks like you're rendering a render array by popping out the markup into a string.
Instead of
return $fieldItemOutput['#markup'];
tryreturn drupal_render($fieldItemOutput);
Comment #16
ladybug_3777 CreditAttribution: ladybug_3777 commentedThe function was simply returning the field's value as a simple string. In some cases that simple string is passed to other functions for comparison or it may be used to concatenate multiple field values into one variable. I don't want rendered HTML though... which I thought drupal_render() outputs. Am I incorrect in thinking that's what drupal_render does?
Comment #17
ladybug_3777 CreditAttribution: ladybug_3777 commentedAnd forgive me if I've got the HTML value part swapped, I'm looking at some old code that we haven't touched in years, so digging back into the themeing layer of this particular section and finding this issue has me a bit out of sorts LOL!
Comment #18
spotzero CreditAttribution: spotzero at Coldfront Labs Inc. commentedfield_view_value() returns a render array generated by the field formatter, so that '#markup' value actually already contains rendered HTML. For this reason field_view_value() isn't really suitable for comparisions or operations on the field value.
However . . .
Since drupal_render happens to render '#markup' the same way your code does, essentially
return $element['#markup'];
.and since the new ER template will render with a simple
check_plain($label);
I'm pretty confident changing your code to
return drupal_render($fieldItemOutput);
will work just fine (and actually work exactly as it did before).Comment #19
ladybug_3777 CreditAttribution: ladybug_3777 commentedGreat, thank you! After typing the first response I was thinking... "wait... actually I think #markup DOES have the HTML in it..." so I did have those swapped in my head at first. hahaha! Thanks for setting me straight. That sounds like a great solution then.
Another question for you.... if I'm going the other way around and was setting the markup value... and I WANTED to include HTML, the new ER change wouldn't allow for that?
so for example
BUT
I don't THINK I'm loading HTML into my old #markup values like that, but your last comment made me think about it....
Going through old dusty code is rarely fun :-)
Comment #20
spotzero CreditAttribution: spotzero at Coldfront Labs Inc. commentedYou've got the render array, you can do anything you want with it before you render it:
Comment #21
dbdrupal CreditAttribution: dbdrupal commentedThis broke just about every view on my site. I'm a site builder and not a developer, can anyone explain how I can fix my site. At this time I'm trying to roll back the changes.
Comment #22
spotzero CreditAttribution: spotzero at Coldfront Labs Inc. commentedYou can downgrade entity reference from https://www.drupal.org/project/entityreference/releases/7.x-1.2
I'm a little confused about how this could have broken all of the views on your site though, can you create a new issue and elaborate?
Comment #23
dbdrupal CreditAttribution: dbdrupal commentedI did the downgrade right after I posted last night and all is well except that I can no longer upgrade to the newer versions of this module. I believe there is already an issue out there for this because I clicked on a link to follow it over to this thread. If I have time this week, I will comment on that issue as well. Thanks.
Comment #24
MustangGB CreditAttribution: MustangGB commentedThis broke a lot of my views also, for reference they were setup something like this:
Switching from
#markup
to#label
works, finding all the instances wasn't so easy.