We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 10713
    • 41 Posts
    Oh yes, the replacement process should not be applied to the whole page... I’ll prepare an update soon!
      • 10713
      • 41 Posts
      Fixed in beta1. Will show up in the repository soon smiley
        • 34022 ☆ A M B ☆
        • 91 Posts
        Wow, that was fast! Thank you, my clients and I definitely appreciate this addon.
          WebsiteZen.com - MODX and E-Commerce web development in the San Francisco Bay Area
          • 34022 ☆ A M B ☆
          • 91 Posts
          By the way, maybe this has to do with a system setting specific to my installation or something, but I always have to change the following line to get it to work:

            // added .'/'
            $dimensions = getimagesize($_SERVER["DOCUMENT_ROOT"].'/'.$filename,$info);
          


          Maybe this is supposed to be the base_url? I am using 2.1 RC-4.
            WebsiteZen.com - MODX and E-Commerce web development in the San Francisco Bay Area
            • 10713
            • 41 Posts
            Quote from: Oleg at May 19, 2011, 08:40 PM

            // added .’/’

            Please try it with this line:

            $config = $modx->getConfig();
            $dimensions = getimagesize($config['base_path'].$filename, $info);
            
              • 16337
              • 44 Posts
              I have a another problem - the plugin seems to go through all the images in the page including the ones in the template. That is not a desirable behaviour in my opinion.

              And when it complains about being unable to find the image (without basepath fix) I can see it pulling in images from templates that are assigned to completely different resources too..

              any idea?
                • 10713
                • 41 Posts
                New version (beta3) with fixed "base_path" behaviour and improved RegEx is on its way!

                Regarding the scope: Yes, the plugin is meant to search and replace within the whole HTML page. In 99,5 % of cases, it will not find any matches outside the TinyMCE-generated "article" section, but it’s conceptionally more useful to fire the plugin after the page is completely generated and run it on the whole page.
                  • 16337
                  • 44 Posts
                  Quote from: gerritvanaaken at May 20, 2011, 03:37 AM

                  New version (beta3) with fixed "base_path" behaviour and improved RegEx is on its way!

                  Regarding the scope: Yes, the plugin is meant to search and replace within the whole HTML page. In 99,5 % of cases, it will not find any matches outside the TinyMCE-generated "article" section, but it’s conceptionally more useful to fire the plugin after the page is completely generated and run it on the whole page.


                  perhaps, conceptually the best place to fire the plugin would be after resource save? there is a technical problem though - once you change the resource content field from regular img link into phpthumb wrapped one you would loose editing in tinymce.

                  how does it work with caching btw?
                    • 10713
                    • 41 Posts
                    Quote from: krisj at May 20, 2011, 05:22 AM

                    perhaps, conceptually the best place to fire the plugin would be after resource save? there is a technical problem though - once you change the resource content field from regular img link into phpthumb wrapped one you would loose editing in tinymce.

                    That’s it. If you "burn" the AutoFix into the content field at the saving process, you immediately loose the connection to the original image files!

                    Quote from: krisj at May 20, 2011, 05:22 AM

                    how does it work with caching btw?

                    After cache is generated, the plugin does not use significant server cpu, see comment #9 above!
                      • 16337
                      • 44 Posts
                      Quote from: krisj at May 20, 2011, 05:22 AM

                      perhaps, conceptually the best place to fire the plugin would be after resource save? there is a technical problem though - once you change the resource content field from regular img link into phpthumb wrapped one you would loose editing in tinymce.

                      That’s it. If you "burn" the AutoFix into the content field at the saving process, you immediately loose the connection to the original image files!

                      it would be great to be able to get this in there somehow before caching... i know its probably not very straight forward...

                      Quote from: krisj at May 20, 2011, 05:22 AM

                      how does it work with caching btw?

                      After cache is generated, the plugin does not use significant server cpu, see comment #9 above!

                      it would have impact under high traffic though. would have to do a stress test obviously its a work in progress. and good work by the way!