Leaderboard

This week the ProcessWire core dev branch version has been bumped to 3.0.230. Currently we are about 10 commits ahead of the main/master branch. Relative to that branch, we have 5 issue fixes, 2 pull requests, major improvements to the wireIconMarkup() function and some minor improvements to the ProcessLogger module. We may merge these updates (among others) to the main/master branch as soon as next week. This week I also developed a new security module called LoginTimer that helps to prevent timing attacks in ProcessWire. Admittedly, I started this more for fun than anything, as I don't think timing attacks are a common problem in ProcessWire. But the more I got into it, the more I became aware of the potential dangers of timing attacks (particularly outside of the ProcessWire world). In any case, I now view it as an important security consideration and definitely thought we should have a module for it. Maybe someday we'll have it in the core too. The module is now available in the modules directory and on GitHub, and I wrote up a blog post to accompany the module and that is located here: https://processwire.com/blog/posts/timing-attacks-and-how-to-prevent-them/

Recent versions of RockMigrations also show you all the settings and their possible values once the module is installed just by hovering over the setting. I'd recommend using this technique rather than copying all the code. Most of the time that is easier and you don't end up with messy migration code...

It seems to be a common misconception that if you start using RockMigration there is no way back and you need to use RockMigrations for everything. That's not the case.

@bernhard Thanks for the quick reply. I just watched another of your videos and together with your explanation I can see the benefits. It looks really nice! I just discovered that you now can copy the code directly from the templates and fields inside the GUI, which makes it even easier to use. You also have a good point about RockMigrations not really breaking stuff as it's just used for the migration and can be replaced later on if necessary. I will test it a bit more and see if it makes sense for my next project.

RockMigrations has a lot more to offer. It has a proven workflow for professional and automated deployments for example and it comes with MagicPages that have a lot of great helpers if you are using custom page classes. It has helpers to make working with the page editor easier (eg the wrapFields() method) and it has helpers to quickly see all the properties you need via mouse hover. Even if I died tomorrow you could just continue using RockMigrations for the next 10 years. If anything is not supported, just go with the regular API. If anything breaks with future updates, just remove RockMigrations from the project and that's it. From that time on you could rely on core api and just remove old code (if that's even necessary). But there's nothing bad in using the core api if you prefer. It's just too cumbersome for me.

Latest dev branch: https://github.com/baumrock/RockMigrations/blob/da0b08b9cc65ee5573a5041971fe6ec575130b98/RockMigrations.module.php#L4107 In the phpdoc the return value is RepeaterMatrixField|null. But inside the function when the field is created with $this->createField($name, 'FieldtypeRepeaterMatrix', $options); it seems to return the generic class Field. I also sometimes experienced the problem, that you described. As a workaround, I first created the field and then added the items in a second run inside a conditional which tests for the correct class of the created field from the first run. But in my latest tests, this did not occur. Unfortunately I can't seem to find out why this is happening sometimes.

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']).

Weird! My image field is set to always return only a single item or none. I still get Pageimages in some cases, Pageimage in other cases. Weird is that I am always trying to get the image of the same object.