I'm testing 8.x-2.0-beta3 version on Drupal 8.1.

I created a view and loaded my multi-valued field into the view. It seems to load the correct number of images for each node (ie if the node has 4 images, I get 4 images) but I get the first image for all of them. The next node does the same thing, I get the first image in that node as well.

I'm not sure what other information would help here, let me know and I'll provide it.

David

Comments

aarailfan created an issue. See original summary.

aarailfan’s picture

aarailfan commented

FYI, you can see a grid view of the images here:

https://www.d8.goldenspikeartisans.com/portfolio/fire

and the juicebox view here:

https://www.d8.goldenspikeartisans.com/portfolio/water

rjacobs’s picture

rjacobs commented

Hi,

It sounds like you have the views "Multiple Field Settings" > "Display all values in the same row" option enabled for the multivalued field that you are using for your gallery? If so the behavior that you are seeing is (reluctantly) by design as Drupal 8 does not allow the Juicebox style plugin tap-into those multivaled settings in a reliable way during the Juicebox XML generation process. For more on that see: #2649310-9: Views plugin is not properly aware of field cardinality.

What this means is that a normal view can only use the first item of a multivalued field with the formatter. This is generally the preferred approach anyway as any other alternatives would lead to a situation where your title and caption values would be repeated across multiple gallery images (they are typically sourced from other view fields).

All that said, there is a workaround where you simply add a "file usage" relationship to your view, add a "file ID" field to your view that uses this relationship, and then use this file ID as your image and thumb source for the Juicebox formatter. I think this would also allow you to leverage image-specific metadata (alt/title text) as your titles and captions in a way that is unique to every image.

Unfortunately there is a big caveat to this workaround, as there is an outstanding bug in Drupal core that breaks the "file usage" relationship, see: #2628230: Adding File Usage "File" relationship results in broken/missing handler (though there is a patch available). If you decide to go this route I would love to hear some feedback about your results. I've not been able to test it in great detail due to that pending core bug.

I hope that helps, just let me know.

aarailfan’s picture

aarailfan commented

I decided to go the route of a single image per node. It's more work to upload the files this way, but the control is better for what I'm looking to do. Thanks for your help.

rjacobs’s picture

rjacobs commented

Sounds good, thanks for letting me know. I think you'll find that the one-entity-per-image approach is most flexible one the long-term (at least for views integration), especially as it allows you to maintain a nicely-packaged one-to-one relationship between each image and it's metadata. There are also some bulk-upload tools out there that can help ease the image ingestion workflow.

rjacobs’s picture

rjacobs commented
Status: Active » Fixed

I hope my comments addressed this. Since I don't think there is anything functional we can do to address this better I'll adjust the status.

aarailfan’s picture

aarailfan commented

Yes, thanks for your help. It is working perfectly using one-entity-per-image approach.

lcontreras’s picture

lcontreras commented

I had the same problem and I resolved following the steps mentioned by rjacobs. Applying the patch suggested :
https://www.drupal.org/files/issues/views_file_relationships_broken-2628...

And creating the File Usage relation.

So, thank you very much. Because It almost drive me crazy.

Status: Fixed » Closed (fixed)

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

c3rberus’s picture

c3rberus commented

I also used the patch and steps mentioned in this thread, it worked very well. I just have to make notes for the views patch and lookout for it whenever there is a core update to make sure it does not get reversed :(