HighslideGallery

[TechAngel85]

HighslideGallery is an extension for MediaWiki written by our very own, stoppingby4now.

 

Please see the link above to find out how to use it on the wiki. It is preferable to use the HighslideGallery to include an image gallery on wiki pages rather than using the Gallery and GalleryItems templates, since those templates were created specifically for system pages such as the mod pages.

[TechAngel85]

Are the number of galleries you can create on one page limitless? The reason I ask is because the ENBSeries INI Guide will have sometime like 800 galleries on it.

[z929669]

There is probably some limit, but I would not guess that it is limiting with regard to your needs. I'll bet you could have 800 galleries. Any integer can be used to indicate an individual gallery.

 

The main limit is page load time though, so be strategic in your implementation and create subpages maybe to hold gallery blocks ... or just limit top pages to 10-20 (... 50-100) galleries and continue them over several top pages.

[Kelmych]

I was hoping there would be a Highslide alternative to the ordinary Gallery, thanks S4N    .

[TechAngel85]

I was hoping there would be a Highslide alternative to the ordinary Gallery, thanks S4N    .

Apparently this has been implemented probably since 2012 when he created it. It's just that no one knew about it so once I found out, I figured I'd spread the word with a thread.

[z929669]

All one needs to do to see what tools are available on the wiki:

 

TOOLBOX > SPECIAL PAGES > Version

 

There is a lot of info on Special Pages too, and don't forget other tools that can be used on any page via other options in the top-bar menu. mediawiki has lots of info to offer for those curious enough to investigate and play around.

[stoppingby4now]

Are the number of galleries you can create on one page limitless? The reason I ask is because the ENBSeries INI Guide will have sometime like 800 galleries on it.

There is no hard limit, however there is a practical limit in that you don't want 100's of images having to load on a page for every view.

 

The gallery ID can also contain letters as well as numbers. 1, A, 1A, 2345ABC, ABCD12 are all valid for example (it's just a string that is used as part of a div id attribute, and associated in highslide during initialization). If you don't specify an ID, one is randomly generated and guaranteed to be unique, in which case that image will be the only one in its own gallery for the page.

[TechAngel85]

Would the Header Tabs prevent images from loading that aren't in the currently selected tab? I've never really noticed if this is so or not because the pages load so quickly.

 

I've also came up with a scheme for the galleries to keep track of them

[stoppingby4now]

No they won't. All of the code for the page is loaded in one go, so the links to the images exist, and the browser will load them. Makes for awesome instanct views when switching tabs, but not so great on the load time.

[stoppingby4now]

I was hoping there would be a Highslide alternative to the ordinary Gallery, thanks S4N    .

There was an implementation already called HighslideThumbs, but it did what almost every other gallery extension did and considered all images in a page to be in a gallery. I wrote HighslideGallery because not only did I want to create multiple galleries in a page, but I wanted control over what images would be galleryfied (new word), while leaving others as basic images in-page. From what I can tell, my extension is also the first gallery type one that generates all of the code for the galleries during the page cache phase and is saved in the actual cache, while all the others modify the html on-the-fly for every page view pre-render. Though to be fair, the others were all written before a hook was added in I think version 1.17 which made that possible. :)

[TechAngel85]

I don't there is much to fear about the number of galleries. I first thought that there might be one for each and every line of the enbseries.ini file (~800 galleries & 1600 images); however, as I'm working on the Guide formatting it and as I'm working with the ENB settings themselves, I think that number will be cut down between ~130 to 250 galleries max. For many of the settings there are the same setting for Sunrise, Day, Night, Sunset, Interior Day, and Interior Night. Most of these can be combined since the setting does the same thing just during that specific time of day. Some of the settings also can't be shown in images either so those are out as well.

[stoppingby4now]

We'll just need to work out a multiple page structure for your guide so all of the images aren't loaded at once. A guide with smaller images that depict UI, or clips of settings aren't bad even in mass, but when you start throwing 1080p screenshots, 10 is really the limit for an acceptable user experience. Best to probably break off the screenshots into separate pages, and associate everything with a unique category.

[TechAngel85]

Okay, we'll do what we need to do when that time comes. Right now it's taking just over 3secs to load on first view and about 1.5sec on secondary loads, but there aren't a lot a custom images. Just only one "dummy" image that I'm using as a placeholder so I know what the formatting looks like.

[stoppingby4now]

Before we get off into solutions, I need to review the extension. It just hit me that I believe I was using wiki methods for the initial generation of the html for drawing an image if it was hosted local, and then wrapping HighSlide around it. The implication being that what is initially shown on the page would be a much smaller in size thumb, and not the original full-size image. The full-size image would then be loaded when the gallery is first opened in HighSlide. Can't do that for external images though.

 

It's been awhile since I wrote it, so will review and report back.

 

EDIT: Yup, that is what I did. Obviously there would have to be some testing, and I doubt you'd still want hundreds of thumbs all loading on the page at once, but it really depends on what the thumb size ends up being. In this case, the smaller you can make the images for adding to a page, the better (like 100 or 150px in width). That's what makes Galleries so great. A smaller thumb size on the page should not matter, as the real glory is displayed when the gallery is opened.

[TechAngel85]

I'm about half way through the initial formatting so if I'm going to need to change the thumbnail size, I'll need to know before I start adding the custom images. Copy and pasting entire lines is much faster than having to copy and paste on small section of a line (now that I think about it, I could simply use Notepad++ to replace it all in one go...). I chose the size I did (450px) to give the users a quick reference of what the parameter does without having to necessarily click the images to even get an idea. Those users needing more detail than that could still click the image to view in greater detail.

 

I'm flexible. I just don't want to sacrifice all of my ideas and vision for the Guide.

[z929669]

The dummy image is small, but I am not sure if browsers (or wiki caching) treat the images as one instance repeated many times or many instances repeated one time (i.e., for 300 duplicated images, 1 cached image versus 300, respectively).
 
I think that a good multi-page strategy could be done in two ways: creating one page per setting at the top level (and adding all to a unique category or, better yet, a subcategory of [[Category:Guides]]), or creating one top-level page and giving each setting a subpage.  I searched the wiki using term 'screenshots' ... Terrain Bump screenshots subpage came up, and it belongs to [[Category:Mod Subpage]], which belongs to [[Category:Mods]], so this was a successful search for me, and it seems to be a logical way to organize mod-related screenshots. (but where the heck did the images go??).
 
Anyway, the ENB INI guide could use /Screenshot subpages by setting and use [[Category:Screenshots]]. I think then each subpage will inherently belong to [[Category:Guides]] as well
 
EDIT: Actually, a category hierarchy makes sense too ...

 

Key:

Category[subcat][sub-subcat] (pagename/subpagename/subsubpagename)

[*]Guides (Guide:ENB)
[*]INI Guides (Guide:ENBSeries.INI)
[*]INI Settings (Guide:ENBSeries.INI/Environment) [*]Screenshots (Guide:ENBSeries.INI/Environment/Screenshots)

the subpages are INI section names. I know these are subpages (s4n does not like them), but they are also categorized effectively, and the page names are intuitive. Searching by any term in the page name will bring that page near the top of the search result, and it is simple for users to navigate either visually or via the URL.