Hi:
Many thanks for this very very useful module and the support you give us swentel!
- I have a 'blog' content type that includes a 'section' taxonomy reference field.
- In sections vocabulary I have created a view mode called 'Taxonomy term for node' that displays an image field
- In blog default display I've configured the default view to show the sections field with 'Taxonomy term for node' but it keeps using the default mode and ignoring the custom view mode.
Thanks.-
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1143070-2.patch | 624 bytes | neurojavi |
| #5 | 1143070.patch | 590 bytes | swentel |
Comments
Comment #1
neurojavi commentedConfirmed in last dev version...
Comment #2
swentel commentedHrm works perfectly fine here, even in latest dev, so not sure what might be wrong here. Tempated to set it 'cannot reproduce' since it works perfect here, but I'll wait a bit more to see if others have the same problem.
Comment #3
neurojavi commentedHi:
I've been debugging for some time and I've found where the problem was...
My view mode was called 'taxonomy_term_for_node' (a very short name as the ones you like :-) so the str_replace in the formatter view function was deleting the string 'taxonomy_' from the beginning of the name...
I think it could be fairly common for people to use view names beginnig with taxonomy so I think it's worth changing str_replace with substr_replace('taxonomy_', '', $display['type'],0,9) or perhaps preg_replace...
What do you think?
In the meantime I've changed the view mode name and works fine.
Thanks for looking at this!
Comment #4
swentel commentedAh, nice catch, never thought about that :)
substr_replace sounds good to me, it's probably a tiny bit faster than preg* functions .
Comment #5
swentel commentedCan you test with this patch ?
Comment #6
neurojavi commentedWell, I've not tested the patch yet.
I've been thinking and looking at code and I think that this line is not needed at all.
Wouldn't be better not to add that prefix to view modes in ds_field_formatter_info()?
I mean changing
$formatters['taxonomy_' . $key] = array(
with this
$formatters[$key] = array(
here
We're adding 'taxonomy_' prefix in formatter_info and deleting it in formatter_view. The only reason I can think for doing this is to avoid namespace conflicts but the only formatters existing for taxonomy terms are
taxonomy_term_reference_link and taxonomy_term_reference_plain, so the only possible conflict is that a view mode is named taxonomy_term_reference_link or taxonomy_term_reference_plain. This is very unlikely to happen and, in any case, adding the prefix we are moving the conflict to cases when the user has named term_reference_link or term_reference_plain his view modes (unlikely too but a little more possible). So, not solving anything...
What do you think about naming formatter the same as the view modes?
Another little question:
Looking at code I've noticed that, in the following function, the case for taxonomy_term_data is never executed because the entity name is taxonomy_term. We don't need this special case. I've tested a set message inside it and it seems that it's never reached. Am I right?
I think we can transform
in this
The changes are so little that I've not attached a patch. Please tell me if want me to attache one or two patches.
PS: The more I use and look to the code, the more I like this module, thanks a lot! :-)
Comment #7
swentel commentedIIRC, the only time that 'taxonomy_term_data' is passed is in views when listing terms. I'm using $this->views->base_table which in that case is 'taxonomy_term_data' (unless views has changed recently). In any case, that code could be simplified anyway, even if views still passes that string. We could modify it in the views implementation too of course.
If we'd change the formatter, than we need an upgrade path which can be annoying since we'll have to find
a) the taxonomy fields and change their formatter
b) find any views which lists terms and uses view modes
c) maybe others than I forget now
so I'm tempted for the substr_replace option for now :)
Comment #8
neurojavi commentedYou're right. It's not woth the effort of such a complicated upgrade path. I was only enjoying and diving into code.
In any case you patch doen't work. It's my fault, I pointed you to substr_replace to avoid preg but that function only accepts 4 parameters and doesn't do what we expect.
I'm attaching a new patch with a conditional assignment to avoid preg. I've tested it with a taxonomy view mode named taxonomy_testmode and works fine.
I think this can be committed.
Thanks.-
Comment #9
swentel commentedJoy is fun, nothing wrong with that :)
Patch committed and pushed, thanks!