Leaderboard

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.

I'm thrilled to announce the official release of RockPageBuilder, the game-changing tool that's set to transform your web development journey (at least ChatGPT says so ??)! With its brand new drag-and-drop interface RockPageBuilder is your secret weapon for creating outstanding ProcessWire-based websites. Get a taste of the future of web development by visiting the demo page at https://pagebuilder.baumrock.com/ and exploring the RockPageBuilder documentation at https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/ Don't miss out on this exciting opportunity to elevate your web development game. Get ready to rock with RockPageBuilder! ??️ Early Bird Sales until 30.11. https://www.baumrock.com/processwire/module/rockpagebuilder/ Here is a quick demo video: And here is how to install it from scratch in under 5 minutes: Some showcase projects are already in the pipeline ? So be sure to subscribe to https://processwire.rocks/ or to https://www.baumrock.com/rock-monthly/ Have a great weekend!

Good solution!

Yes I see this Apple thing, but it can't show if it's hidden. ^^

OK that's because cache is cleared just before the sorted hook callback, but instance given in callback is the "old" one, yes that makes sense when you look at implementation. ^^ Nothing is wrong, that's a long story. Method with children loop is also called by several hooks, including a saveReady, so at first I didn't need to save current page in loop because PW was gonna save it at end. So when I added sorted hook, I saw that I had to save() the page myself so did it in the hook because other method was not doing it, and that didn't worked. Finally I refactored this method to take in parameter if it's needed to save current page.

As far as I can see and understand in the PW core code, there is no problem with consistency since the $page does contain the most recent version of the data. The issue really is that in the hooks save (after only) and sorted, the cache has been invalidated due to previous database writes, and thus, subsequent queries will generate new instances. This all makes sense. I believe this is to be expected. In your code, you are updating the title on the "new" instance which is factually another object and then trying to save the "old" page instance. This doesn't work of course. What is wrong with your commented-out line instead of $page->save() outside the loop?

That's possibly a browser cache issue, because the variation filename doesn't change when the quality option changes. This problem is the motivation behind this module: https://processwire.com/modules/unique-image-variations/

Sorry to catch up this older topic again, but there seems to be no changes in sight so far. I also still would find it useful to have webp as input format. The need- or the wish- to use it, is from my experience originated in Google requesting (or recommending) webp format in order to reduce loading times when doing speed tests with lighthouse. So people start to use and store images in webp format. Then to convert them back to jpg or png just to output these as webp again makes no sense at all.

Welcome to our lovely community, Rasso. I hope you are enjoying the benefits of ProcessWire as much as I do. We had the discussion about replicating / syncing fields on the server many times. I use RockMigrations as a reliable and working module for this. You write code with migrations and they get executed as soon as you save the file and refresh the admin. A migration can be inside the site/migrate.php file, or in a migrate method inside of your custom module, or somewhere else. Here is a possible example of a migration: $rm->migrate([ 'fields' => [ 'body' => [ 'label' => 'Content', 'type' => 'FieldtypeTextareaLanguage', 'inputfieldClass' => 'InputfieldTinyMCE', 'tags' => 'generic', 'contentType' => 1, 'langBlankInherit' => 1, 'inlineMode' => 0, 'height' => 500, 'lazyMode' => 1, 'features' => [ 0 => 'toolbar', 1 => 'menubar', 2 => 'stickybars', 3 => 'spellcheck', 4 => 'purifier', 7 => 'pasteFilter', ], 'toolbar' => 'styles bold italic pwlink pwimage blockquote hr bullist numlist anchor code', 'rows' => 15, ], 'home_intro' => [ 'label' => 'Home Intro', 'type' => 'textarealanguage', 'tags' => 'generic', 'inputfieldClass' => 'InputfieldTinyMCE', 'rows' => 5, 'inlineMode' => 1, ], 'subheadline' => [ 'type' => 'text', 'inputfieldClass' => 'InputfieldTextLanguage', 'maxlength' => 100, 'tags' => 'generic', ], ], 'templates' => [ 'basic-page' => [ 'label' => 'Standardseite', 'fields' => [ 'title', 'navtitle', 'seo', ], ], 'imprint' => [ 'label' => 'Impressum', 'fields' => [ 'title', 'body', 'seo', ], ], ] ]); With the migration you can also create pages and even fill them with content (if you want that) $rm->createPage(title: 'About us', name: 'about-us', template: 'basic-page', parent: '/'); There is no sync between fields or templates you create in the admin and RockMigrations (there was a YAML option once, but I don't know if it still exists), but you get an easy to copy code in each fields edit section, that you can copy directly over to your migration. I am also in favor that migrations should be a core feature of ProcessWire, but Ryan does not approve. So we have to stick with what we have, and RockMigrations is a great solution.

As far as I know this is a default behaviour on Macs and/or iOS devices. Maybe this plugin can help? https://github.com/lazd/iNoBounce

Hey @bernhard, I think I've found the problem. It's relating to the fact that the view file extension can be either .latte or .view.php (I'm using the .view.php version). The logic for finding the php file edit link is stripping the view file extension and then adding back ".php". This works if it's a .latte view file, but not for .view.php files. In this case, it simply strips off the last part (.php) and adds it back, so we still have the .view.php in the full path. I added this line to ___getIcons() which fixes the problem, though there might be a more elegant solution: $ext = pathinfo($opt->path, PATHINFO_EXTENSION); // php file edit link; view file can be .latte or .view.php $php = substr($opt->path, 0, strlen($ext) * -1 - 1) . ".php"; $php = str_ireplace("view.php", "php", $php); // <============== if it's a .view.php file if (is_file($php)) { .... Regards, Ian.

Hey @bernhard, Thanks so much for this mini tutorial, when I get time I'll attempt to test it out and see how I go. ?

Hey everyone, A short and easy question about this forum. I posted some questions before and always got a helpful answer. I keep receiving saying I would gladly do that, if I knew where this button is ?. Is the "thanks" trophy? Thanks.

I've never done that myself but you could also do a get request to that page automatically on save: <?php $wire->addHookAfter("Pages::saved(template=yourtemplate)", function($event) { $page = $event->arguments(0); (new WireHttp())->get($page->httpUrl); }); This might slow down saving the page for the client, but it would create all image variations for website visitors and you'd not need to define all the image variations in the hook or keep your template and the hook in sync... Happy to hear how that worked!