Bjoern

I’m not sure how photon works but from what I understand it serves images depending on img width and height attributes. So it doesn’t use the sizes defined in WP. If that is so, you could save webspace by activating dynamic imnage resizing while Images are still being served by photon. If in doubt leave dynamic image resizing disabled.

I’m not sure what you mean by no compress. Do you mean gzip/deflate compression? Or actual image (jpeg) compression?

Pretty permalinks still have to be enabled (this isn’t checked by WPPP yet), but rewrite rules are flushed automatically from version 1.2 on when activating (deactivating) dynamic image resizing.

All the files should be utf-8 encoded now (v1.2). I hope everything works fine. Some files must have slipped me before, because I had that same problem and thought it was fixed…

(btw: versions are now tagged in repository)

Good to hear that. None the less, based on your feedback version 1.2 now does include a php version check on plugin activation.

Yes PHP 5.2 might be the cause of your problem. And you are right, some pretest for requirements would be good. I’ll try to implement that in the next version. Also I’ll check why this results in a blank screen when activating.

Pretty permalinks have to be enabled. You have to flush the permalinks manually once by opening the permalink settings. this should will be fixed in the next version. I hope this fixes your problems.

So if I define an image size as (300, 200, false), and then I upload a 600×500 image, then I want to actually get an image that is 240×200. Not cropped, just scaled to the maximum size on one side that will still fit in the allotted space.

I agree. That’s why the calculation of image sizes in the wp_generate_attachment_metadata override uses the crop flag. So the filename saved in the meta data will be <i>filename_240x200</i> when no cropping is used. I haven’t changed that. When the actual resizing is done on the first request to exactly that (intermediate) Image, only the I do the mentioned calculations to determine if to use cropping or not. I don’t ignore the crop flag. I only not add the “c” Suffix as the information about to crop or not is implicitly contained in the filename. (If the Image size would be defined as (300, 200, true) then the intermediate filename would become <i>filename_300x200</i> image_resize_dimensions without cropping would return 240×200, so cropping would be applied)

You can’t really eliminate it and just proportionally scale all the time, because sometimes you actually do want to crop to a fixed size.

Maybe you misunderstood me or I misunderstand what you mean.

When an image is to be resized (not when the meta data is generated – that will use the cropping parameter and thus will create the correct image dimensions as suffix but I don’t append the “c” to the filename) I call wp_constrain_dimensions with the original image dimensions and the dimensions given in the filename suffix. If the results of that call don’t match the dimensions from the suffix then cropping is used for the dynamic resizing.

image_resize_dimensions in media.php returns the same dimensions wether cropping is true or false if the image can be resized (proportionally) to the desired dimensions. I don’t see in which case that won’t work.

I just published version 1.1 of my plugin WP Performance Pack which includes dynamic image resizing based on Dynamic Image Resizer. It includes some of the above fixes but serving resized images works a bit different: Instead of hooking into the 404 handler I’m using rewrite rules to serve images using SHORTINIT. No more “c” is added to cropped files. Images get cropped, if resizing to the desired size results in different width or height as given in the filename. This way also images with “old” meta data entries which would be missing the “c” get cropped correctly.

@samuel: I can add you to the list of contributors of WPPP if you want.

I can’t reproduce the problem. I installed Global Content Blocks and used the IFrame code from your site. All works as expected with WPPP activated. Maybe the issue is caused by another plugin?

How exactly do you emdbed the iframe? Are you using any plugin for this?

It took me some time figure this out, but I found the reason for this. It’s not really a bug and is caused by WPPP Debugging (when using debug_backtrace inside a uasort callback use DEBUG_BACKTRACE_IGNORE_ARGS). It doesn’t really cause anything bad, so nothing to worry about. None the less the next version will include a fix for this.

You have to activate WPPP debugging in advanced view. This will add a new panel “WP Performance Pack” to the debug bar that shows information about loaded textdomains and cache usage of WPPP.

Caches like bodi0s Easy Cache are page caches, not object Caches, as are most of the caching plugins for WordPress. These caches cache static snapshots pages for not logged in users (same for bodi0s, as it’s stated in the plugin description),which improves Performance for most of your visitors. What they don’t speed up is the back end and pages for logged in users (and the time to create not yet cached pages). Object caches (should) improve performance for all page requests. Best is a combination of both.