Leaderboard

This week we have a new core version available on the dev branch. Relative to the previous version, 3.0.212 contains 32 commits, 16 issue fixes and 3 PRs. Here's a list of what's been added: Improvements were made to InputfieldImage so that you can now add your own image actions with hooks. More details in this post and ProcessWire Weekly #455. Significant refactoring and improvements were made to the ProcessPageEditLink module. One of the most notable is that it now will retain HTML class attributes on links, even if not specifically configured with the ProcessPageEditLink module. This is useful if you've added custom classes for links in TinyMCE or CKEditor, but haven't also added them to the ProcessPageEditLink module configuration. Improvements were made to Text fields so that HTML Entity Encoder is now automatically added. This was covered in detail in last week's post and in ProcessWire Weekly #457. InputfieldEmail has been updated with optional support for IDN emails and UTF-8 local-part emails, per request. Two new $sanitizer methods have been added: htmlClass() and htmlClasses(). These sanitize HTML class attributes, and it's part of what enables us to support the custom class attribute support added in the ProcessPageEditLink updates mentioned above. Added feature request #480 to support configurable file extensions for translatable files (beyond .php, .module and .inc). Added a new uploadName() method/property to Pagefile/Pageimage objects that returns the original unsanitized filename as it was uploaded. Applies only to files uploaded since this feature was added. Be aware the filename is unsanitized so be careful with it. This was to partially answer feature request #56 and this solution was suggested by Bernhard Baumrock. Demonstrating the above, InputfieldFile now shows this original filename if you hover the file icon, and InputfieldImage shows it if you hover the current filename. HTTP requests that contain an accidental double slash in the URL now redirect rather than render the page. The PagesParents class was refactored so that it is now a lot faster in saving its data to the pages_parents table. This is very noticeable if you have a site with more than million pages when changing the parent of existing pages, especially those having children. Previously there was a [potentially very] long delay at large scale, now it is instant. More details on these updates, and additional updates can also be found in ProcessWire Weekly #455, #456 and #457. Thanks for reading and have a great weekend!

It looks to me that the post above was generated by ChatGPT. It begins with "In ProcessWire,..." and ends in "Keep in mind that...". I doubt that copy/pasting ChatGPT results is a good way of discussion.

Oh wow. Thank you @Robin S! I've been looking for way too long, but I didn't come up with that. My AppApi module does not have the problem because it has Process extended. For that it even says in the documentation that parent::___install() has to be called. But for my simple module that only inherits from WireData, parent::___install() makes no sense. Thanks a lot!

Not sure if this the overall cause of your issue, but one problem I can see in your test module code is that parent::___install() can't work because there is no ___install() method in the parent class (WireData).

@wbmnfktr I agree. If you're busy publishing stuff (your own blog, medium.com or elsewhere), you might want to add your latest articles to the sig. Ditto if you hold events of some sorts (webcasts, seminars) - it doesn't hurt to advertise them in your mail footer. Just don't go crazy with imagery/styling - you don't want the sig to attract more attention than the actual mail message ?

Hello all, After I have posted some question or other I sometimes get an email asking me to "Help others by going to the topic and use the 'Mark as Solution’ button on the post with the best answer" I have looked and looked but never have I found this button, is there a trick or is it really missing? Best regards.best answerhe 'Mark as Solution’ button on the post with the best answergoing to the topic and use the 'Mark as Solution’ button on the post with the best answer

You can edit your first/original post and change the title. Add [SOLVED] at the beginning and you are done. That's our "Mark as solution" button here.

I've seen a lot of commits to support PHP 8+, so I'd say the core will most likely be stable. I'd be more worried about third party modules that might not have been updated recently, so if you are able to, I'd recommend you make a backup and test first in another install with the same environment.

Hey @Kiwi Chris thx for your input, that's an interesting idea! I've often thought about how we could do something similar. The problem is to define what should happen automatically and what manually. The distinction is the key. Sometimes it might be good to have things happen automatically, sometimes the opposite would be preferable. That's why it's 100% manual at the moment. Defining a path to save the code could be an option I guess. The storage/save portion of the problem is trivial. Instead of showing the code in the backend we could easily store it somewhere. But how would you suggest using that file then? Copy&pasting code is easy: $rm->createField('foo', 'text', [ 'label' => 'my foo field', ]); How would that look like when having a code file? $rm->createField('foo', '/site/modules/MyModule/RockMigrations/fields/foo.json'); While that looks good on first sight I'm not sure it will really work. Maybe it could work for fields, but for templates it might not: $rm->createTemplate('foo', '/site/modules/MyModule/RockMigrations/templates/foo.json'); What if that file had a reference to a field that does not exist? One would have to make sure that this field exists before the createTemplate is called. Clear what I mean? When writing migrations manually these problems are likely less of an issue (I guess), because while writing that migrations code you should already realise if you are referring to something that is not yet created. I've also thought about a solution that copies all field and template setups to a dedicated place (like /site/assets/RockMigrations/fields/... or /templates/... ) and on migrate() it first creates all those fields and templates and then does another run that actually applies all settings. That's what the migrate() method does behind the scenes. Maybe it helps if you provide a very detailed step by step use case / workflow how you think that concept could work and how you think we could solve the problem of non-existing references.

Hi @Kiwi Chris I've added a config setting to prevent migrations if you don't want them to be triggered automatically: $config->noMigrate = true; https://github.com/baumrock/RockMigrations/#running-migrations For adding this setting only to your local dev setup see https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/

@snck I am currently working on implementing Repeater Matrix support. It is basically working but needs some more thorough testing. ATM the setMatrixItems() method seems to be working well. If you like, you can grab a copy from https://github.com/gebeer/RockMigrations/tree/repeatermatrix and test it out. This is how you create a Repeater Matrix field: // first create the blank field $rm->createField('repeater_matrix_test', 'FieldtypeRepeaterMatrix', ['label' => 'Product Content Blocks', 'tags' => 'products']); /** * Set items (matrixtypes) of a RepeaterMatrix field * * If wipe is set to TRUE it will wipe all existing matrix types before * setting the new ones. Otherwise it will override settings of old types * and add the type to the end of the matrix if it does not exist yet. * * CAUTION: wipe = true will also delete all field data stored in the * repeater matrix fields!! */ $rm->setMatrixItems('your_matrix_field', [ 'foo' => [ // matrixtype name 'label' => 'foo label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], 'bar' => [ // matrixtype name 'label' => 'bar label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], ], true); Still need to test the other methods for removing/adding items etc. But this one should work. At least it was working in my tests. When testing is completed I will make a PR so @bernhard can implement.

The latest version of RockMigrations comes with a console on the module's settings page. What does that mean? It is now easier than ever to create custom "site-profile" like installation scripts that you can just copy and paste into that console. Add or remove the lines that you need or don't need, check the checkbox to run code on save and hit the save button!! ?

The latest version adds some improvements to alfred styling. Now the ALFRED styles take the primary color setting of this module as primary color ?

I've just implemented a new way of how watching files work and bumped the version to 1.0.0 As from version 1.0.0 the module will not run ALL migrations any more but only the ones that either have the "force" property set or that have changed since the last migrations run. I'm working on a site with lots of RockMatrix blocks and all blocks have their own migrate() method. Using RockFrontend I get livereload as soon as I change a watched file, but then the reload took over 9 seconds because I had so many migrations going on. Now the new version does only migrate changed files and forced files, which brings down the duration for the reload to around 1 second ? When using migrate() from the CLI it will still trigger all migrations, even for unchanged files. That update will especially be interesting for you @dotnetic I guess? ? This is how the log looks like (HomePage was changed and RockMatrix is forced, so these two files are the only ones being triggered):

Looks interesting, thanks for sharing! I put it on my todo list to take a closer look. Interestingly, I have just recently set up a workflow based on CodeKit and its "Kit" file compiling capabilities (Kit == HTML + import features + variables) in order to craft my own site. I boosted the whole thing by also adding Fat-Free PHP to the mix. I use Beyond Compare for syncing to the server. All this is about producing "flat files". Since I also sprinkle PHP here-and-there, I actually invented my own Semi Flat File website approach ? My whole setup is all about using desktop GUI apps, as opposed to (say) npm based cli stuff which can be quite unreliable at times (actually, unreliable too frequently to my liking). All in all, what I like about Publii is that it is a "technically minded" / developer oriented solution, still, components are integrated as a desktop app, so there is no need to experience the pain of npm/webpack/and-similar as all the burden of such things are on the developers of Publiit, and not on the developer of the website(s). After all, I'm a creative guy who likes to create, but I dislike dealing with fixing CLI tools, fighting incompatibility issues and such. That is why I chose ProcessWire in the first place, btw. ?

Just a minor correction. It's the default template and the default parent page.