Panels compatibility when individual fields are added to a pane

Hi jesuis,

That message that you saw was added to warn users about a incompatibility with a specific views configuration, see: https://www.drupal.org/node/2006830#comment-7984443. The problem was that image fields in individual views rows cannot really be formatted as Juicebox galleries, but some users were still trying to use this configuration and getting confused when it didn't work.

The fact that this warning is triggering inside of a Panels configuration form may or may not be an appropriate thing. It would help to know a bit more about how you are trying to incorporate a Juicebox gallery via Panels. Are you trying to "embed" a specific node that contains a field-based gallery inside a Panel? Are you incorporating a view inside a Panel? Is your Panel going to represent a single image field and you want to format that as a gallery?

I'm not super-familiar with Panels, but if you provide a bit more context about how you are trying to configure things it might help clarify if the error is being triggered incorrectly or if you are truly trying to do something that is incompatible with the module.

Ok, thanks for the additional info.

It sounds like the notice you are seeing might be "misfiring", so it's likely that bypassing that warning for the specific case of a Panels configuration form would address this. This would still need some additional investigation though. I don't currently have any test environments that use Panels, but it's something that I'd like to look into more at some point.

If anyone else wants to dig further in the meantime, the conditional check that triggers that notice ("The Juicebox field formatter is not fully supported within individual view rows...") is at the very top of juicebox_field_formatter_settings_form() in juicebox.field.inc. The special logic there can't be removed entirely as it's necessary to catch a couple cases where the field formatter is known to be incompatible, but perhaps it could be adjusted to still allow Panels usage.

Jeseuis, you're the only person i have found that has stated they have juicebox working in panels. Can you tell me/us how you set up your view?

As for the second error you got. I had the same issue and got this fix from the juicebox folks directly.

For: 7.x-2.0-beta5+8-dev (or wherever Line: 174 is in the file for different versions)
File: sites/all/modules/juicebox/includes/JuiceboxGallery.inc
Line: 174
- return $dom->saveXML();
+ return $dom->saveXML($juicebox);

Regards,

Mark

I think that I was able to replicate this. As far as I can tell this is an issue specific to the panels node sub-module, and not panels as a whole. The problem only seems to arise when configuring a node of type "panel" such that an image field is placed into a pane and then formatted as a Juicebox gallery. I hope this is consistent with both your observations.

If so the problem is related to the fact that panels node handles fields in it's own custom way, and does not store the field's display configuration as part of a "view mode" like a normal Drupal entity. This view mode concept is something that the Juicebox module depends on when building the gallery's XML. So if we can't associate a view mode with the field, we don't have a way to get the XML that the javascript library requires to build the gallery.

As this is an example of a low level incompatibility between the two modules, I'm not really sure what the best fix would be. Jesuis's solution to build a view that essentially mimics the output of the individual node's field, and then format that as a Juicebox gallery that can be added to a panels pane, is a very good workaround. Very creative. Though it's a little extra work I think it could certainly achieve the same result.

Regarding the pending need to add a gallery to individual "teasers", I think I would need to know more specifics before I could be much help with that. Are you trying to format the teaser display of a "panel" node as a gallery? If so wouldn't the same view-based workaround work there as well?

Next, regarding the "fix" mentioned in #4 (the edit to sites/all/modules/juicebox/includes/JuiceboxGallery.inc), this is most likely a very different issue. It sounds like System Lord's Drupal instance is printing extra whitespace at the top of every page, which is then corrupting all XML output produced by Drupal. This is a problem that's probably unrelated to this module and can almost always be traced back to another 3rd party module or theme with an extra line-break at the top or bottom of one if its php code files. See these notes for more on that. Though that fix suggested by the Juicebox library people will get around this, it essentially masks an important issue that you may want to address in order to avoid other problems with other modules later.

Anyway, in regard to the core feature request here, direct native support for panels node would certainly be a nice thing to have, but I'd really need to think more about how to make it work.

rjacobs, you said something very interesting.

It sounds like System Lord's Drupal instance is printing extra whitespace at the top of every page...

I'm curious how you concluded that? It's interesting because I'm having an issue with whitespaces in URL like this:

https://www.drupal.org/node/2189571#comment-8694935

Location group says its not their module causing it, although some responders believe it might be. In any case you may be on to something wrong with my site. Please, what made you say conclude this?

Thanks

Mark

Mark, the "whitespace" issue that came to mind is one where extra spaces or line breaks appear at the start of the final Drupal page response. These can be inadvertently added due to a php file somewhere in one of your modules or theme that has whitespace at the beginning of the file (extra spaces outside of the <?php wrapped part will get "printed" to the output). For normal HTML pages this is usually not a problem as the browser just ignores that whitespace, but for XML output (like an RSS feed or the Juicebox gallery XML) this whitespace can cause the returned result not to validate correctly in your browser.

I assumed this is related in your case because you said the modification to ~line: 174 of sites/all/modules/juicebox/includes/JuiceboxGallery.inc made the "Config XML file not found" error go away. That change modifies the XML output such that it does not contain an XML declaration at the top. Without that declaration the browser no longer tries to validate the XML, and the whitespace error essentially gets ignored. It's a workaround, but not an actual fix for the whitespace issue that could cause problems with other modules that produce XML or RSS.

I don't think this would be related to your other issue though. That seems to be specific to the generation of a very specific part of a page (a URL) as opposed to the final full page response.

So it turns out the issue from the OP is really just another form of the issue that I mentioned earlier:

#2006830: Support for views row field formatter (Views Not saving Juicebox Configuration and reverting to default when saved)

It's also related to some performance notes posted long ago here:

#1906860: Notes on performance when core page caching is disabled.

This makes me motivated to really find a workaround of some sort (it's a relatively rare issue, but it's going to recur). The only straightforward solution I know is to implement a somewhat "experimental" XML caching concept that I have some mixed feeling about. Because I'm hesitant to include this concept in the main module, I've put together a separate sandbox module (that extends the main Juicebox module) for it here:

https://www.drupal.org/sandbox/rjacobs/2302609

All the details are posted with that sandbox description, so I won't repeat them here. @jesuis and @System Lord, perhaps you want to try it out?

After working with panels a bit more I can see that this problem would not be limited to "panels node", but could happen in any case where an individual field containing a gallery is added to a pane.

Anyway, the juicebox_xml_cache sandbox module should provide a solution for all these cases, and may be considered for addition to the main Juicebox module. If anyone else is able to test and report that would be great.

Juicebox XML cache works great in panelized noded with a Multi image field.
Do you know more about the external caching issues mentioned on the sandbox Page (p.e. Varnish)?

Hi Patrick,

Glad to hear it works, and thanks for testing. I currently have no specific reason to believe that this caching would cause problems with external caching systems (Varnish, etc.). I just added that note to the sandbox page to be conservative given that I've not personally been able to do any real testing. I did encounter some conflicts quite a while back related to external caching and Juicebox, which is one of the reasons I felt the need to be conservative (see #2030997: Add feature to force bypass of browser and network caches when XML changes). However, those problems were resolved, and the resolution should continue to help ensure things work alright with external caches (even with this extra "Juicebox XML" cache added).

Are you currently using Varnish?

I'm having the same problem with panel panes and individual image fields. The error I'm seeing is because of a 403 on juicebox/xml/field/node/14471/field_image_field/unknown

If I add the field to the full display mode a proper page callback is generated field_image_field/full and the gallery works.

I'm going to investigate the Juicebox XML Cache module and other fixes and will report back ASAP.

In order to load the settings that field_view_field needs you'd have to load the panel pane configuration and then use it in JuiceboxXmlField->getXml(). This would require passing extra parameters to the page callback and I'm not sure how the module maintainer would prefer this. I'm also not incredibly familiar with ctools/panels internals, so someone else would probably be better suited to write a patch :)

I'm guessing that if we can pass the panel pane id (pid), we can load the configuration and generate the render information.

I'm going to punt and use a view or separate view mode for this field. Would be interested to see what pans out here though.

In order to load the settings that field_view_field needs you'd have to load the panel pane configuration and then use it in JuiceboxXmlField->getXml(). This would require passing extra parameters to the page callback

Yep, that's exactly the crux of this issue. The formatter has to somehow pass all the details that are needed to (re)build the field as part of a separate XML request. This is not really something that a field formatter typically does in Drupal, as the formatter is supposed to be agnostic to how the field was built in the first place. So, long story short... it's tricky.

For a normal field instance this is not too hard as we just need to pass-on machine names for things like field name, bundle, entity ID, view-mode, etc., and then the Drupal field API can use this info (notably the bundle and view-mode names) to easily fetch the appropriate field instance configuration in a consistent way. However, when the field is "embedded" into some 3rd party object, like a panel or a view row, the field configuration is usually stored and loaded in a way that's unique to that 3rd party object. Panels seems to use a common ctools concept of "fake field instances" for this, but the method for accessing the field instance configuration is still panels-specifics, so Juicebox would need lots of Panels-specific support to be built in. That would be fine, but the problem is not limited to Panels, really anything that uses its own means to store a field instance configuration would need special support and logic to be added to this module for it to work.

Anyway, my stab at a "generic" solution for this was the Juicebox XML Cache concept. It just builds the XML while building the embed code, caches it, and then makes it available to the XML request without any special knowledge about where the field instance came from in the first place. See the "More Details" info at that link above for more.

If the XML Cache concepts actually works well, it should probably just be bundled into the main module. Still, I'd love to know if anyone has any other ideas on how to deal with these cases technically.

The Juicebox XML cache logic, which solves this problem, appears reasonably stable now. I've opened a separate issue getting it integrated into the main Juicebox module here: #2380741: Integrate juicebox_xml_cache.

I'll leave this issue open a bit longer, but it can probably be closed soon assuming the cache solution remains the best way to fix this.

A solution for this has now been committed as part of #2401389: Consider alternate ways to store and generate gallery XML, and will be included in the next release (7.x-2.1). In the meantime anyone can try things out by using the most recent dev version.