Sticky Hover-over Thumbnails

[John Stewart]

Hi all,

I've recently upgraded my galloery install from 3.0.9 to 3.1.3. All went smoothly and I just had to remember to re-apply my hack that allows me to delete the resizes directories as they take up a lot of space.

One issue that remains, is that when hovering over thumbnails for photos or albums, the thumbnail expands to show the author and number of views. However, when you move the mouse away from the thumbnail, it doesn't shrink back to it's original size.

I've had a look through the theme definition and can't see any reference to hover-over functions, so if anyone has found a fix for this previously and could point me in the right direction it would be very much appreciated.

Best Regards

John

[JR]

John,

Glad things went well on upgrading G3 v. 3.0.9 to v. 3.1.3 -- as for the on mouse-over expansion of the thumbnail display you describe, I've never seen that happen in an out-of-the-box Gallery 3 installation of any version. I think this means that you also have a separate module installed that is creating the rollover effect which is now sticking. That module probably needs to be tweaked to work with v. 3.1.3.  (or possibly PHP 7 if you hosting server account is running that). There is a list of modules you can see when you log-in, click on "Admin" at the top of the page and select "Modules" from the drop-down menu. The list will show all modules installed in your system and there will be a check-mark next to those which are currently active.

Scroll through them and see if there are any checked active modules where the description indicates they are providing the hover-over display. Try turning the suspect module off and then seeing if the hover-over behavior is still there when you do. If you find the module responsible for the behavior, let us know its name. Also, tell us what theme are you using -- always good to know since some themes (like Gray Dragon) add additional functions and effects. Also helps to know which version of PHP your hosting server account is running.

-- J.R.

---

Collabro Limited

Company Registration Number 257810

Registered Office 

Union Plaza, 1 Union Wynd, Aberdeen, AB10 1DQ

Correspondence: Collabro, The Enterprise Centre, Aberdeen, AB23 8GX

www.collabro-group.com

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Collabro Ltd or associated companies in the Collabro Group.. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error and delete it from your system.

WARNING: Although Collabro has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments; our  company email is monitored for lawful business purposes.  Collabro accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing.

Collabro Ltd. is a limited company registered in Scotland. Registered number: SC257810. Registered office: Union Plaza (6^th Floor),1 Union Wynd, Aberdeen AB101DQ.

--
WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
 
To post a NEW MESSAGE to the group, send an new email to:
gallery...@googlegroups.com
 
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
You received this message because you are subscribed to the Google Groups "Gallery 3 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gallery-3-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/125f3939-7a15-4a58-a18d-74e837fbacden%40googlegroups.com.

[John Stewart]

Thanks very much J.R. :)

I did try to include photos of the modules in use, and a link to my website in the original post, but it didn't seem to get through. I'm not sure if attachments are prohibited.

You can view the issue on my website here: https://www.flatoutphotography.com/gallery3/2017

I'm using a theme called left-right-wind, which is a modified version of the Wind theme that allows users to navigate between photos using the left and right arrow keys. There's also a module that allows navigation using left/right mouse clicks as well, which was primarily designed to stop people right clicking on an image and downloading it.

I'm still using PHP 5.6.40 as I wanted to get everything working as it was under this version before updating to version 7. I reckoned if I came across any problems, it would be harder to tell if it was the PHP version or the gallery3 update that broke it.

Best Regards

John

You received this message because you are subscribed to a topic in the Google Groups "Gallery 3 Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gallery-3-users/UPmKWz_dN3c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gallery-3-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/51b06450-7913-c96e-e80d-c2025bd73a0a%40thepostalzone.com.

[Adrian London]

I remember having an issue like this when my site upgraded php.  If only I could remember the fix! 

I had thought the upgrade to G3.1 fixed it, but I guess not.  I *might* have copied over "ui.unit.js" from one of the standard themes provided by G3.1 and copied it over the one my theme uses.  You could try that (taking a backup of that file first).

[John Stewart]

Adrian, 

thank you very much! I copied the javascript file from the widewind theme from gallery 3.1.3 and replaced the version from my existing theme and it's solved the problem.

For information, I use the module called info to display the extra information which includes the author and number of views for each album/photo on hover over:

Best Regards

John

On Wed, 30 Dec 2020 at 16:58, Adrian London <ahad...@gmail.com> wrote:

I remember having an issue like this when my site upgraded php.  If only I could remember the fix! 

I had thought the upgrade to G3.1 fixed it, but I guess not.  I *might* have copied over "ui.unit.js" from one of the standard themes provided by G3.1 and copied it over the one my theme uses.  You could try that (taking a backup of that file first).

--

WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
 
To post a NEW MESSAGE to the group, send an new email to:
gallery...@googlegroups.com
 
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
You received this message because you are subscribed to a topic in the Google Groups "Gallery 3 Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gallery-3-users/UPmKWz_dN3c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gallery-3-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/87286cfd-ee11-498e-9496-63976f47437cn%40googlegroups.com.

[Adrian London]

Cool, so my memory does work even if I don’t always believe it will :)

I also display stuff under my thumbnails, although it’s there permanently.  I store the date/time of the earliest and latest photo in an album (using a modified version of the Edit Creation module) and display that as a date range underneath each one, along with a count of photos and count of sub-albums (if any).  For photos, I just display the date and time it was taken.   Another module, called “Update Albums” recursively updates all parent albums with the date of the latest photo.

By the way, for the person who modified their theme to use keyboard shortcuts for navigation (was it you?  I lose track of threads when they all hit me by email), there’s a module called Arrow Navigation which does it. I also modified that (I think, maybe. directly in the theme) so that “esc” on my macbook goes back up the hierarchy, so it’s a quick way to get back from a photo to the album (and from there to any parent album etc).

Sorry for the theme colours in my screenshots, it’s gone midnight here and for fun my theme fakes a dark mode (using css “invert”) after midnight for a few hours.  Even my family don’t really view my photos in Gallery any more as they expect me to iMessage them the important ones, so it’s mainly just for me and my own entertainment!

[JR]

John,

Sorry I didn't get around to looking at your Flatout site until today -- New Year's celebrations and all... but I'm wondering if you found the answer to the "sticky" hover-over thumbnails because as I move about your site today, Jan. 20, the hover-overs seem to be working fine... popping up when the cursor moves over thumbnail and then immediately disappearing when it moves off the thumbnail. I've tested with Firefox running in both windows and linux.

By the way your modified theme looks very good and seems to work flawlessly.

Is the code which you used to allow you to delete the resizes directory fairly easy to apply? I've wanted to do this myself for sometime, now since the images in my var/albums and in my var/resizes are always identical and it would be nice to free up all the storage space the redundant resizes eat up. But when I tried to hack around the system wanting to access resizes directory several years ago, I couldn't quite get it to work.

-- J.R.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/CAAoCrWyZcgEDYJyACih3RKuhoXdr6iAnzvk4ZFVGdy4eJLPeOg%40mail.gmail.com.

[John Stewart]

Hi Adrian,

many thanks - your memory saved me hours (or longer) of hunting down the issue.

I can't take credit for modifying the theme to use the keyboard navigation, it was one that I downloaded many years ago and simply modified the CSS to change the colours. I think I also have a keyboard navigation module, but it's probably switched off.

My albums are all event based, so I very rarely need to add new photos to an album, but you've got me thinking of a great way of sorting out some family albums :)

Best Regards

John

--

WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
 
To post a NEW MESSAGE to the group, send an new email to:
gallery...@googlegroups.com
 
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
You received this message because you are subscribed to a topic in the Google Groups "Gallery 3 Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gallery-3-users/UPmKWz_dN3c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gallery-3-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/E36D873E-C2B5-48CB-9661-1C4AF7671872%40gmail.com.

[John Stewart]

Hi J.R.,

yes it was me who modified the code to not need the resizes. It's a very simple change to a single module.

The file to change is /modules/gallery/models/item.php

All you do is change the single reference in the resize_url function as shown below:

Old

  public function resize_url($full_uri=false) {

    $relative_path = "var/resizes/" . $this->relative_path();
    $cache_buster = $this->_cache_buster($this->resize_path());
    return ($full_uri ? url::abs_file($relative_path) : url::file($relative_path)) .
      ($this->is_album() ? "/.album.jpg" : "") . $cache_buster;
  }

New

  public function resize_url($full_uri=false) {

    $relative_path = "var/albums/" . $this->relative_path();
    $cache_buster = $this->_cache_buster($this->resize_path());
    return ($full_uri ? url::abs_file($relative_path) : url::file($relative_path)) .
      ($this->is_album() ? "/.album.jpg" : "") . $cache_buster;
  }

This allows you to delete all the resized photos from your website, and instead it displays the original uploaded version from the album.

There are a couple of minor gotchas to be aware of:

1) This doesn't stop Gallery from creating new resizes when you upload new images or an album, but you can delete them afterwards.

2) If you need to add new photos or an album to an existing album, the /resizes directory structure must be in place as it will try to create them in a directory that doesn't exist and generate some strange errors.

For example, if your resizes directory originally was as below:

/resizes

  /2020

    /album1 (contains 300 photos)

    /album2 (contains 200 photos)

  /2019

    /album1 (contains 500 photos)

    /album2 (contains 400 photos)

  and you delete everything under /resizes (this is quickest way to delete everything)  and you will end up with just

/resizes

If you then add album3 via the front end under 2020 this works fine. However, when you try to add images to the album you will get an error (or some strange behaviour with blank thumbnails), and you need to manually re-create the directory tree. i.e.

/resizes

  /2020

    /album3

As a result, I tend to just tidy out my resize images about once per year, and will often leave the empty directory structure in place, as it doesn't really take up any space, and just delete the album contents.

In an ideal world, Gallery would have a Yes/No option to use resizes, so it didn't create them in the first place (I assume the upload would then be much quicker), but I understand this would be considerably more work.

Best Regards

John

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/7794f948-8a3c-ee09-9c50-49a9c2a0562d%40thepostalzone.com.

[Adrian London]

If you’re definitely no longer using the resized images, you can set the resize size to “1”.

Also, maybe some info here will help:
https://www.gfisk.com/gallery3/

[JR]

John,

Many since thanks for providing these details. I'll give it a try. Unfortunately the two gotchas you mention are exactly the issues I ran into when I tried to eliminate the resizes several years back, which discouraged me as it meant than on my active galleries I would have to remember to regularly go in and manually clean out the recently-created images in the resizes folder. But as the size of the folders in my installations has continued to grow, I may have to live with that and simply schedule semi-annual y "resize clean out" sessions. Maybe I'll get ambitious and work out an sql query to the database which will delete every image in the resizes directory tree yet still leave the tree structure intact...

-- J.R.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/CAAoCrWx%2B1HPMXnYPYdDrDNh%3DOiKtrYPuZ-sEYYh1J6kYfktgeg%40mail.gmail.com.

[Adrian London]

Hi JR,

Make the edit John provides and then set the resize size to “1”, which will create 1x1 pixel resizes.  Yes, they don’t take up zero bytes of storage, but close enough.  

Changing the resize size will also trigger all the existing resizes being marked as “dirty” so every one will be recreated (at 1x1) assuming you run the task.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/c17c50c3-74e9-e8e3-62c0-6abb3e379490%40thepostalzone.com.

[Adrian London]

Oh, I didn’t read the rest of your post.

To delete all the resizes, assuming Unix, from the resizes directory (be careful!) run:

find . -type f -exec rm {} \;

On 6 Jan 2021, at 07:53, JR <jrl...@thepostalzone.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/c17c50c3-74e9-e8e3-62c0-6abb3e379490%40thepostalzone.com.

[JR]

Adrian,

Thanks... I'll research that approach and double-check everything (on a test gallery site) before I do anything. The resize to 1x1 approach simply won't work for me on my hosting server -- it has to do with the hosting server limits -- not on disk space as one would think, but with the sheer number of individual files residing in the account which are nearing the allowed limit (they say this limit is necessary because it impacts through put performance on all the other users sharing the same hosting server). So I either have to stop adding new files or clear out all those useless (to me) files in /resizes -- which account for 33% of the total number of files on the server.

But I don't think I can get system level unix command execution privileges (shared hosting servers generally do not allow that for obvious reasons). So it will have to be done with an sql query to call up every image in all the various .var/albums/ .../resizes folders and then deleting the images in them without affecting the folder structure in /resizes. To make matter more complicated, we're talking roughly 800 albums -- each with its own /resizes folder.

-- J.R.

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/5BBEE785-21B5-4D2F-AD35-37F2CA3A23B1%40gmail.com.

[Adrian London]

I don’t have unix/shell access to my files either; I just assumed you did for some reason!

I suppose one not-so-fun method would be to delete the “resizes” directory completely then each time G3 failed, check the errors in the logs and find/fix the code that’s trying to write to that directory. Eventually you would have found all the places and it’ll run :)

I’m not a developer, so this advice could well be rubbish, but using PHP instead of unix commands …
https://stackoverflow.com/questions/4594180/deleting-all-files-from-a-folder-using-php

[JR]

Adrian,

Yep. That idea was part of my attempt a couple of years ago, but I had to give it up in frustration because the calls to /resizes seem to be far more prevalent and logic-connected to far more other things that one would expect. I broke my experimental gallery several times trying to do that. Of course, this is the problem when dealing with most legacy core functionality code written 10 years ago and not well-documented anywhere as far as I know. Basically, the lowest level of core code expects /resizes to be there from the get-go.

I'm pretty such I can make the custom sql query do the job -- but no so sure if I can make it do all 800+ /resizes folders in one go. Having to run it 800+ times would not only be tedious, but a potential slip up in one of those 800 passes could seriously screw things up.

-- J.R.

[JR]

Adrian,

Follow up:  after I went through the link you provided for possible PHP script solutions: While not one of the responses is right for what I want to do (most of them assume you also want to delete the directory folder) it looks like I might be able to combine some of this code into something workable. I'll play around with it. It is also possible to write a PHP script that executes a direct sql query on the database which might allow me to "automate" the process.

-- J.R.

On 01/07/21 4:48 AM, Adrian London wrote: