- Issue created by @liquidcms
Took a little while to debug what was going on here, but i think sorted out now. A few things about this module which are counter-intuitive to how Views works.
1. the formatter processes regardless of whether the field is excluded or not.
2. the field always appears empty.
The way these showed up is i have:
- a node banner image field (field 2)
- a parent node with a banner img field (field 1)
The idea is simple: if the node doesn't have a banner img then use the parent's banner img. I set this up with the parent field as a bg img defined first but excluded and then the node banner img as the 2nd field, also defined as a bg image and with its "no results" set to the first field. In a view with these displayed as normal images; this would work. But with bg images and the odd processing rules i listed above; this doesnt work as expected.
To start with; the child node img ALWAYS appears as empty so the parent field is ALWAYS used; but it also ALWAYS appears as empty so it doesn't really matter.
Then, when you look at the CSS that gets generated, both bg img definitions exist with one overriding the other. The way views and this module process the order here; it is the first field which has precedence (counter-intuitive with how CSS works) - so how i have it set to work with normal images is backwards. If i switch the order of these fields; this works as expected. Whether they are enabled or not as they are both processed regardless.
So I have a work-around. Ideally however, this would process a bit more logically:
- if field is excluded; don't process
- if field has an image don't appear as empty
This would still leave handling of the "no results" but possibly the first field is not defined as a bg img; just std img formatter (original img). And then the 2nd field would use its field img to process unless missing then use the img (unprocessed) from field 1 to process.
Active
1.16
Code