MiniGalleria-Talk

Summary: Talk page for Mini with Galleria.
Maintainer: Petko
Users: (View? / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.

Suggested code change

SteP 2015-10-23:

As regards the recently introduced '::' title/description settings, I suggest changing the code as shown further down to be able to set null title and description with "::". With the new code you will be able to use
>>Galleria<<
Mini:Page1/*.jpg"::"
Mini:Page2/with-title.jpg"title::description"
>><<
to hide titling for all pictures but with-title.jpg. With the current code you could use " :: " but when the title container is styled with a background color Galleria shows colored boxes for title==description==" " instead of an empty div. The new code in mini-galleria.js:
  function getDataConfig(img) {
    var x = $(img).attr('title');
    if(x=='::') return { description: '', title: '' };
    x = x.split(/::/);
# same as current code...

It already does that. The code currently in place will return exactly the same object { description: '', title: '' } as the one you suggest, if you use "::" for a tooltip title (note the lack of spaces). --Petko October 23, 2015, at 04:50 AM

Customize description and selectively slide open picture info <div>?

SteP 2015-09-08:

  1. Currently the filename is used to set the picture description in the Galleria infoBox. Is there a way I can replace the file name with text of my own choosing? I know I can set the title with Mini:file.jpg"title", but what about the description?
  2. Is there a way to slide open Galleria's infoBox by default so all text is visible? Galleria's option showInfo_true turns on/off the infoBox toggle button, but the user still needs to click the button to see the text. I was hoping that some markup like %open-hook%Mini:picture.jpg"title" would insert class open-hook into the <div class="galleria-info-title">title</div> that Galleria generates, so that I could then run some jQuery to auto-open div.open-hook But no, %open-hook% seems to be lost somewhere, so I can't use jQuery, at least not in this way. Any ideas?

Given requirements 1 and 2, please advise me, is Mini with Galleria the right recipe for me or are there better suited cookbooks? Thanks in advance.

I released a version which allows you to set "Title::Description" for each picture, see GalleriaDescription. To have the info box open by default, this can be set in the "Theme" script. For example, in galleria.classic.js, before line 54 "}else{" insert a line "info.toggle();". You should copy the theme to a new folder (or at least that file to a new name) and modify your own copy so that you don't lose your changes if you upgrade. I wouldn't know if other recipes are better suited, maybe. :-) --Petko September 08, 2015, at 11:25 PM

Thanks Petko! I downloaded and tested and it's really what I needed. I can set title and description separately and I can even hide the title but show the description, or show the title and hide the description. Perfect. I see that you also added a way of setting Galleria's floating point option values directly. Thank you again! --SteP September 09, 2015, at 02:51 PM

Petko, why do all files and directories in the galleria.zip archive, including folder 'pub', have permission equals to 604? Should I change permissions on my wiki to 604? Before seeing 604 in galleria.zip I thought that 644 for files and 755 for directories should be used throughout the wiki. SteP September 10, 2015, at 07:12 AM

Don't change your existing permissions, unless you know what you're doing. Do set the new files to the existing permissions. On my server there are other users in the 'users' group like me, and I don't want them to have permissions to read my disk files; the server process is in the "other" group and it needs permissions to read, but not to write those files -- on yours the server is probably in your group. If you don't install and manage your own server (root), chances are that it is properly configured, so simply drop the files with FTP and keep those default permissions. Unless PmWiki asks you to create the directories "wiki.d" and "uploads" and set their permissions once. --Petko September 10, 2015, at 01:10 PM

I've configured my packing script not to store unix permissions anymore, so from the next version this will not cause confusion. --Petko September 10, 2015, at 01:42 PM

div.img inside div.Galleria issue

SteP 2015-08-28: With PmWiki 2.2.78 I can't get the canonical example to work.

>>Galleria<<
Mini:*.jpg
>><<

I see that PmWiki builds this DOM

<!--PageTitleFmt--><!--PageText-->
<div id='wikitext'>
<h3>Photo</h3>
<div class='Galleria' > 
<div class="img"><a href="http://localhost:8010/uploads/Main/Photo/2.jpg" class="minilink" rel='lightbox_mini' title="2"><img class="mini" src="http://localhost:8010/uploads/Main/Foto/th00---2.jpg.jpg" title="2" alt="2" border="0" /></a></div>
</div>
</div>

I suspect that the extra <div class="img"> that scripts/stdmarkup.php line 329 injects behind the scenes confuses pub/gallery/mini-gallery.js. I could be wrong, so firstly I ask, "Is the injected <div class="img"> a problem for this recipe, or does mini-galleria.js deal get past it?" Anyway, after the page has finished loading and js is done, the page is empty, except for the <h3> element, no galleria viewer, no Mini thumbnails. Chrome js console is showing this message

Uncaught Error: Fatal error: Stage width or height is too small to show the gallery. Traced measures: width:500px, height: 14px.

So I change galleria options this way

>>Galleria transition_fade autoplay_2000 width_100pct height_1000<<
Mini:*.jpg
>><<

And this time js console shows:

Uncaught Error: Fatal error: Stage width or height is too small to show the gallery. Traced measures: width:940px, height: 14px.

Apparently galleria (the viewing script) didn't accept height=1000. However, I suspect this is actually again due to the div.img issue. I could be wrong. Anyway, the js debugger shows that mini-galleria.js is setting a[2]=1000 correctly.

Then I change galleria options this way
Note: More recent versions of Galleria don't seem to offer the 'ratio' option anymore, but there still are other options that can take a floating point value. SteP September 09, 2015, at 03:02 PM

(:comment 0.5629 => 16/9 ratio:)
>>Galleria transition_fade autoplay_2000 width_100pct ratio_0.5629<<
Mini:*.jpg
>><<

And this time js console shows:

Uncaught Error: Fatal error: Stage width or height is too small to show the gallery. Traced measures: width:940px, height: 14px.

Here the issue occurs before mini-galleria.js gets called. PmWiki sets the last class name to height_0, or so it seems from the js debugger. It makes sense, I don't know if '.' is a legal character in class names. Is there a way to work around parsing floats in class names?

Thanks in advance.

There has always been a <div> there, just recently it got the class "img", and it shouldn't cause a problem (it works on my wiki). The height_1000 classname appears to also work in my wiki: the set is actually 200 or 1000 pixels high. However, if I try to set it to a smaller number like 100, it breaks -- not sure why. The fraction part indeed is not recognized by PmWiki so it would not work; what would work is to set both width and height as integers. (I took the chance to update the download archive to the latest versions of jQuery and Galleria, please test it and report.) --Petko August 28, 2015, at 05:56 PM

SteP 2015-08-29 OK. By upgrading to the new jQuery/Galleria combo I can see some progress in my page. Now I do get a visible Mini thumbnail on the page, while before nothing was visible. However, I still get the error message about insufficient "Stage height". So I think I need to fully debug galleria.js at this point. I will report back my findings here. Meanwhile, the new package you uploaded has enough differences from the previous one that MiniGalleria should be updated. I will edit that page and you can revert if you don't like it.

Thank you SteP! --Petko August 29, 2015, at 05:12 PM

SteP 2015-08-29 I traced down the issue I was having with Galleria to a timeout. The learning from it is:

With Galleria don't ignore '404 CSC file not found' errors.

Details: This code fragment in galleria.js:
    // the gallery is ready, let's just wait for the css
    var num = { width: 0, height: 0 };
    var testHeight = function() {
        return self.$( 'stage' ).height();
    };

When this code is executed, at the end of the gallery construction process, it waits up to 10000 ms for the gallery skin's CSS to be loaded, which can happen from a <link> tag in the source code, or through a jQuery function. So, when the gallery CSS isn't processed within the timeout, Galleria gives up, rightly so, and reports the js error message "Insufficient Stage width or height to display the gallery."

In my case, the PmWiki skin I was using declared two <link>s for the skin, and the first <link> pointed to a missing file on the localhost web server. It didn't matter that the second <link> pointed to a valid Galleria skin, the first bad <link> prevailed.

As regards Galleria's minimum accepted height, galleria.js function 'until' sets an arbitrary 50px height lower hard-limit with this code

    return( self._stageWidth &&
            self._stageHeight > 50 ); // what is an acceptable height?

Does Mini with Galleria require that images be re-uploaded if the server configuration is changed?

I ask because when I moved my server with already uploaded images to another location, which involved changing some of my farm path variables, I discovered that on Firefox, SeaMonkey, and Opera, but not on Safari or Chrome, I began to see the message "Image gallery could not load" instead of seeing the gallery. However, when I uploaded new images to the new server, the gallery worked fine on all browsers.

-- RandyB August 28, 2014, at 11:46 AM

If cache is enabled, you may have to either delete the *.mini-cache.txt files, or edit and save the gallery pages. --Petko August 28, 2014, at 12:20 PM

I didn't specify $Mini['EnableCache'] = 1;. I only have $Mini['EnableLightbox'] = 1;. -- RandyB August 28, 2014, at 01:10 PM

I don't know then - may be some temporary caching like CDN enabled on the server, or a lag in the filesystem synchronization of network-mounted disks. When migrating a wiki I also double-check file permissions, but if now you're able to see the previously uploaded files, you probably don't have a permissions issue. --Petko August 28, 2014, at 08:49 PM

I have a site with images in different pages, with individual upload directories. Is there a way to modify the all option to include all sub pages?

Mini:a*.jpg
Mini:OtherPage/*.jpg

Something like...

Mini:*/*

Or similar?

Thank you,
--Monte December 3, 2014 at 11:29 AM

Sorry for the late reply, not sure why I didn't notice the question. It may possible to do this with a pagelist with a custom template, something like this:

>>Galleria<<
(:pagelist group=Main fmt=#mini:)
>><<

(:if false:)
[[#mini]]
Mini:{=$FullName}/*
[[#miniend]]
(:ifend:)

--Petko

Talk page for the Mini with Galleria recipe (users?).