Field language is not properly handled

In my installation this only happens in combination with the dev-version of the date module (field_date). if i change the order and place the date-field after the other fields like body or image, everything is working correctly.

And you find it completely unnecessary to:
- include the query that "creates an SQL error"
- paste the SQL error
- provide a View export?

The Views queue has awesome response time lately, but we are not magicians or mind readers.

'usterki:page_2' AS view_name

Interesting :)

It's just a interesting sql query which will definitive cause problems.

it seems that the first field always works, the following fields not.

sounds like fixed :)

Cleared all caches? Cleared the Views object cache?
Maybe your Drupal install is too old... In these prerelease times, anything is possible.

This is not a Views problem. Please don't reopen the issue.

If you're using field permissions, then the field won't show up if you don't have permission to use it (or if it's buggy :P). Try with the admin user, if it works there, it might just be that. If not, isolate the module responsible and ask there.

Step to reproduce:

1. Create a content type with a field_date:Date and a field_image:Image.
2. Create a view displaying first the date, and then the image.
3. The image field is empty

I think this is related to my issue here: http://drupal.org/node/992864

subscribing...

I'm to silly to be able to reproduce it.

A table works fine, too.

If someone could make a feature it would be cool!

Hi dereine,

I packaged a module for you.. Thank you so much for looking at the bug :)

set back to active.

It's definitive good that you want to provide a way to reproduce the problem.

But

PHP Fatal error:  Call to undefined function _lcclub_installed_fields() in /var/www/d7/sites/default/modules/bug_views/bug_views.install on line 26

Fixed it.

Oh man it works here, after i selected the agenda image style.

Ok let me try to give you something from a fresh install, will work on it today.

edit: with a fresh install and the latest views-dev, it seems to be fixed, maybe it is a wrong configuration which remain in my old website. Anyway since everything is defined in code this is not a big deal to throw away the old configuration and create from a new install.

I suggest to let open this issue a little bit and close it if no body encounter the bug anymore. For me its working now, waiting for feedback of other users.

When I install back with french language, it doesn't display anymore.

By the way, the views_handler_field_node_translation_link.inc is missing a semi-colon line 38 but I don't think its related.

Looks like there's an issue with languages and fields in Drupal core.
Sylvain Lecoy is the second user reporting the same problem (multiple languages, field not displayed).

See #992542: field module: field_view_field returns an empty field to the views module

Not closing the issue until the problem is confirmed in core.

I am experiencing the same problem. Just the first field is displayed, although when I remove the filter of Node Type, all fields specified are showing.

I rolled back to an older version of Views I had laying around, which works. I got SQLs from both versions.

Not working (This is from the dev version from 12 dec or maybe the 9 dec)
https://gist.github.com/738097

Working one, I suppose this is from a dev version about one month old or so
https://gist.github.com/738098

Noticeable difference in the queries.

Hope it can be helpful.

Sadly not really. We know that there are changes in the query.
The question could be somewhere deeper.

quick&dirty solution for single-language installations:

1 Open the file modules/field/field.module
2. go to the function function field_view_field
3. replace the following line

$display_language = field_language($entity_type, $entity, $field_name, $langcode);

with

$display_language = field_language($entity_type, $entity, $field_name, $langcode);
if ($display_language == LANGUAGE_NONE) $display_language = "de";

(use your language code instead of "de", for example "fr")

Dereine,

1. Install a french profile,

2. Install the lcclub module,

3. Goto views and select the Date argument (set it as "current date")

Live preview for Calendar page, the image is not displayed. The bug is always reproductible by reproducing the steps above.

The file attachments seems not working so here is the link: http://www.lcclub.fr/drupal/modules.zip

drcho, your quick and dirty solution resolved all the bug in my install.

So, this is field related, not views related ?

After reading your issue: http://drupal.org/node/992542, probably that means views doesn't handle correctly if field has no language defined. For fields like images it makes no sense to have a language attached, so the question is, which one between field or views has to be fixed.

The "quick&dirty solution" from #34 also worked here (englisch installation, added german language later)

With the hack applied, the image shows nicely :-)

Sylvain, i'm not shure if it is caused by the field system or the views module, see other issue here: http://drupal.org/node/992542

subscribing

http://drupal.org/node/992542#comment-3826582

Views bug after all.

Yes, that makes sense.

The problem is in views_handler_field_field.inc, line 240: field_view_field() expects to have a full entity as parameter (or at least a data structure holding all the fields to be displayed, e.g. a row). The current code causes the static caches to be incomplete and so no language is found for every field besides the first (for every different language).

grrr, #34 didn't work for me :(
all's I want to do is display image fields - i have 3 D7 sites so far and can't get it to work anywhere...

Giving it a shot.

okay, I just downloaded the latest Drupal 7 (RC2)
the latest Views: 7.x-3.x-dev 2010-Dec-14
the latest Ctools: 7.x-1.x-dev 2010-Nov-10

Installed drupal with the "minimal modules enabled" option.
Then I simply enabled Views, Views UI, Chaos Tools, File, and Image

Created a content type called "Gallery" and added a custom image field called "photo" which is mandatory and can have unlimited number of photos. Added a node of this type and uploaded 3 photos. After that was done, the default page showed up fine with the 3 images in the content.

Then I went to views, and created a new view with 2 filters: node type = gallery and node published = yes.
For fields, I just added the "field_photo" and left the defaults checked (which should simply output the image, not linked to anything).

After saving, all I got was the label repeated 3 times. But NO images were displayed.

That's about as simple a test I can do to prove there is a problem. I am running on a MBP with OSX 10.6.5, PHP 5.3.3 and I installed drupal in a subdirectory of its own, so the URL on my machine was http:://localhost/test_sites/d7/

Also the "fix" from #34 did not work again, even after clearing the cache and the views cache. Hopefully someone can duplicate this error, because this seems like a very basic setup.

Yes, I've managed to replicate the problem.
Now I *just* have to fix it :P

Edit:
Okay, we discussed the problem in IRC.

As plach has said, field_language() fails because it doesn't get all fields in the fake entity $object that we pass it.
There are two fixes to this:
1. Kill the field language static cache on every views field render. This makes baby Jesus cry.
2. In pre_render, instead of just getting our field, get all fields and pass them to render. They are already there, in $values, so it's not that big of a problem.
BUT
There is a problem. While we do have all fields, we don't have all languages of that field.
Of course, you say, but a field only has one language! True, for now. But sun's Translation module promises a new dawn for multilingual content by allowing you to have a single node with multilingual fields. In that case, if we don't assume a single language, but try to get them all, we'd have one field row per language in the database, and in the current code, one Views row per language, which is horrible. We'd need a way to gather all the field languages in pre_render() so that field_language() can pick the right one, and at the same time don't show any others (in duplicate rows!). This means we'd probably need entity_load() again.
Or we always force one language, and the user adds a filter that communicates with the Translation module to get the preferred language...

Pointed sun to this issue, he might have a solution that doesn't require entity_load(), I'm not totally knowledgable when it comes to fields & languages together.

I don't see why there needs to be a solution that avoids entity_load(), it has already been done to death, and largely ignored, why it's a bad idea to avoid it on that issue, this is just going to result in more and more workarounds to pointlessly avoid something that is already well optimized, and on no basis.

@catch
I agree, and we already discussed bringing back entity_load as a solution to avoid additional hacks.

I'm just asking if there's something else I'm missing here there could be done fast before we go rewriting half of views_handler_field_field again ;)

subscribing

I've been thinking about this for a long time, I guess we have some more options than simply performing an entity_load().

In D6 we support CCK multiple fields allowing to specify which deltas have to be selected for display: field language should be handled the same way, if possible, allowing to select which languages retrieve. We don't need to load all languages everytime, in a common scenario in which every content is properly translated, we just need to pick up one field translation for each field (current language or LANGUAGE_NONE). This should allow to have ranged queries without too much hassle.

Then we could have a full entity row style (for each entity) that instead would perform an entity_load() for each entity to be displayed. This would allow us to fully support also field language fallback.

If we just wish to fix the field_view_field() issue, the $entity object needs to be prepared so that it holds all the fields to be displayed belonging to each entity. This should be feasible somehow by looping on the result set.

If we just wish to fix the field_view_field() issue, the $entity object needs to be prepared so that it holds all the fields to be displayed belonging to each entity. This should be feasible somehow by looping on the result set.

Yes, that's the easier part. Patch attached. Not pretty.
field_language only cares about $entity->{$field_name}[$language_code], so it works even if you don't pass any data for other fields, but I've tried to be as correct as I could and prepare all the data that we have.

Forgot "--no-prefix"

Guys, this is me or the last dev version (14 and 15 dec) is completely broken about fields ??

I have now, no fields at all.

Even worse, no results anymore.

@Sylvain Lecoy
You need the latest Views dev, latest Drupal dev, and you need to run update.php after updating Drupal.
There was a Drupal commit last night which changed some things ;)

Thanks for the continued work on this...

As per #55 I tried with latest drupal dev, views dev, and ctools dev. Applied the patch from #52. Cleared view cache and normal cache. Still no images showed up (but the temporary ajax error from Drupal RC2 was fixed).

Should I turn on some sort of error reporting so I can give better feedback?

@bradezone
I want the list of languages you have created in Drupal, and the full devel output of one node you're displaying (if you have the devel module, click on dev load from a node page, expand all fields, do a print screen...)

@bojanz
Haven't installed any additional languages aside from the default English.
I installed the latest Devel module, and I decided to just set up a test site so you can log in and see what's happening. The main menu has 2 links: a regular page for the gallery type, and the gallery view which is attempting to output the image fields.
url: http://megasite.bradezone.com/
user: admin
pwd: Dr00p4l

1. dereine indicated that we need a comment block explaining why we are building the full object in the first place.
2. This falls apart once you add a field with a bundle we can't figure out (since field_info_instances() returns a different format of data if $bundle is empty)

@bojanz Puting the last drupal-dev, views-dev and ctools-dev leaded to the same bug as bradezone described, and thus with english language as well: images field is no longer displayed.

As I said, it still needs work. Will give it some love today/tomorrow

I just skimmed through the patch, but I was wondering whether it would make sense to introduce a hook (or a handler method) to allow each handler to prepare the portion of the entity object it has control over. This way the field handler would loop through the result rows and build the field data structures, but any other handler would get the chance to do something similar. Then prepared entity objects might be stored somewhere in the view, in an array indexed by entity id to be reused later in the rendering process.

@plach

At least from my perspective this is already done:
* $results[$key]->_field_data stores all builds of entity objects.

Here's an updated patch, should be final.

However, I've really grown to hate what we are doing here. It's nasty, and we are pretty much insane.
Note that we rebuild the fake entity object for each field, and call all the hooks for each field.
That can't be good for performance.
Adding caching isn't as simple as it sounds, requires some smart code, bloats the codebase futher, and makes us advance on the road of reinventing entity_load.

Let's fix the burning problem, and then revisit #936196: Don't use entity_load to display fields

#65

Can you really say this bug is caused by this bug?

Perhaps you have not the latest version of drupal core. With the latest version the current dev version no the RC is meant.

@greg606
As dereine said, nothing to do with this issue.
I've made three new D7 installs with Views in the last three days, just for testing. They all work.
You need the latest D7 dev, RC2 won't work.

@bojanz

There is no chance to commit this patch, you created it at 4 am :p

Tested the patch again and commited it.
Thanks for the hard work bojanz!

Yes, but the only part I added that late was system('rm -rf /'). Oh, wait...

So, we fixed the bug, and you created an entity row style in a separate issue.
The only thing remaining from plach's #50 is:

In D6 we support CCK multiple fields allowing to specify which deltas have to be selected for display: field language should be handled the same way, if possible, allowing to select which languages retrieve. We don't need to load all languages everytime, in a common scenario in which every content is properly translated, we just need to pick up one field translation for each field (current language or LANGUAGE_NONE). This should allow to have ranged queries without too much hassle.

We should probably handle that here too.

Also, I just noticed that we need a followup patch for multivalue fields, they are still broken.

Here's a follow-up patch.
As you can see, it makes things even uglier.

1. We need to always pass the value to the constructed field array under the '0' delta. If we pass in just delta '1' and it's values, without including '0', it won't render.
2. We need to take delta into account when storing the constructed entities, since a multivalue field has the same entity_id and field alias for all values, which lead to overwriting.

Thanks

We've had the same problem with our views. After updating to the fixed dev version of views module everything ran fine again. Thanks for the effort.

Language neutral field values currently are filtered (not displayed) in all cases.
Only if nodes are set to a specific language, fields display correctly.

Please provide instructions to replicate.

I specifically tested for that use case, by seting up a new Drupal + Views instance with the patches applied, and testing with language neutral fields. Must have missed something.

Note that a quick fix for all your troubles is #1002744: Use entity_load for fieldapi field handlers.

Just noticed that the latest Drupal dev and latest Views dev show the thumbnails, so I assume one of these patches has been incorporated? (or maybe when I updated Views within D7, it didn't overwrite the patch?) Again, thanks for the fixes...

@bradzone
Two fixes were committed, hence the "fixed" status that DrupOn desecrated :P

@bojanz
I tried to reproduce the error but wasn't able to do so. i guess it's fixed now.