We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 40833
    • 52 Posts
    I apologize in advance if this topic has been broached somewhere else, but I can't find any documentation or forum posts that cover this.

    The scenario: I've created a mega-menu that uses phpthumbof re-sized images taken directly from TVs where the image is attached to each page as a "cover photo". The menu only shows 2nd level pages (so between 3-7 menu items per section, 6 sections). Take into account this is a medium sized site with between 100-150 pages, including articles (so it will continue to grow).

    The problem: With the config setting "phpthumbof.postfix_property_hash" set to "on" to prevent naming collisions, every single page produces a unique cached version of all the images in the mega-menu. That starts adding up exponentially.

    The semi-solution: Turning off the postfix_property_hash has the desired effect of only using one cached image for every mega-menu thumb on every page. *Someone please correct me if I'm wrongly assuming this is what happens.

    The downside to this is, I can never use phpthumbof manipulated photos from these TVs anywhere in the site (or indeed, any image that has the same name as one of these images).

    The needed solution: So I don't know if this is possible or if this is something I need to do a feature-request for, but if I could just provide a custom postfix_property_hash in my call of the phpthumbof snippet, that would add SO much power to it. Example:
    [[!phpthumbof? &input=`[[+imgurl]]` &options=`&w=180&h=100&f=jpg` &postfix_hash=`mega-menu`]]


    Thanks in advance for any thoughts, suggestions, etc.!

    * For instance, does it pull the image from cache on each page like I think, or does it actually recreate each image every time a page is loaded (even though the menu itself is cached, every page has a slightly different version of the menu cached). [ed. note: dan971 last edited this post 12 years, 9 months ago.]
      • 35150 ☆ A M B ☆
      • 191 Posts
      Quote from: dan971 at Dec 26, 2013, 12:15 PM

      The problem: With the config setting "phpthumbof.postfix_property_hash" set to "on" to prevent naming collisions, every single page produces a unique cached version of all the images in the mega-menu. That starts adding up exponentially.

      Yes, you're quite right, especially when you're calling it uncached like that (which likely you shouldn't be). You might have a look at my extra pThumb which fixes exactly this problem as well as several others.
        Extras :: pThumb • Resizer • imageSlim • setPlaceholders
        • 40833
        • 52 Posts
        Quote from: jgrant at Dec 27, 2013, 05:52 PM
        especially when you're calling it uncached like that (which likely you shouldn't be).

        Nope, I call everything cached unless it's something that could change dynamically every time the page is loaded (following Mark Hamstra's guidelines ). But since (I assume) a Wayfinder menu creates a cached version of the menu for every section, then it created a new thumbnail for each processed image. (P.S. If anyone could explain how Wayfinder caches menus to me a little better, I would be eternally grateful.)

        Anyway, thank you, I will definitely take a look at your pThumb addon and respond at a later date to let you know how it worked.

          • 28042 ☆ A M B ☆
          • 24,524 Posts
          As far as I am aware, Wayfinder itself doesn't cache anything. The entire page is cached with the menu.
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
            • 35150 ☆ A M B ☆
            • 191 Posts
            A simple way to see how something's cached is just to look at the cache file for a resource, in core/cache/resource/web/resources/.
            I believe you'll find all your calls to phphthumbof intact, since the ! before the snippet name ( [[!phpthumbof... ) prevents its output from being stored in the cache, meaning every time somebody hits the page all those snippet calls will be run. Now, since phpThumbOf has run before, the thumbnails already will be stored in its cache (assets/components/phpthumbof/cache/) and won't have to be recreated, but phpThumbOf is very inefficient in determining this and requires a fair amount of effort just to figure out that it already has a thumbnail cached. The more images in its cache, the longer it takes. A few thousand cached thumbnails combined with several phpthumbof calls on a page quickly becomes a performance drag and starts adding multiple seconds to page load times. Mix in anything more than a minimal amount of traffic to the site and this is a recipe for a very overburdened server.

            The main reason why phpThumbOf gets slower as the number of cached thumbnails increases is that every time it's run it attempts to clean its cache, generating a list of all thumbnails along with file sizes and modification times, then going through the list determining which if any should be deleted. In an ironic twist, it won't actually ever delete anything, though it'll sure waste plenty of time trying to.
              Extras :: pThumb • Resizer • imageSlim • setPlaceholders