Search the Community

Delayed Image Variations Delays the creation of image variations until their individual URLs are loaded. Image variations being generated one-by-one: Background Normally when you create new image variations in a template file using any of the ProcessWire image resizing methods, all the new variations that are needed on a page will be created from the original Pageimage the next time the page is loaded in a browser. If there are a lot of images on the page then this could take a while, and in some cases the page rendering might exceed your max_execution_time setting for PHP. So you might like to have image variations be generated individually when they are requested rather than all at once. That way the page will render more quickly and the risk of a timeout is all but eliminated. But there can be problems with some implementations of this approach, such as with the (in)famous TimThumb script: It's not ideal to have PHP be involved in serving every image as this is needlessly inefficient compared to serving static assets. It's not good to allow arbitrary image sizes to be generated by varying URL parameters because you might want to restrict the maximum resolution an image is available at (e.g. for copyrighted images). If images are generated from URL parameters a malicious user could potentially generate thousands of images of slightly different dimensions and fill up all your disk space. The Delayed Image Variations module avoids these problems - it creates variations when their URLs are loaded but only allows the specific dimensions you have defined in your code. It does this by saving the settings (width, height and ImageSizer options) of every new Pageimage::size() call to a queue. The module intercepts 404s and if the request is to an image variation that doesn't exist yet but is in the queue it generates the variation and returns the image data. This only happens the first time the image is requested - after that the image exists on disk and gets loaded statically without PHP. Usage In most cases usage is as simple as installing the module, and you don't need to change anything in your existing code. However, there might be some cases where you don't want the creation of a particular image variation to be delayed. For example, if you created a variation in your code and then immediately afterwards you wanted to get information about the variation such as dimensions or filesize. $resized = $page->image->width(600); echo $resized->height; echo $resized->filesize; This wouldn't work because the actual creation of the resized image hasn't happened yet and so that information won't be available. So in these cases you can set a noDelay option to true in your ImageSizer options and Delayed Image Variations will skip over that particular resizing operation. $resized = $page->image->width(600, ['noDelay' => true]); echo $resized->height; echo $resized->filesize; For advanced cases there is also a hookable method that you can return false for if you don't want a delayed variation for any particular resizing operation. Example: $wire->addHookAfter('DelayedImageVariations::allowDelayedVariation', function(HookEvent $event) { /** @var Pageimage $pageimage */ $pageimage = $event->arguments(0); // The Pageimage to be resized $width = $event->arguments(1); // The width supplied to Pageimage::size() $height = $event->arguments(2); // The height supplied to Pageimage::size() $options = $event->arguments(3); // The options supplied to Pageimage::size() // Don't delay variations if the Pageimage belongs to a page with the product template if($pageimage->page->template == 'product') $event->return = false; }); 404 handling For Delayed Image Variations to work your .htaccess file needs to be configured so that ProcessWire handles 404s. This is the default configuration so for most sites no change will be needed. # ----------------------------------------------------------------------------------------------- # 2. ErrorDocument settings: Have ProcessWire handle 404s # # For options and optimizations (O) see: # https://processwire.com/blog/posts/optimizing-404s-in-processwire/ # ----------------------------------------------------------------------------------------------- ErrorDocument 404 /index.php ProCache If you are using ProCache then make sure it is not configured to cache the 404 page or else PHP will not execute on 404s and queued image variations will not be generated. Generate queued variations Before launching a new website you might want to pre-generate all needed image variations, so no visitor will have to experience a delay while a variation is generated. To queue up the image variations needed for your site you will need to visit each page of the website one way or another. You could do this manually for a small site but for larger sites you'll probably want to use a site crawler tool such as Xenu's Link Sleuth. This may generate some image variations but it's likely that some other variations (e.g. within srcset attributes) will not be requested and so will remain queued. To generate all currently queued variations there is a button in the module config: This will search the /site/assets/files/ directory for queue files and render the variations. https://github.com/Toutouwai/DelayedImageVariations https://processwire.com/modules/delayed-image-variations/

Hi, what I'm doing is this: <picture> <source srcset="<?php echo $page->section_three->main_img->first()->size(396,710)->webp->url; ?>" type="image/webp"> <img class="p_absoulte pp_block" src="<?php echo $page->section_three->main_img->first()->size(396,710)->url; ?>" alt=""> </picture> and for some reason it sometimes becomes this: <picture> <source srcset="/site/assets/files/1057/sektion3_bild-1.396x710.png" type="image/webp"> <img class="p_absoulte pp_block" src="/site/assets/files/1057/sektion3_bild-1.396x710.png" alt=""> </picture> It seems to be related to ->size(). When I don't use ->size() the webp Url is correct. I'm using the image-field inside a Fieldset(Page). Could that be a problem too? I just increased the output size by 2px and voila the webp url comes up. I deleted all variations (webp variation is present in correct size) changed it back to the original size and again: a png url. I also tried to rename the image and load it up agian. ...same behavoir. Thanks in advance guys

Hey Ryan, hey friends, we, Mobile Trooper a digital agency based in Germany, use ProcessWire for an Enterprise-grade Intranet publishing portal which is under heavy development for over 3 years now. Over the years not only the user base grew but also the platform in general. We introduced lots and lots of features thanks to ProcessWire's absurd flexibility. We came along many CMS (or CMFs for that matter) that don't even come close to ProcessWire. Closest we came across was Locomotive (Rails-based) and Pimcore (PHP based). So this is not your typical ProcessWire installation in terms of size. Currently we count: 140 Templates (Some have 1 page, some have >6000 pages) 313 Fields ~ 15k Users (For an intranet portal? That's heavy.) ~ 195 431 Pages (At least that's the current AUTOINCREMENT) I think we came to a point where ProcessWire isn't as scalable anymore as it used to be. Our latest research measured over 20 seconds of load time (the time PHP spent scambling the HTML together). That's unacceptable unfortunately. We've implemented common performance strategies like: We're running on fat machines (DB server has 32 gigs RAM, Prod Web server has 32gigs as well. Both are running on quadcores (xeons) hosted by Azure. We have load balancing in place, but still, a single server needs up to 20 sec to respond to a single request averaging at around about 12 sec. In our research we came across pages that sent over 1000 SQL queries with lots of JOINs. This is obviously needed because of PWs architecture (a field a table) but does this slow mySQL down much? For the start page we need to get somewhere around 60-80 pages, each page needs to be queried for ~12 fields to be displayed correctly, is this too much? There are many different fields involved like multiple Page-fields which hold tags, categories etc. We installed Profiler Pro but it does not seem to show us the real bottleneck, it just says that everything is kinda slow and sums up to the grand total we mentioned above. ProCache does not help us because every user is seeing something different, so we can cache some fragments but they usually measure at around 10ms. We can't spend time optimising if we can't expect an affordable benefit. Therefore we opted against ProCache and used our own module which generates these cache fragments lazily. That speeds up the whole page rendering to ~7 sec, this is acceptable compared to 20sec but still ridiculously long. Our page consists of mainly dynamic parts changing every 2-5 minutes. It's different across multiple users based on their location, language and other preferences. We also have about 120 people working on the processwire backend the whole day concurrently. What do you guys think? Here are my questions, hopefully we can collect these in a wiki or something because I'm sure more and more people will hit that break sooner than they hoped they would: - Should we opt for optimising the database? Since >2k per request is a lot even for a mysql server, webserver cpu is basically idling at that time. - Do you think at this point it makes sense to use ProcessWire as a simple REST API? - In your experience, what fieldtypes are expensive? Page? RepeaterMatrix? - Ryan, what do you consider as the primary bottleneck of processwire? - Is the amount of fields too much? Would it be better if we would try to reuse fields as much as possible? - Is there an option to hook onto ProcessWires SQL builder? So we can write custom SQL for some selectors? Thanks and lots of wishes, Pascal from Mobile Trooper

Hello! I use PW 3.0.98 and I have frontend editing enabled for a PageTable Field. Somehow, when I double click the field in the frontend, the iframe in wich the content is displayed is very small (see screenshot). I couldn't find out if thats some CSS conflict or another problem. Any suggestions? Thanks, Andrej

Running PW 2.7.2 I've built several sites using PW. One question that I have is is there a module, or planned upgrade in the core to refuse (fix) uploaded images that don't meet the Min width or Min height? In the description PW says "Optionally enter the minimum width and/or height .. images that don't meet these minimums will be refused." (the field /image upload is required) example: Currently, if I set Max width to 320, Max height to 260 and leave "refuse images exceeding max dimensions?" unchecked. This is fine, if they upload a 1024x768, I'll let PW scale/crop it down to 320x260. In the next section I set Min width/height for uploaded images to 320x260. however, when a user uploads a 800x200 image, for example, PW won't refuse it. PW will just scale the image to 320x200 (for example)...when the minimum is set to 320x260. Something, with the settings enabled above, just seems to be off. Maybe PW (in the PHP core) is not checking the dimensions of the dimensions after the user uploads it and PW scales/crops it?

Hey, I was wondering if there is an alternative to the default Processwire ImageSizer. Although it comes in really, really handy (I have actually never used any Content Management Framework that comes with a default Resize module) I am not quite content when it comes to resizing large images. Check this image: http://imgur.com/KNS9VWB You can clearly see a difference in sharpness of both images, after resizing the image comes out a bit blurry (Yes, quality is on 100). Has anybody else encountered this? If so, is there any good alternative (in form of a Module). Much love to anyone that's willing to help <3

Hello, for a module that's used in the admin, I need the ->size(x, y) functionality for creating thumbnails of existing images. I tried it but I got following exception: ProcessWire: ProcessPageList: Method Pagefile::first does not exist or is not callable in this context I hope someone can help me with that! Thanks!

I'm doing some updates on a site that only just launched last week and during development everything was fine. But now I've exported the db from the production site, imported it back into my local and get Call to a member function size() on a non-object. My template looks like: foreach($products as $product) : $img_src = $product->images->first(); echo $img_src; // this works echo $img_src->url; // so does this echo $img_src->size(300,300)->url; // this gives me the error endforeach; What would be causing this to error now when it was working fine before and I can get values for the image and its source, just not the resized version?

I have an image 500x300 I need to apply the resizing to 150x150 without cutting edge. Thus in any case, I need to have the image canvas size 150x150 When you use $ image->size (150, 150), we obtain the desired result (cropping). When using $ image->size (150, 150, array ('cropping' => false)) our image circumcised according to the greatest height, canvas change proportionally. / / 150x90. Need an image 150x90 position in the center of the canvas 150x150. You can do this using the API?

Hi all, I'm fairly new to Processwire. As far as I can see, it's a great tool to get my work done! There's just one question right now: Is there a way to define a fixed width and/or height for an image in the backend? I'm aware of the "maximum width/height" options, but I need a fixed width in my case. Images larger than the defined width should automatically downsize, images smaller should be rejected with an error. Regards, Thomas

I'm having a real issue here guys, my site's just gone live and the client has been adding some photos to the galleries. All looked great until I got further down and some of the images had not been resized (so were showing 3900px x 3000px or something similarly terrifying). All the images are just in a foreach loop and the vast majority of the images are getting correctly resized but once one is not resized, all subsequent ones follow suit and are also not resized. I can upload code, but has anyone else seen or heard of a similar issue? Sorry for the desperation but it's sort of making the website look insane