Leaderboard

This week we have ProcessWire 3.0.229 on both the dev and master/main branches. At this moment, both branches are equally up-to-date. Though I've not yet added the 3.0.229 tag just yet, as it is Friday after all. ? So I'll tag it this weekend or Monday. If you are already running the dev branch on version 3.0.228, then this version contains a few issue fixes and is worth the update. If you are running the previous master/main version 3.0.227 then this version has quite a few worthwhile fixes and I'd recommend upgrading, at least once we add the 3.0.229 tag. Here's a link to the current commit log. That's all for today, have a great weekend!

Form Builder Default Data is a super simple module that adds (via module config settings) the ability to set a default value used as "import data" when creating new Form Builder forms. Form Builder already provides an export option for created forms and an import field when creating new forms, so the only thing this module does is hook after form creation and, in case import data was not provided, set it to the default value instead. The original use case for this module was for a client site where each form should have a consent checkbox with predefined text. With this module the field is always added, but it can be easily removed if a specific form doesn't need it. If updates are needed later they need to be done on a form-by-form basis (or directly via API or SQL), but in this particular case that is an acceptable tradeoff. Anyway, I hope someone else will find this module useful as well ? Modules directory: https://processwire.com/modules/form-builder-default-data/ GitHub: https://github.com/AvoineOy/FormBuilderDefaultData Composer: composer require avoineoy/form-builder-default-data

Hi Ivan, I really appreciate your input and I'm very happy to see your interest in RM growing. Though I have some concerns about your suggestion. Not saying that are bad suggestions, I just try to be realistic. First of all: I'm really, really happy with RM and how it works right now. There has been a lot of refactoring from RM1 to RM2 and that has brought a lot of improvements to the module. The API is in my opinion quite easy and stable to use and the concepts have proven to be working. Second: It's a free module. I think it's one of the best and most powerful modules out there for PW and it can bring a HUGE value to your everyday work, especially if you work in a team or want or need more professional workflows with zero-downtime deployments on multiple environments etc.; I decided to release it for free, because I think this should be part of the core. It should be something that every developer can use to create great modules. To use it as a foundation for, eg quickly and easily create a blog module that creates all the necessary fields and templates that you get a one-click blog setup for ProcessWire. That's simply not possible to do with site profiles and it's simply a pain to do with the regular API. Unfortunately that did not happen. Quite the contrary. People complained about it being too complicated (and didn't even use the module once). And no one ever used RM to create something useful for the community as far as I know. I'm not complaining - it is like it is, but that's the context for the question you are asking. That said, back to topic: I've been talking with @gebeer about refactoring quite some time ago: --bernhard-- In the long term, however, I thought it might make sense to split the API. Similar to how the wire core is split into its own classes. $rockmigration->fields->create('foofield'); $rockmigration->templates->addField('foofield', 'bartemplate', afterfield: 'title'); $rockmigration->migrate([ ... ]); That would really be a completely different API... That means a mega breaking change. I don't know if it's worth it...... --gebeer-- In the long run it's not wrong because it brings more structure into the API. But I think the API is well usable as it is. But I'm still not sure if it would be better. I really like the simple API that is accessible via $rm: Also splitting the API brings in other problems. Many methods do something with two things, eg "addFieldToTemplate" - would that be $rm->fields->addToTemplate("myfield", "mytemplate") or would that be $rm->templates->addField("mytemplate", "myfield") ? I don't understand ? If you have specific ideas I'd be more than happy to hear them and think about how we can improve the module and/or the code quality.

Good day @bernhard! I was testing @gebeer's PR (see this thread), and I was looking at the code of RockMigrations.module.php. It seems to me that it might be beneficial for supporting this long-time to split the code into submodules. I think that all the code that actually creates fields/templates/users... could be moved to a helper module(s). And the main one would deal with all the admin logic. This way it would be not only easier to add field-specific methods, but also possible to use those great methods in different types of workflows (including them). I would love to see other Pro fileds' specific methods added. Maybe other commercial or just 3rd party modules too. Maybe there could be some plugin system for those?

Ah, I always read ProfileUtilities instead of ProfieldsUtilities ? Well anybody could just develop his/her own module based on RM Just create an autoload module that requires RockMigrations, then in the init() method one could do this: public function init() { $this->wire->rockmigrations->fooPlugin = $this; } And then anybody could use that plugin like this: $rockmigrations->fooPlugin->doSomething(); But I'm not sure how useful that would be compared to calling the module directly: $foo = $modules->get('fooPlugin'); $foo->doSomthing(); I know that feature, but I just don't know what benefits you are thinking of..

I know I'm sort of preaching to the choir here, but it's a shame you cannot add images in SF. I think what many devs, me included ,want to use this module for is for global settings which includes things like logo(s). It just makes so much more sense to have these things defined in a separate page rather than by adding fields to the home template but maybe I'm just being too neurotic. Please forgive me if this is a dumb question, but since I have to create a page under the admin page tree to get SF to work, why can't I add images to this very site's /assets/files/ folder? But I guess the answer does something like because the fields I create on the required php or json file don't really exist in the system and are create at runtime?

The main module is a mix of process stuff and helper functions for the main logic. And it is more than 3000 lines. So a little refactoring here seems reasonable. But adding stuff via hooks (or some other way) to implement the plugin architecture seems reasonable too.

Unfortunately it is not possible to create a RM field in one go. The way I do it: // first create the field /** @var RepeaterMatrixField $rmfProduct */ $rmfProduct = $rm->createField('content_product', 'FieldtypeRepeaterMatrix', [ 'label' => 'Product Content Blocks', 'tags' => 'products', 'repeaterAddLabel' => 'Add New Block', ]); // then populate it if (wireInstanceOf($rmfProduct, 'RepeaterMatrixField')) { // TODO quickfix find out why $rmf instanceof Field after create $test = $rm->setMatrixItems('content_product', [ 'features' => [ 'label' => 'Features', 'fields' => [ 'repeater_product_features' => [], ] ], 'gallery' => [ 'label' => 'Image Gallery', 'fields' => [ 'images' => [], ] ], ... ] I will add a hint to the docstring. Note the issue that I had, that after first creation of the field it returned an instance of Field, not RepeaterMatrixField. So I added some logic to avoid errors. Then needed to run initial migration twice to populate. Haven't found out why that happened, yet.

Hi Ivan, thanks a lot for testing this. I've been working with it on a bigger project for the last 9 months and it seems quite stable. I had some health issues and am getting slowly back on track. Will do the PR on the weekend.

Yes i see that the lines that handle the languages (148-154) is not checking if the array key is set yet. Will have to add that check to prevent the warning.

Hi folks, I'm looking for some general advice on where things stand with PHP 8.X and ProcessWire versions. Having recently migrated to a new webhost, I now have the option of using any PHP version (from 5.3 right up to 8.2) and I'm trying to decide on which version to go for. At the moment, things seem to point towards PHP 8.1, but I'd be happy to go for 8.2 if it has been confirmed as stable with the latest ProcessWire DEV (3.0.221). Most of the sites I develop run a few modules (including Formbuilder with custom Stripe payment actions). So, in a nutshell, my question is this: If you had the choice of a clean install, which version of PHP and ProcessWire would you choose? Thanks in advance for the insight! Douglas.