The "extend" option does not work because the Drupal.settings API passes whatever you type in the box as a string, rather than a raw Javascript Function.

The Galleria documentation on the options array states that the "extend" option expects a function. However, for some reason, Drupal's drupal_add_js(..., 'setting') is making it into a string.

You can see a demonstration of a working "extend" option by viewing the source of Galleria's Classic Demo #2.

Assigning to myself so that I can write some steps to reproduce.

Comments

mparker17’s picture

Title: Galleria "extend" option expects function, Drupal.settings gives string » Galleria options expect different types of variables; Drupal.settings only passing strings
Version: 6.x-1.0-beta3 » 6.x-1.x-dev

Confirmed that this happens on 6.x-1.x-dev.

Turns out that all options passed through Drupal.settings are being output as JavaScript strings; so I'm changing the title of this.

mparker17’s picture

Title: Some Galleria options expect JavaScript functions, Drupal.settings gives string » Galleria options expect different types of variables; Drupal.settings only passing strings
Assigned: Unassigned » mparker17
StatusFileSize
new1.1 KB

After a bit of experimentation, it seems that, by casting the output of views_slideshow_galleria_variable_get(), I can get it to work. See attached patch file for one example.

mparker17’s picture

Title: Some Galleria options expect JavaScript functions, Drupal.settings gives string » Multiple issues with passing Galleria options discovered when trying to use "extend" option
Assigned: mparker17 » Unassigned

I've been testing a bit here; and I'm starting to see that there are multiple issues which prevent me from having Galleria execute my "extend" JavaScript. Expect a bunch more bugs to be filed later.

However, let's make steps to reproduce:

Platform

Client

  • Hardware = Macmini3,1
  • O/S = Mac OS X 10.6.4 (10F569)
  • Browser = Firefox 3.6.10 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10)

Server

  • Web Server = Apache/2.2.3 (Debian) mod_fastcgi/2.4.2 mod_webkit2/0.9 mod_perl/2.0.2 Perl/v5.8.8
  • PHP = 5.2.0-8+etch16
  • MySQL database = 5.0.32
  • Drupal = 6.19 (clean install)
    Modules enabled:
    • cck-6.x-2.8
    • filefield-6.x-3.7
    • imagefield-6.x-3.7
    • jquery_update-6.x-2.0-alpha1
    • views-6.x-2.11
    • views_slideshow-6.x-2.3
    • views_slideshow_galleria-6.x-1.x-dev

Steps to Reproduce

  1. Clear all browsing/download/form/search history, cookies, caches, active logins and site preferences from Firefox.
  2. Install a fresh, English copy of Drupal 6.19 on a blank MySQL database.
  3. Download the versions of the contributed modules listed above, and install them to sites/default/modules.
  4. Download Galleria at revision cf9ab014d15c41ce89faccb258da6612e677fccf and unzip it into sites/all/libraries. When I unzipped mine, it was automatically named aino-galleria-cf9ab01.
  5. Log in to Drupal as user/1 if you aren't already.
  6. From Administer -> Site building -> Modules, check off the boxes next to Content, FileField, ImageField, jQuery Update, Views, Views Slideshow, Views Slideshow: Galleria and Views UI, then click Save configuration.
  7. From Administer -> Site building -> Views -> Views Slideshow: Galleria, ensure that the Path to the Galleria Plugin is set to the src sub-folder of the Galleria folder you extracted earlier. In my case, Views Slideshow: Galleria automatically detected Galleria at sites/all/libraries/aino-galleria-cf9ab01/src.
  8. From Administer -> Content management -> Content types, add a content type.
    1. Click Add content type. Set the name to Album, the type to album, and click Save content type.
    2. In the list of Content types, click manage fields in the Operations column next to the new album type.
    3. Add a new field with the Label Images, the Field name field_album_images, the field type File and the form element Image. Click Save. Drupal will prompt you for more information about the image field. Under Global settings, check off Required, but leave everything else at the default. Make sure to Save field settings.
  9. From Create content -> Album, add two or three album-type nodes. I always click the Upload button before saving the page.
  10. From Administer -> Site building -> Views, click Add and create the view:
    1. Name the view album_gallery and make it a view on type Node. Leave the other options at their defaults.
    2. Add a filter on Node: Type; set it to Is one of and check off Album.
    3. Add a field: Content: images (field_album_images). From Format, choose Image; leave the other options at their defaults.
    4. From Style, choose Slideshow. Leave List type as Unordered list. Ensure Slideshow mode is set to Galleria.
    5. Add a Page display. Set it's path to gallery.
    6. Leave the other options at their defaults. Click Save to store the view. Under Galleria options, expand Advanced settings, and enter the following into the Extend box: function() { this.bind(Galleria.IMAGE, function(e) { $(e.imageTarget).css('cursor','pointer').click(this.proxy(function() { this.openLightbox(); })); }); } (this extend code was copied from the source of the Galleria homepage's Classic Demo 02).
    7. Save the view.
  11. Navigate to http://yoursite.example.com/gallery, click on the image that appears and observe the behavior.

Expected Behaviour

I should be able to click on an image to have it pop up in one of Galleria's lightboxes.

Actual Behaviour

I'm not able to click on an image to have it pop up in one of Galleria's lightboxes.

mparker17’s picture

Title: Galleria options expect different types of variables; Drupal.settings only passing strings » Some Galleria options expect JavaScript functions, Drupal.settings gives string
Assigned: mparker17 » Unassigned

Wow, I really wandered off-topic from my original problem here... resetting the title.

izmeez’s picture

Title: Galleria options expect different types of variables; Drupal.settings only passing strings » Some Galleria options expect JavaScript functions, Drupal.settings gives string
Assigned: mparker17 » Unassigned

Do the steps in #3 work with the patch in #2 ?

mparker17’s picture

Assigned: Unassigned » mparker17

Sorry, no. The patch in #2 is just an example. I'm still working on this one... I had a patch ready, but when I was doing my QA, it didn't work, so I've got to look over it and see what I've done wrong. I should assign it to myself, as I am more than half way there.

Check out #945084-6: Settings passed as wrong type. That patch doesn't fix the problem where JavaScript functions are being passed as strings; but it does solve problems with other variables.

mparker17’s picture

Title: Multiple issues with passing Galleria options discovered when trying to use "extend" option » Some Galleria options expect JavaScript functions, Drupal.settings gives string
StatusFileSize
new8.97 KB

I've got a patch that works for Galleria at commit cf9ab014d15c41ce89faccb258da6612e677fccf. It disables some options that break when settings.extend is defined (there are comments).

Because the JavaScript functions need to be passed un-escaped to the page, I've added a permission. A user must have that permission in order to edit the fields that must be output raw.

The Galleria library has changed a lot since I created this ticket. I'll try to adjust the patch to work with the latest version of Galleria.

mparker17’s picture

Status: Active » Needs review

Whoops... forgot to mark this as "needs review"

sgabe’s picture

I just encountered this bug. I would like to set the advanced "data_config" option to add rich HTML captions as described here. I tried the patch in #7, but that broke the whole gallery. So far I couldn't make it work, any help would be appreciated.

mparker17’s picture

Unfortunately, the Galleria JavaScript library is still quite unstable. The folks at Aino promised us a stable release in November 2010, but (at the time of writing, 2011-Feb-07) they haven't done so yet. The Galleria library's API has changed significantly since I started this issue on 2010-Oct-08, and Galleria's documentation isn't always accurate (as I found out when trying to fix this problem).

When I wrote the patch in #7, I was using the version of Galleria at commit cf9ab014d15c41ce89faccb258da6612e677fccf and the version of Views Slideshow: Galleria at the HEAD of the 6.x-1.x branch (last commit 2010-Nov-12 — at the time of writing, this is the most recent commit on the 6.x-1.x branch). Ensure that you have those versions installed before applying my patch.

It would seem that @aaron hasn't been able to keep up with all the API changes in the Galleria library (and honestly, due to circumstances beyond my control, I haven't touched Galleria since November either). If you really need to use the latest version of Galleria, you could help the community by writing and submitting a patch to this module so that it would work with the latest changes to the Galleria library (submit your patch in a separate issue though: it's a more–general—issue than this one). Once that's done (and, assuming that your patch doesn't fix this issue), let me know and I can try re-rolling this patch.

sgabe’s picture

Version: 6.x-1.x-dev » 6.x-3.x-dev
Status: Needs review » Needs work

This is still an issue for the 3.x branch. The "modify raw Galleria JavaScript" permission is a good call, but IMO it should be handled in a separate issue.

sgabe’s picture

Status: Needs work » Fixed
StatusFileSize
new1.07 KB

The attached patch is committed to the 3.x branches.

Status: Fixed » Closed (fixed)

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