Hello,

This looks like the most supported slider implementation for D8 at the moment. I have successfully installed it in a drupal 8.0.2 instance and have had a good play with the juicebox field formatter (so I know that it works).

Things are starting to fail when I try using the views plugin to collect slides into a juicebox slideshow.

These are the steps that I have followed:

1. Create a new content type (called Slide), containing an image
2. Create some test content (two nodes of type Slide)
3. A view that collates the slides, using the juicebox formatter - I then selected the custom Slide fields and plugged the desired fields into the juicebox formatter settings. While defining the view I chose to create a page (to view the resulting slideshow).

Image Source: Content: Slide Image
Thumbnail Source: Content: Slide Image
Image Field Style: None
Thumbnail Field Style: None
Title Field: Content: Title
Caption Field: Content: Title

When trying to view the slideshow I get the following error message:
The website encountered an unexpected error. Please try again later.

Examining the logs I see the following error message:
Recoverable fatal error: Argument 1 passed to Drupal\juicebox\JuiceboxFormatter::styleImageSrcData() must implement interface Drupal\file\FileInterface, null given, called in /var/www/html/modules/juicebox/src/Plugin/views/style/JuiceboxDisplayStyle.php on line 251 and defined in Drupal\juicebox\JuiceboxFormatter->styleImageSrcData() (line 217 of /var/www/html/modules/juicebox/src/JuiceboxFormatter.php).

Any thoughts? Let me know if I can provide any more information to assist.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gavz created an issue. See original summary.

rjacobs’s picture

Issue tags: -juicebox, -views

Hi,

It looks like you are doing things in a fairly standard way that's consistent with the examples from the docs. Which version of Drupal core are you using? As far as I know there are no compatibility issues with the most recent versions of core (8.0.x or even HEAD/dev) as all the tests are currently passing (and there is a test case in there that essentially duplicates the setup that you have described). However pre-release versions of core could certainly cause issues.

Also, is the field that you are using as an image source just a standard Drupal image field?

Finally do you have any other "media" related modules or customizations in place? Compatibility with any other contrib modules that do things to file entities or that offer new field types for image storage is still largely untested, so it would be interesting to know if this could be a variable in your case.

gavz’s picture

Hi Ryan,

Many thanks for replying.

1. I'm running drupal 8.0.2.
2. Using the default Drupal Image field
3. Not running any additional media related modules (to my knowledge).

Note that we did migrate a lot of content from an older D7 instance.

Would you like me to create an admin account that allows you to jump in and take a look?

gavz’s picture

Just tried on a completely vanilla drupal 8 install - it works!

There are two additional error messages that occur before the one I reported earlier:

Notice: Undefined offset: 5 in Drupal\juicebox\Plugin\views\style\JuiceboxDisplayStyle->getItems() (line 358 of /var/www/html/modules/juicebox/src/Plugin/views/style/JuiceboxDisplayStyle.php).

Recoverable fatal error: Argument 1 passed to Drupal\juicebox\JuiceboxFormatter::styleImageSrcData() must implement interface Drupal\file\FileInterface, null given, called in /var/www/html/modules/juicebox/src/Plugin/views/style/JuiceboxDisplayStyle.php on line 251 and defined in Drupal\juicebox\JuiceboxFormatter->styleImageSrcData() (line 217 of /var/www/html/modules/juicebox/src/JuiceboxFormatter.php).

So it's definitely something environmental ...

gavz’s picture

OK, I dug a bit deeper, and it looks like entity API is returning NULL files (when provided a list of fids).

>> $file_entities = $this->entityManager->getStorage('file')->loadMultiple($fids);

I added some debug and it looks like it was requesting the correct fids.

I checked and the files exist on the filesystem (and have corresponding entries in the file_managed table).

rjacobs’s picture

That's some great debugging, thanks! So it sounds like the place to focus is Drupal\juicebox\Plugin\views\style\JuiceboxDisplayStyle::getItems(). It seems like the logic there is able to extract an fid for each image from each row in the view, but is then unable to get a fully-loaded file entity based on that fid.

I'm wondering if that is an issue with that state of your migrated content, or if it's an issue with the logic used by this module to fetch image data in entity form. Maybe some layer of caching within the entity manager is getting corrupted? After the migration I'm assuming you have reset all caches, etc? (though I suppose that should not be a necessary manual step). The fact that you have appropriate records for each file in the database, but yet entity loading still fails is puzzling.

I've not been able to sit down with this in too much detail yet. It sounds like it could be tricky to replicate on my end.

gavz’s picture

Thanks for your help offline - by changing the image field from a single value to a multi value works around this bug. There is still an outstanding bug - it really should support single value (but it's great that we can work around it right now!).

rjacobs’s picture

Title: Unable to use the views plugin (help!) » Views plugin is not properly aware of field cardinality

Yeah, there is certainly a bug here.

For the official "issue queue record", a look at the instance where this problem was first replicated (gavz's example) revealed that the problem only occurs when a view field that's used as an image source is single-valued. The reason for this is that the logic in Drupal\juicebox\Plugin\views\style\JuiceboxDisplayStyle::getItems() makes as incorrect assumption that the target_id (fid) info from each view row will be represented as an array, which is not the case for single-value fields. The final result was that the fids for single-valued source fields were getting incorrectly calculated.

After looking at this further is also occurs to me that we may have some issues with the way multivalued fields are handled in as well. Currently we are "safely" just grabbing the first value and ignoring the rest, but the way we do this is not friendly to the "Multiple Field Settings" options on the field config in views. So if someone has some offsets set there, or is doing some grouping, those settings won't be reflected in the gallery output. Because these "Multiple Field Settings" are loosely supported in 7.x-2.x, and because we are shooting for feature parity there, I'll need to give this a bit more thought before figuring out the best way to implement a change.

In the meantime things should still work alright for multivalued field sources.

rjacobs’s picture

I needed to mull this over a bit. I was hoping that there would be a way to support multi-valued fields in some basic way, but on further investigation I don't think it will be possible in any reliable way. Views does expose some "Multivalued Field Settings" which makes it possible to split each value from a multivalued image field into completely separate views rows, which was a feature that tended to integrate pretty well with this module in D7. However, in D8 all the field-specific settings (including the multivalued field controls) work a little differently, and we can't tap into them the same way safely anymore. As a result I'm thinking that it makes the most sense to just enforce a rule that only the first value of a multivalued field will be used in the gallery. This also ensures a more logical relationship between image and caption/title source data for these cases.

So to fix this bug we just have to be sure that Drupal\juicebox\Plugin\views\style\JuiceboxDisplayStyle::getItems() can work with mixed values (strings and arrays) as it fetches field id info from view fields. That's what the attached patch does. The patch also tweaks the views Juicebox formatter configuration screen to help make this all more clear to the end-user.

  • rjacobs committed 4d4439e on 8.x-2.x
    Issue #2649310 by rjacobs, gavz: Make views plugin properly aware of...
rjacobs’s picture

Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

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