Leaderboard

This week on the dev branch are some fixes and improvements, but we'll likely wait another week before bumping the version number up. Some new hooks have been added to $pages, including moveReady(), restoreReady() and renameReady(), to accompany the existing moved(), restored() and renamed() hooks. There was also some refactoring with the way that some hooks are called from $pages to improve their reliability and cover some edge cases where they might have not been called before. See the dev branch commit log for more. The biggest addition this week is likely the newly added support for custom page classes for repeater items. This was added to respond to a feature request initiated by @thetuningspoon and @Jonathan Lahijani let me know about earlier in the week. Here's how it works. If you have a repeater field named "menu_items" then you could create a class named MenuItemsRepeaterPage in /site/classes/MenuItemsRepeaterPage.php, and it would use your custom class rather than the regular RepeaterPage. Though note it must extend RepeaterPage. <?php namespace ProcessWire; class MenuItemsRepeaterPage extends RepeaterPage { // ... } This works with RepeaterMatrix and FieldsetPage as well, since both are derived from regular repeaters. But since both have their own Page classes you'd want to extend their page classes rather than RepeaterPage. In the case of RepeaterMatrix, it uses a class called RepeaterMatrixPage. So if your Matrix field is named "hello_world" then you'd create /site/classes/HelloWorldRepeaterMatrixPage.php: <?php namespace ProcessWire; class HelloWorldRepeaterMatrixPage extends RepeaterMatrixPage {} If you want a custom class for your FieldsetPage field named "seo" then you could create /site/classes/SeoFieldsetPage.php: <?php namespace ProcessWire; class SeoFieldsetPage extends FieldsetPage {} Let's say that you want to use a custom class without using the naming convention and/or file(s) above. You can tell the fieldtype what class to use for its item(s) like this: inclue_once('/path/to/MyCustomRepeaterPageClass.php'); $field = $fields->get('your_repeater_field'); $field->type->setCustomPageClass($field, 'MyCustomRepeaterPageClass'); In the example above, MyCustomRepeaterPageClass would extend RepeaterPage. You'd probably want to do this during the "init" or "ready" state, or at least sometime before you load any items from your Repeater (or Matrix or FieldsetPage) field. If your custom class is not in the ProcessWire namespace, then you'd want to include the namespace in your call, i.e. setCustomPageClass($field, "\\MyNamespace\\MyCustomClass"); If your custom page class is already in /site/classes/, or some other path where it can be autoloaded, then the include_once() line isn't necessary. (API ref pages for getCustomPageClass and setCustomPageClass). Big thanks this week to typneun Designagentur (https://typneun.de/) for posting more than 20 awesome new sites to our ProcessWire sites directory! That made my day. Thanks for reading, more next week, and have a great weekend!

After a previous request for Webp support (6 years ago, times flies…) that Horst and Ryan kindly introduced in PW 3.0.132, I'm back with another request for a new image file format, AVIF, which has landed in almost all browsers. I'm actually surprised no one here in the PW community has been asking for AVIF support in ProcessWire as it seems to be provide much more consistent gains in compression and greater relative quality over Webp, and of course over good old JPEG. My experience using it definitely confirms this. I've been using Cloudinary to serve AVIF images to the browsers that support it, but of course I'd rather not use a third-party service, and use it natively in ProcessWire. Imagemagick supports AVIF if I'm not mistaken. Anyone else is interested?

This week on the dev branch is ProcessWire version 3.0.235. Relative to the previous version, this one contains 19 commits of fixes and feature additions (see commit log). As mentioned last week, this version adds support for custom repeater page classes. Another significant addition was the upgrade from TinyMCE 6.4.1 to 6.8.2, which covers 13 TinyMCE versions with hundreds fixes, improvements and additions (see TinyMCE changelog for all the details). I did also try to upgrade CKEditor to the latest version (which is also the final open source version of CKEditor 4), but found it was making outbound http requests to ckeditor.com, so I reverted to the previous version. Presumably that was just to preform version checks, but what's the point if it's the final version ever... previous versions didn't do that. It also seemed like it could be for some kind of tracking, so I decided to leave it out for now and revisit it later. Lastly, this dev version of ProcessWire adds an improvement to the ProcessWire installer. Now you can choose either "hostname" or "socket" as the DB connection type. Depending on what you choose, it'll provide the appropriate inputs. Previously the installer did not support a socket DB connection option. Thanks for reading and have a great weekend!

Well I was certainly being presumptuous that people would be mapping everything to Fluency and didn't test for that scenario. Actual problem. Easy or not, needs to be fixed. I'll come back and let you know when I've pushed an update!

Hi, This is working. Thank you.

Most likely it’s because FieldtypeOptions is not an allowed fieldtype as a custom field. You can check this in FieldtypeFile’s module page (or in PW’s source code). I don’t know why that is though. An alternative could be to use a FieldtypePage instead.

@TomPich I see. Glad you got it solved. This might easily break your setup when updating the module, though. If you feel strongly about re-enabling the custom date formats, feel free to open an issue on the GitHub repo!

Any plans on adding this to PW, @ryan?

@Jonathan Lahijani Good idea, I'll add an update to make it use it for that case (and the one Bernhard mentioned). It'll likely be the same location as what you've suggested, except it'll get it from FieldtypeRepeater::getCustomPageClass() instead, since that already has all the logic to determine what class to use.

This is so great!! Thx @ryan and @Jonathan Lahijani and @thetuningspoon for suggesting this. I've just implemented first class support for this in RockMigrations and it comes in really handy for the development of RockCommerce. There I have a repeater where clients can add Accessories for every Product. Instead of being RepeaterPages they are now \RockCommerce\Accessory objects which is a lot nicer and makes the code a lot cleaner and I can get rid of many hooks and now my IDE actually understands my code ? For everybody using RockMigrations all you have to do to make that work is to place your file in /site/modules/YourModule/repeaterPageClasses/Accessory.php and add the field constant to that class so that RockMigrations knows which field to apply the pageclass to: <?php namespace RockCommerce; use ProcessWire\RepeaterPage; class Accessory extends RepeaterPage { const field = "rc_product_accessories"; } While working on this I have also improved autoloading of custom page classes and autoloading of regular PHP classes or traits: MyModule/classLoader will auto-load regular PHP classes or traits MyModule/pageClasses will auto-load PW custom pageclasses MyModule/repeaterPageClasses will auto-load PW custom repeater classes (and trigger init() and ready() for them) Extensive docs are already on the dev branch (https://github.com/baumrock/RockMigrations/tree/dev/docs/classloader) and will be merged to main begin of next month ? This is also the case when using $pages->newPage(...) - not sure if that's intentional @ryan ?

Hi @ryan, Thanks for this update. One easy to overlook but important missing part of the repeater update that was made is what happens if you edit a repeater item directly. Assume we have a repeater field named 'books' and you edit the repeater item page by going to /admin/repeaters/books/(for-page)/repeater-item-page When editing it directly, the page to be edited simply gets the RepeaterPage class instead of BooksRepeaterPage class. I managed to hack-fix this by doing this in /wire/core/Templates.php: // determine if custom class available (3.0.152+) if($usePageClasses) { // generate a CamelCase name + 'Page' from template name, i.e. 'blog-post' => 'BlogPostPage' $className = ucwords(str_replace(array('-', '_', '.'), ' ', $template->name)); // *** *** hack fix: if we are editing a page with a template that starts with 'repeater_', assign the correct page class! *** *** if(str_starts_with($template->name, 'repeater_')) { $className = __NAMESPACE__ . "\\" . str_replace(' ', '', $className) . 'RepeaterPage'; $className = str_replace('ProcessWire\Repeater', 'ProcessWire\\', $className); } else { $className = __NAMESPACE__ . "\\" . str_replace(' ', '', $className) . 'Page'; } if(class_exists($className) && wireInstanceOf($className, $corePageClass)) { $pageClass = $className; } } Can what I described be supported as well?

You can also use the selector with the children() method: $page->children("children.count=0, sort=-date");

Hey, it seems to me that there is a wrong thinking or understanding to the whole subject that leads to the confusion. (?) If your comparison are between the compressed image from a third party tool, e.g. photoshop or others, and ONLY the webP output from GD or imagick, then this is comparing apples with bananas. If that's the fact, please read on. If that's not true, please excuse my post and my misunderstanding and forget / don't read the rest of the post. ? EDIT: maybe of additional interest: