Leaderboard

I think you're right, and some things like Robin's module there are definitely things that could benefit from being in the core as it just makes sense - @ryan please do take a look at this one as it's incredibly useful to visually see how the fields will flow as well as in tabs etc and would be nice if it was in the core too as I don't think it would add much to it but add a lot of benefit to folks who launch sites regularly. This is a bit of a tangent but talking about mental health is less taboo nowadays and I'm sure someone else here will relate - having recently been diagnosed with ADHD I tend to let myself off the hook a bit more now with my forgetfulness. I used to beat myself up about it but the fact is that something needs to be deeply engrained into my day-to-day work to remember it so modules that might help me with setup at the start of a project like TemplateFieldWidths are long forgotten by the end of it ? It's also why I can write PHP and build big projects but cannot hang onto the terminology at all. Like people talk about closures and my brain can rarely remember what "operand" means some days but I can write it all... just the labels on my internal glossary/filing system aren't stuck on very well and keep falling off it feels like. I spent until I was 43 amazed at how people can learn stuff and retain the knowledge so well. I'm very thankful to be pretty good with computers and good enough as a developer that I can do this for a living and live pretty well.

This week the most useful core update is likely the refactored column width slider in the template editor, located Setup > Templates > [your template] > Basics > Fields. You may or may not already know that clicking, holding and dragging the percent indicator on the right side of each field adjusts the column width. With the term “column width”, I mean the width of the field in the page editor, for when you want to have multiple fields in different columns on the same row. It’s a convenient and time saving shortcut. But it was also a little tricky to use, as it allowed anything between 10% and 100% in 1% increments, and it was a little finicky trying to get the percentages just right sometimes. It’s something that’s been bugging me for awhile, and @Pete messaged me on Slack this week and mentioned it. He suggested making it operate in 5% increments rather than 1% increments. He also suggested making a double click of the percent indicator open up the dedicated column width range slider that allows for more precise adjustments. I thought those were good suggestions, so I went ahead and implemented them this week. In addition to now using 5% increments, it also supports the commonly used 33%, 34% and 66% width values as well. But if you happen to already have some field that is using a less common width, like 27% or 72%, etc., then it reverts back to 1% increments for the same behavior as before. Of course, you can also use the 1% increments by double clicking the percent indicator to open the dedicated column width range slider. Thanks Pete for the suggestions, I think it all works better now. I’ll be applying the same changes to FormBuilder’s equivalent of this feature as well. This week I’ve also been working on the new CustomFields modules (FieldtypeCustom and InputfieldCustom). Most recently I’ve been working on adding support for multi-language fields, as well as adding more examples and tools to make it really easy to use and configure. I may have it ready as soon as next week or the following week. The PageAutosave module is also getting a new version soon. I’ve been focused on the LivePreview feature of it and making a version of it that doesn’t depend on auto-save. The alternative LivePreview option (which we’ll just call “Preview”) will work anywhere because it has no field limitations. It simply updates the preview window whenever you save the page. While that’s not as fancy as live preview as-you-type, it’s still very helpful, while being reliable in any situation. It’s reliable and portable enough that I may end up putting the feature in the core, but will be testing it out in the next version of the PageAutosave module first. Have a great weekend!

There is so much the community already has a solution for... we just have to remind ourselves about these solutions. (to be fair... I regularly can't remember core functionalities as well) Especially in cases like this, I would vote for something like a "merge this module into core"-principle of some kind, yet I want to see module authors thrive for and because of their efforts. Similar to the Weekly update – 2 August 2024 announcement - where we saw similarities to already existing solutions:

Ah so that's why this all felt so familiar! I remember using that one a while back on a site and then forgot all about it - thanks Robin for that one and to Ryan for improvements to the core field widths.

I became so used to use Template Field Widths that I almost always install it on larger projects. Super fast editing of values, tabbing around and done.

Good catch. Neither of those modules are enabled by default. Looking up that module and finding a discussion, this might be useful to read up. In the description of the module, it states that it is under development (i.e.: not finished). ?

Thanks @bernhard for helping me out yesterday! Will try to include jQuery only on the necessary pages with a different implementation in the new week.

Great news, thank you @ryan! For FormBuilder, it will be a nice improvement. Even though it is a nice improvement for template fields and repeaters as well, I think I will still use @Robin S's visual aid: https://processwire.com/modules/template-field-widths/ Which is even faster to work with, as it provides a wireframe look, reducing the need to guess what the final layout will look like.

OK I found a way to disable it, not necessarily the root of the problem though. I had the core module SystemNotifications installed and "Notification status" was turned on. I turned it off now and the issues disappeared. It's a core module, so is that the expected behaviour? Or is it a known bug? I'm reluctant to install it on other installations just to investigate it further…

I was able to speak with someone at TinyMCE on a Zoom call this week and we had a good meeting. They are going to make it possible for us to continue using TinyMCE 7.x+ in the core, even though it is using a GPL license, while we use the MPL 2.x license. They will make a custom license available for ProcessWire and I hope to have the details of that potentially next week. We’ll have to review the conditions and everything to make all is good, but it sounds like it will very likely solve the issue for us. I’m really happy about this and look forward to working with TinyMCE 7.x They also expressed interest in us potentially collaborating on a separate module that would make some of the commercial and advanced TinyMCE features available to ProcessWire users that wanted them via a paid service, like a Pro module. This option hasn't been available to us before, so I thought it sounded interesting. I'll definitely be communicating with them more about that to see what's possible. That’s all I know so far, but will keep you up-to-date as I learn more.

This week I've bumped the dev branch version to 3.0.241. Relative to the previous version, this one has 29 commits with a mixture of issue resolutions, new features and improvements, and other minor updates. A couple of PRs were also added today as well. This week I've also continued work on the FieldtypeCustom module that I mentioned last week. There were some questions about its storage model and whether you could query its properties from $pages->find() selectors (the answer is yes). Since the properties in a custom field are not fixed, and can change according to your own code and runtime logic, it doesn't map to a traditional DB table-and-column structure. That's not ideal when it comes to query-ability. But thankfully MySQL (5.7.8 and newer) supports a JSON column type and has the ability to match properties in JSON columns in a manner similar to how it can match them in traditional DB columns. Though the actual MySQL syntax to do it is a little cryptic, but thankfully we have ProcessWire selectors to make it simple. (It works the same as querying any other kind of field with subfields). MySQL can also support this with JSON encoded in a more traditional TEXT column with some reduced efficiency, though with the added benefit of supporting a FULLTEXT index. (Whereas the JSON column type does not support that type of index). For this reason, FieldtypeCustom supports both JSON and TEXT/MEDIUMTEXT/LONGTEXT column types. So you can choose whether you want to maximize the efficiency of column-level queries, or add the ability to perform text matching on all columns at once with a fulltext index. While I'm certain it's not as efficient as having separate columns in a table, I have been successfully using the same solution in the last few versions of FormBuilder (entries), and have found it works quite well. More soon. Thanks for reading and have a great weekend!

This week I received some client specifications for project that indicated it was going to need a lot of fields, and fields within fields. There are a lot of tools for this kind of stuff in ProFields, but none that I thought would make this particular project "easy" per se. The closest fit was the Combo field, but with 40-50 or so subfields/columns within each of the "groups", it was still going to be kind of a pain to put together. Not to mention, just a lot of fields and subfields to manage. To add more challenge to it, there was another group of 30 or so fields that needed to be repeatable over any number of times (in a repeater field). I wasn't looking forward to building out all these fields. That scale of fields/subfields is at the point where I don't really want to build and manage it interactively. Instead, I want to just edit it in a code editor or IDE, if such a thing is possible. With any large set of fields, there's often a lot of redundant fields where maybe only the name changes, so I wanted to be able to just copy and paste my way through these dozens of fields. That would save me a lot of time, relative to creating and configuring them interactively in the admin. Rather than spending a bunch of time trying to answer the specifications with existing field types, I ended up building a new Fieldtype and Inputfield to handle the task. Right now it's called the "Custom" field (for lack of a better term). But the term kind of fits because it's a field that has no structure on its own and instead is defined completely by a custom JSON file that you place on your file system. (It will also accept a PHP file that returns a PHP array or InputfieldWrapper). Below is an example of defining a custom field named "contact" with JSON. The array keys are the field names. The "type" can be the name of any Inputfield module (minus the "Inputfield" prefix). And the rest of the properties are whatever settings are supported by the chosen Inputfield module, or Inputfield properties in general. /site/templates/custom-fields/contact.json { "first_name": { "type": "text", "label": "First name", "required": true, "columnWidth": 50 }, "last_name": { "type": "text", "label": "Last name", "required": true, "columnWidth": 50 }, "email": { "type": "email", "label": "Email", "placeholder": "person@company.com", "required": true }, "colors": { "type": "checkboxes", "label": "What are your favorite colors?", "options": { "r": "Red", "g": "Green", "b": "Blue" } }, "address": { "type": "fieldset", "label": "Address", "children": { "address_street": { "type": "text", "label": "Street" }, "address_city": { "type": "text", "label": "City", "columnWidth": 50 }, "address_state": { "type": "text", "label": "State/province", "columnWidth": 25 }, "address_zip": { "type": "text", "label": "Zip/post code", "columnWidth": 25 } } } } The result in the page editor looks like this: The actual value from the API is a WireData object populated with the names mentioned in the JSON definition above. If my Custom field is named "contact", I can output the email name like this: echo $page->contact->email; Or if I want to output everything in a loop: foreach($page->contact as $key => $value) { echo "<li>$key: $value</li>"; } After defining a couple large fields with JSON, I decided that using PHP would sometimes be preferable because I could inject some logic into it, such as loading a list of 200+ selectable countries from another file, or putting reusable groups of fieldsets in a variable to reduce duplication. The other benefits of a PHP array were that I could make the field labels __('translatable'); and PHP isn't quite as strict as JSON about extra commas. So the module will accept either JSON or PHP array. Here's the equivalent PHP to the above JSON: /site/templates/custom-fields/contact.php return [ 'first_name' => [ 'type' => 'text', 'label' => 'First name', 'required' => true, 'columnWidth' => 50 ], 'last_name' => [ 'type' => 'text', 'label' => 'Last name', 'required' => true, 'columnWidth' => 50 ], 'email' => [ 'type' => 'email', 'label' => 'Email address', 'placeholder' => 'person@company.com' ], 'colors' => [ 'type' => 'checkboxes', 'label' => 'Colors', 'description' => 'Select your favorite colors', 'options' => [ 'r' => 'Red', 'g' => 'Green', 'b' => 'Blue' ], ], 'address' => [ 'type' => 'fieldset', 'label' => 'Mailing address', 'children' => [ 'address_street' => [ 'type' => 'text', 'label' => 'Street' ], 'address_city' => [ 'type' => 'text', 'label' => 'City', 'columnWidth' => 50 ], 'address_state' => [ 'type' => 'text', 'label' => 'State/province', 'columnWidth' => 25 ], 'address_zip' => [ 'type' => 'text', 'label' => 'Zip/post code', 'columnWidth' => 25 ] ] ] ]; The downside of configuring fields this way is that you kind of have to know the names of each Inputfield's configuration properties to take full advantage of all its features. Interactively, they are all shown to you, which makes things easier, and we don't have that here. There is yet another alternative though. If you define the fields like you would in a module configuration, your IDE (like PhpStorm) will be able to provide type hinting specific to each Inputfield type. I think I still prefer to use JSON or a PHP array, and consult the docs on the settings; but just to demonstrate, you can also have your custom field file return a PHP InputfieldWrapper like this: $form = new InputfieldWrapper(); $f = $form->InputfieldText; $f->name = 'first_name'; $f->label = 'First name'; $f->required = true; $f->columnWidth = 50; $form->add($f); $f = $form->InputfieldText; $f->name = 'last_name'; $f->label = 'Last name'; $f->required = true; $f->columnWidth = 50; $form->add($f); $f = $form->InputfieldEmail; $f->name = 'email'; $f->label = 'Email address'; $f->required = true; $f->placeholder = 'person@company.com'; $form->add($f); // ... and so on Now that this new Fieldtype/Inputfield is developed, I was able to answer the clients specs for lots of fields in a manner of minutes. Here's just some of it (thumbnails): There's more I'd like to do with this Fieldtype/Inputfield combination before releasing it, but since I've found it quite handy (and actually fun) to build fields this way, I wanted to let you know I was working on it and hope to have it ready to share soon, hopefully this month. Thanks for reading and have a great weekend!

Clickbait title aside, I recently found a cool new feature in PHP 8.1 and wanted to share it with you, in case you didn't know this either. Starting with PHP 8.1 you can write $this->method(...) (yes, that's the actual syntax, not a placeholder) to reference a method. I find this super convenient, especially for defining hooks. Plus the IDE can refactor this much better than the traditional [$this, 'method'] callback. <?php class MyModule { public function init() { $this->addHookAfter('ProcessPageView::finished', $this->doSomething(...)); } private function doSomething(HookEvent $event) { // TODO: something } }

A module to work around a few shortcomings of Fieldset and FieldsetPage fields. Not submitted to the modules directory because I'm hopeful that most if not all of this will be handled in the core eventually. https://github.com/processwire/processwire-issues/issues/1953 https://github.com/processwire/processwire-requests/issues/533 https://github.com/processwire/processwire-requests/issues/534 Fieldset Helper Adds some visibility features to fields of type FieldtypeFieldsetOpen and FieldsetPage, and adds a helper method to get the child fields of a FieldtypeFieldsetOpen field. Visibility The module adds support for the following visibility settings to FieldtypeFieldsetOpen and FieldsetPage fields: Open when populated + Closed when blank Open when populated + Closed when blank + Load only when opened (AJAX) * Open when populated + Closed when blank + Locked (not editable) Open when blank + Closed when populated "Blank" in the context of a fieldset means that all the child fields within the fieldset are blank. * The AJAX part of this option doesn't currently work for FieldsetPage. Get the child fields of a fieldset If you've ever wanted to get the child fields that are within a fieldset you will have noticed that the ProcessWire API doesn't provide a direct way of doing this. Although they appear indented in Edit Template, the child fields are actually all on the same "level" as the other fields in the template. The module adds a FieldtypeFieldsetOpen::getFieldsetFields() method that you can use to get the child fields of a fieldset for a given page. Example: $field = $fields->get('my_fieldset'); $template = $templates->get('my_template'); $fieldset_fields = $field->type->getFieldsetFields($field, $template); First argument: the fieldset Field, i.e. a Field whose type is an instance of FieldtypeFieldsetOpen (this includes FieldtypeFieldsetTabOpen). Second argument: the Template that the fieldset field is part of. Return value: a FieldsArray of child fields. If there is a nested fieldset inside the fieldset then the child fields of the nested fieldset are not included in the return value, but of course you can use the method again to get the child fields of that fieldset. https://github.com/Toutouwai/FieldsetHelper

emplate Field Widths Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template. Since v0.2.0 the module also adds a similar field to the settings of Edit Field for Repeater, FieldsetPage and Repeater Matrix allowing you to quickly set the widths of inputfields within the Repeater/FieldsetPage field, or within each Repeater Matrix type. Note: widths are only saved if the edit form is submitted with the "Field widths" field in an open (non-collapsed) state. Edit template Edit Field: Repeater Edit Field: Repeater Matrix Why? When setting up a new template/repeater or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process. Config options You can set the default presentation of the "Field widths" field to collapsed or open. Widths entered into the "Field widths" field are only applied if the edit form is submitted with the field in an open (non-collapsed) state. "Collapsed" is the recommended setting if you think you might also use core inputs for setting field widths in a template context. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width. https://github.com/Toutouwai/TemplateFieldWidths https://modules.processwire.com/modules/template-field-widths/

This module is inspired by and similar to the Template Stubs module. The author of that module has not been active in the PW community for several years now and parts of the code for that module didn't make sense to me, so I decided to create my own module. Auto Template Stubs has only been tested with PhpStorm because that is the IDE that I use. Auto Template Stubs Automatically creates stub files for templates when fields or fieldgroups are saved. Stub files are useful if you are using an IDE (e.g. PhpStorm) that provides code assistance - the stub files let the IDE know what fields exist in each template and what data type each field returns. Depending on your IDE's features you get benefits such as code completion for field names as you type, type inference, inspection, documentation, etc. Installation Install the Auto Template Stubs module. Configuration You can change the class name prefix setting in the module config if you like. It's good to use a class name prefix because it reduces the chance that the class name will clash with an existing class name. The directory path used to store the stub files is configurable. There is a checkbox to manually trigger the regeneration of all stub files if needed. Usage Add a line near the top of each of your template files to tell your IDE what stub class name to associate with the $page variable within the template file. For example, with the default class name prefix you would add the following line at the top of the home.php template file: /** @var tpl_home $page */ Now enjoy code completion, etc, in your IDE. Adding data types for non-core Fieldtype modules The module includes the data types returned by all the core Fieldtype modules. If you want to add data types returned by one or more non-core Fieldtype modules then you can hook the AutoTemplateStubs::getReturnTypes() method. For example, in /site/ready.php: // Add data types for some non-core Fieldtype modules $wire->addHookAfter('AutoTemplateStubs::getReturnTypes', function(HookEvent $event) { $extra_types = [ 'FieldtypeDecimal' => 'string', 'FieldtypeLeafletMapMarker' => 'LeafletMapMarker', 'FieldtypeRepeaterMatrix' => 'RepeaterMatrixPageArray', 'FieldtypeTable' => 'TableRows', ]; $event->return = $event->return + $extra_types; }); Credits Inspired by and much credit to the Template Stubs module by mindplay.dk. https://github.com/Toutouwai/AutoTemplateStubs https://modules.processwire.com/modules/auto-template-stubs/

You could add the datalist to a normal text field using a hook in /site/ready.php: $wire->addHookBefore('InputfieldText::render', function(HookEvent $event) { /* @var InputfieldText $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; if($field && $field->name === 'my_field') { $inputfield->attr('list', 'my-list'); $inputfield->appendMarkup = <<<EOT <datalist id="my-list"> <option value="One"> <option value="Two"> <option value="Three"> </datalist> EOT; } });

Just add: protected static $fM; at line #19 You'll also need to change line 94 from: self::$fM['type']($f, $fM['label'], $data[$f], $fM['desc']) to: self::{$fM['type']}($f, $fM['label'], $data[$f], $fM['desc'])