d'Hinnisdaël

@videokid Sounds like the composer dependencies haven‘t been installed. Have you installed the module using composer? Merely installing via the admin UI won‘t work as it‘ll be missing the dependencies.

Appreciate the detailed explanation @bernhard and @gebeer, I was unaware of some of the finer points. Looking forward to trying the module again in the future. A brief philosophical note among the technical discussion (the thread seems to have gone off track a bit ?) — RockMigrations is a great tool and people seem to be enjoying it. And not everybody has to agree with its way of doing things. We were merely expressing our views on what a good solution looks like. Choosing to use a particular tool is about preference and previous experience. It's about finding what works best for each of us, and that might change over time, or it might not. Neither is directed against you or a critique of your work. I have no doubt that the features I referred to as "a few things too many" are valuable in your workflow. That's the beauty about creating your own modules – you're free to tailor them to your needs and include whatever saves you time. My personal opinion is that these features shouldn't be part a migrations feature. You seem to disagree, and that's fine.

@ShadowByte You can add a sort order to your selector: template=news, limit=10, sort=-date

I can't quite see how WEBP images are different from JPEGs or GIFs in this regard, and why they shouldn't be allowed as source images. All these formats are lossy and have the potential to look fantastically terrible when set to high compression rates, so there's really no ideal input format apart from TIFFs and lossless PNGs. The browser and OS support of WEBPs is such that we should allow them as source format if the server is configured to resize them. From what I've seen, most GD and Imagick installations these days handle WEBP just fine. With websites now outputting WEBP files, a growing number of PW users will expect to keep working with them as they've always been working with other common formats.

@MarkE Sounds interesting! Keep us posted about new releases and let us know if you need beta testers.

Welcome @Rasso! While ProcessWire doesn't have built-in support for migrations or version-controlled field definitions, it already supports export and import of field definitions via JSON, albeit only manually via the admin interface. However, it being JSON-based should be a good enough base to start automating some of this, e.g. by saving and reading the JSON from disk. That would also make them version-controlled as well. I agree this should be part of the core. Most CMS have solutions for this and it'd be a useful feature to advertise. The landscape of modules here is somewhat splintered. The module that integrates best with the core, Migrations, has unfortunately been deprecated. I haven't fully tested RockMigrations yet, but from what I've seen it seems to be doing a few things too many (snippets, "magic pages", "files on demand") and I'd prefer a module that limits itself to migrations, if not just for performance. +1 for a ProMigrations module from @ryan to ensure the best level of integration into the core.

In the meantime, I've found a fix that kind of works: rename the repo to ImagePlaceholders, register the module in the registry, the rename it back to processwire-image-placeholders. Since GitHub will indefinitely redirect any requests to the new name, this should be somewhat future-proof, but very hacky and not my preferred solution here ?

@ryan Thanks! Could we convert kebab case to pascal case in general? That way we'd cover all use cases. I've tested the following snippet below and it's working great. Currently conforming names will be left untouched: PageEditLockFields, ProcessWireUpgrade, etc. Any kebab case names are converted to valid module names: processwire-template-engine-latte → TemplateEngineLatte. function guessModuleNameFromRepo($repo) { $module = str_starts_with($repo, 'processwire-') ? substr($repo, 12) : $repo; $module = str_replace('-', '', ucwords($module, '-')); return $module; }

@maetmar You don't need to call or render anything. That's basically what TemplateEngineFactory does for you behind the scenes. For every template.php, it will look for a corresponding view file, e.g. template.latte or template.twig. Looking at the module again, for that to happen, you need the mentioned option enabled: Enable automatic page rendering. Why this would interfer with your prepended _init.php, I don't know and is something to debug.

@maetmar It's probably best to ask this in the dedicated forum topic for the TemplateEngineFactory module. The Latte engine has no influence on this behavior, it merely renders the output. For what it's worth, I have that option enabled and my _init.php is being called normally, so it might be something else.

@ryan Thanks a lot! That's useful to know. Is this something that could be reconsidered or changed in the module directory? I've recently started prefixing module names with processwire- on GitHub for better context and discoverability and have found that to be a great way of organi`ing projects. This makes it a lot easier to e.g. enter "processwire" into the repo search input and filter down a list to only PW modules. @bernhard Sweet — I'll definitely need to try that as well! It's super easy to forget simple steps like version bumps when creating releases. Better to automate this.

I've upgraded the module to work with Latte v3. Note that this is a potential breaking change if you're defining custom macros and might require code changes on your end. Learn more about the migration to Latte 3 and upgrading macros to tags. To upgrade: composer require daun/template-engine-latte:^2.0

I'm having trouble submitting new modules to the directory, as well as updating versions of existing modules. What's the best way to debug this? Is there some person I could ping from the core team to help me look at this? Has anyone had similar problems? Here's the concrete issues I'm facing: When trying to add the ImagePlaceholders module from this GitHub repo, it errors out with the message: "Unable to load module info from GitHub. Please make sure there is a getModuleInfo() function, a ModuleName.info.php file, or a ModuleName.info.json file". However, the module does have a .info.php file and is working fine locally and when installed via composer. Trying to add the DatetimeCarbonFormat module from this GitHub repo results in the same error. This one also works fine when installed and has a getModuleInfo method defined. An existing module, TemplateEngineLatte, seems to not get updated, even after successful refreshes. The version is stuck at 1.0.0, even though the GitHub repo has a recent 1.0.6 tag.

Great to see people adopting Latte ? One potential issue with your example is that you're creating a new Latte instance for every single Page class instance that is created. And page class instances are created whenever they're pulled from the database. Meaning, when you're looping over a set of 100 pages, you're creating 100 Page instances and 100 Latte instances with it. That's rather costly for performance. The advantage when using existing modules like TemplateEngineFactory or RockFrontend is that they take care to only instantiate a single instance of whatever renderer they use for generating template views.

Amazing, thanks for creating this! I agree this should be part of the core once it's been in use for a while.

@TomPich I can‘t look into this as I‘m travelling at the moment. If you create an issue with reproducible examples on the GitHub repo, I‘m happy to take a closer look in the next weeks.

Native AVIF support would be great for creating performant sites. When WEBP support was added to the core, it was done as a one-off addition. AVIF could be added in the same way by accessing an $image->avif property on the image object. However — I think @BrendonKoz touched on this above — adding more alternative output formats will probably require some rethinking to keep this part of the core modular. We'll definitely see more image formats being developed in the future, and it'd be great to access them from a single property or as a single parameter with formats and fallbacks, e.g. $image->url(300, ['format' => 'webp,png']).

As far as I can tell, this is a current limitation of the core. The default language cannot be deactivated and serves as fallback for non-translated versions.

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>

@markus_blue_tomato I'm also thinking of adding support for alternative hashing methods, specifically ThumbHash. The colors with ThumbHash seem to be a bit closer to the original and it also supports alpha channels. Would you be willing to accept a PR for that? I'd love to avoid creating a separate module, as the core logic would just be duplicated. Adding a new setting is much more elegant and allows experimenting with both hashing methods more easily. If it helps and it's possible, I'd be willing to take over maintenance of the module and take it from there.

Hi @markus_blue_tomato I've finally come around to investigating the issue where newly uploaded images would keep the old blurhash. I have a working backward-compatible fix ready in a fork, but I see that the module itself has been marked as readonly for a while and I can't create any PRs against it. Would you accept this fix via some other means?

Thanks for reporting the issue; I've pushed a fix as 1.0.6. Updating the composer package should fix it: composer update daun/template-engine-latte

@maetmar When rendering templates using Latte, I've found the built-in field rendering a bit cumbersome to set up since you'll need an intermediary PHP file to render the Latte view from. The straight-forward version would be using a loop and including a file based on the matrix type. This will look for a view partial at site/templates/views/partials/blocks/image.latte, when rendering a matrix page of the type "image" in a matrix field named "blocks": {foreach $page->blocks as $block} <div class="block" data-block="{$block->type}"> {include 'partials.blocks.' . $block->type, block => $block} </div> {/foreach}

@artfulrobot Great catch. Could you repost this in the support thread of the main TemplateEngineFactory module? I have no control over either that module or its repository; I merely created an integration for it adding support for the Latte language.

Add support for the Latte templating language to the Template Engine Factory. Available on the module directory and on GitHub. The latest version uses Latte v3. Configuration The module offers the usual the following configuration: Template files suffix The suffix of the Latte template files, defaults to latte. Default layout file Layout that all views will extend from unless overwritten. Provide ProcessWire API variables in Latte templates API variables ($pages, $input, $config...) are accessible in Latte, e.g. {$config} for the config API variable. Simplified path resolution Enable Blade-style dot syntax for directory traversal, e.g. partials.navigation instead of ../../partials/navigation.latte Auto refresh templates (recompile) Recompile templates whenever the source code changes.