We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 10713
    • 41 Posts
    This plugin for Revolution relies on phpThumbOf, which must be installed: http://modx.com/extras/package/phpthumbof

    The plugin auto-detects every <img> element and checks if the width/height attributes match the physical size of the image file. If not, it generates a correctly sized version of the image (via phpThumbOf) and fixes the src attributes. Works especially well with TinyMCE’s image insertion.

    This is the very first version, so handle with care.

    http://modx.com/extras/package/autofiximagesize
      • 17883
      • 1,039 Posts
      Wouldn’t it be better to fire the plugin on docFormSave? So the replacement is done once and not on every page load?
        • 10713
        • 41 Posts
        No, I don’t want the source of the text fields changed, because if you clear the cache, all phpthumbof images are deleted, and you would have to save all resources once again. all image src attributes would be broken.

        Also the editor could not easily edit the image size in TinyMCE after saving the resource. the plugin could not make a connection to the original file, once the cached version has been inserted.

        As page output is usually cached, I don’t see a problem for image generating on demand.
          • 17883
          • 1,039 Posts
          No, I don’t want the source of the text fields changed, because if you clear the cache, all phpthumbof images are deleted, and you would have to save all resources once again. all image src attributes would be broken.

          Understood.

          As page output is usually cached, I don’t see a problem for image generating on demand.

          Maybe, but your plugin runs every time and if the output is cached or not, it loops through all images and runs getimagesize() on them. So it could be interesting if your
          $str = $modx->resource->_output;

          gets the cached output. I think so because the parser is through it. So perhaps you could run the process only on images which are not in the phpthumbof cache folder.
            • 10713
            • 41 Posts
            Good point. I will try to reduce the number of regex and getimagesize operations, where there’s no need for it.
              • 18373 ☆ A M B ☆
              • 3,141 Posts
              Saw this retweeted on Twitter.. am glad to have seen this!

              This is actually a great feature for those clients that resize images on the fly, and then start calling you why it takes a minute to load the image - it’s only 1/4th the size after all smiley
                Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                • 10713
                • 41 Posts
                Mhh, my investigations are telling me that the event "OnWebPagePreRender" does not fire at all if there’s a cached version of the resource!
                So there is no performance problem, right?
                  • 17883
                  • 1,039 Posts
                  Well, test it ;-) I don’t know how exactly the cache mechanism of Revo works. Could be that one single uncached snippet call somewhere fires the event (which would be true according to your definition). Since you iterate over the whole output the problem would still remain.
                    • 10713
                    • 41 Posts
                    Weird. Depending on various Revo installations, "OnWebPagePrerender" fires up to 5 times per page load, although the docu says "Called just before the page is pushed to the client. This is the very last event called before the page is sent to the client browser."

                    Most of those events take place after cache is written. Maybe there is some serious magic happening after delivering the output string to the browser...

                    Anyway: After a complete cache clearing, the first plugin call takes 2 seconds. After that all following calls only take 0.03 seconds. I can live with that. I don’t know what the caching system does here exactly, but my plugin seems to work fast enough smiley
                      • 34022 ☆ A M B ☆
                      • 91 Posts
                      You should limit the filename replacement to each individual instance of the filename that needs resizing.

                      The problem: clients use the same image in both the thumbnail and the link to the full-size version of it (such as for a lightbox). Example:
                      <a href="HUGE_IMAGE.jpg"><img src="HUGE_IMAGE.jpg" width="100" height="100" /></a>
                      


                      Currently, your plugin replaces all of the references to each image everywhere it appears on the page, even when it does not need resizing, causing problems with lightboxes showing tiny images. I would also guess that this causes problems when the same image is used many times on one page, each time using a different size.

                      Even with these problems, this plugin is really great for clients that are in too much of a hurry to pre-resize images before uploading. Thank you, it’s very useful!
                        WebsiteZen.com - MODX and E-Commerce web development in the San Francisco Bay Area