Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/10/2023 in all areas

  1. This week we'll take a look at a newly released module that enables you to lock page fields or properties from editing on a page-by-page basis. Originally planned as a core feature, I found it worked just as well built as a focused module, so here it is. This post serves as both an introduction to, as well as documentation for this new module— https://processwire.com/blog/posts/page-edit-lock-fields/
    12 points
  2. 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/
    9 points
  3. @Richard Jedlička & @bernhard, just want to let you know, I did a pull request for fixing issues on non label fields and on fields "not closable". https://github.com/uiii/AdminHelperLinks/pull/6#issue-1988009038
    2 points
  4. Got a support request from @dotnetic today and thought I'd share it with you ? Imagine you have all speakers saved under /speakers with template "speaker", eg /speakers/someone and /speakers/anotherperson Now you want to show/list those persons in the RockPageBuilder block called "Speakers". That's very straightforward ? In Speakers.php you add a helper method: <?php ... class Speakers extends Block { ... public function allSpeakers() { return $this->wire->pages->find("template=person"); } } And in the view file Speakers.view.php: <ul> <?php foreach($block->allSpeakers() as $speaker): ?> <li><?= $speaker->title ?></li> <?php endforeach; ?> </ul> Or when using LATTE in Speakers.latte: <ul> <li n:foreach="$block->allSpeakers() as $speaker"> {$speaker->title} </li> </ul>
    2 points
  5. Generate image placeholders for smoother lazyloading. Currently supports ThumbHash, BlurHash, and average color placeholders. I've been using the wonderful ImageBlurhash module for this in the past, but unfortunately it's no longer in active development. This new module adds ThumbHash and Average Color placeholder algorithms, improves performance by caching generated placeholders, fixes an issue when replacing images, and allows regenerating and clearing placeholders via the admin interface. Try it out using the installation instructions below or check out the GitHub repo for details. Why use image placeholders? Low-Quality Image Placeholders (LQIP) are used to improve the perceived performance of sites by displaying a small, low-quality version of an image while the high-quality version is being loaded. The LQIP technique is often used in combination with progressive lazyloading. How it works This module will automatically generate a small blurry image placeholder for each image that is uploaded to fields configured to use them. In your frontend templates, you can access the image placeholder as a data URI string to display while the high-quality image is loading. See below for markup examples. Placeholder types The module supports generating various types of image placeholders. The recommended type is ThumbHash which encodes most detail and supports transparent images. ThumbHash is a newer image placeholder algorithm with improved color rendering and support for transparency. BlurHash is the original placeholder algorithm, developed at Wolt. It currently has no support for alpha channels and will render transparency in black. Average color calculates the average color of the image. Installation Install the module using composer from the root of your ProcessWire installation. composer require daun/processwire-image-placeholders Open the admin panel of your site and navigate to Modules → Site → ImagePlaceholders to finish installation. Configuration You'll need to configure your image fields to generate image placeholders. Setup → Fields → [images] → Details → Image placeholders There, you can choose the type of placeholder to generate. If you're installing the module on an existing site, you can also choose to batch-generate placeholders for any existing images. Usage Accessing an image's lqip property will return a data URI string of its placeholder. $page->image->lqip; // data:image/png;base64,R0lGODlhEAAQAMQAA Accessing it as a method allows setting a custom width and/or height of the placeholder. $page->image->lqip(300, 200); // 300x200px Markup Using a lazyloading library like lazysizes or vanilla-lazyload, you can show a placeholder image by using its data URI as src of the image. <!-- Using the placeholder as src while lazyloading the image --> <img src="<?= $page->image->lqip ?>" data-src="<?= $page->image->url ?>" data-lazyload /> Another technique is rendering the placeholder and the original image as separate images on top of each other. This allows smoother animations between the blurry unloaded and the final loaded state. <!-- Display placeholder and image on top of each other --> <div class="ratio-box"> <img src="<?= $page->image->lqip ?>" aria-hidden="true"> <img data-src="<?= $page->image->url ?>" data-lazyload> </div>
    1 point
  6. I'm already using processwire / php but still with a configuration from my last desktop. I wanted to create a simple processwire MAMP PRO localhost project in my sites folder. My php version is compatible, I have apache and SQL. I've tried both methods, Ryan and zip, but nothing works.
    1 point
  7. Yes, that's right. The replacement happens only for defaults.json, any additional settings from JSON text or file are merged afterwards.
    1 point
  8. This is brilliant @Robin S - very clever solution ?? Should be merged into the core imho once it is more tested!
    1 point
  9. Yeah the same technique applies to custom page classes as well. Just add methods there with a talking name and your code will get a lot cleaner and better. Think for example of a situation where you are using $pages->find("template=something") in your template files in several spots and you realise that you forgot to change the sort order to random. When using $pages->find() in your template files you need to find all instances and change the code there. When using $page->findRandomSomething() you simply change the logic in your custom page classes method and everywhere it will be changed immediately. Check out my videos on youtube for that topic: 1) https://www.youtube.com/watch?v=7CoIj--u4ps&t=2124s 2) https://www.youtube.com/watch?v=D651-w95M0A
    1 point
  10. I'm not sure but is that a mistake in the readme? The image, width, height and options all equal to $event->arguments(0) in the hook example.
    1 point
  11. Thanks a million, I know it will be a staple for me from now on.
    1 point
  12. @Robin S, thank you very much, that is such a nice gesture of you. I'll try this right away. ?
    1 point
  13. Okay I have to try it out but this is absolutely fantastic and something I wanted to tackle myself for a while now, working on websites with a lot of images. Thanks for sharing this!
    1 point
  14. I also experienced this issue. Following on netcarver's advice above, it turns out that my device clock is ahead by over 5 minutes. I adjusted my device time & it worked but thought a broader solution might be better. This fixed my issue. var startTime = parseInt($('#login_start').val()); // GMT/UTC // var maxSeconds = 300; // max age for login form before refreshing it (300=5min) var clientStartTime = Math.floor(new Date().getTime() / 1000); var clockDifference = clientStartTime - startTime; var maxSeconds = 300 + clockDifference; But I prefer it be done in the core, so I opened an issue in github.
    1 point
  15. Hi @bernhard, thanks for this! it should be fixed now...
    1 point
  16. Could you tell a little bit more? Any Errors? At which step are you stuck?
    1 point
  17. Try pushing the max_input_vars value in the server.
    1 point
×
×
  • Create New...