Leaderboard

This week I'm releasing the ProcessWire Fieldtype/Inputfield module "Functional Fields" as open source in the modules directory. This was originally built in 2017 for ProFields, but hasn't required much in terms of support resources, so I thought I should release this newest version (v4) publicly. While this module is completely different from other Fieldtypes, I think it's quite useful and fulfills some needs better than other Field options. Give it a try and please let me know what you think. For an introduction to Functional Fields, please revisit this blog post which covers all the details: https://processwire.com/blog/posts/functional-fields/ Functional Fields is available for download in the modules directory here: https://processwire.com/modules/fieldtype-functional/ Thanks and have a great weekend!

The latest release fixes a bug that was caused by a recent chrome update where moving blocks led to selecting the underlying text: And after the fix: Happy dragging&dropping ?

Hey @kixe I'm using Version 1.2.0 on PW 3.0.229 with PHP 8.1.19 and getting the following error: Deprecated: hexdec(): Passing null to parameter #1 ($hex_string) of type string is deprecated in .../site/modules/FieldtypeColor/FieldtypeColor.module:85 The null coalescing operator is working for me in line 85: public function sleepValue(Page $page, Field $field, $value) { return hexdec($value ?? ''); } Can you fix this? Many greets!

Not an exact answer, but this excellent post might give you some direction on how you can approach this conversation with your boss and collueagues in terms of business.

Yeah that might be more elegant in some situations. Actually you don't even need to put it in a hidden div, you can put it in your markup in a latte comment for example. So those classes will not end up being rendered in your sites markup, but still tailwind will catch them for the final css. I prefer to place markup related things in markup files (*.latte) as for example when working on a "text" block for RockPageBuilder then I want it to contain all necessary markup for that block. So when moving that block into a new project it will still work and I will not have to mess with the tailwind config... But workflows and preferences are different ?

What version did you update from? I think it hasn't been possible to set access controls on fieldsets for some time, maybe years. I think there might be a couple of reasons for why you can't set access controls on fieldsets: 1. Edit access (in Page Edit) for a fieldset is meaningless because a fieldset doesn't store any user-editable data. 2. Generally speaking fields do not "know" that they belong to a fieldset. You can run your own logic like this... ...but there is no simple property of a field A that indicates that it is within fieldset B. So setting view/edit access on a fieldset doesn't actually set view/edit access for fields within that fieldset. Back when it was possible to set access controls on a fieldset it might have appeared that there was access control in that maybe the inputfields didn't get rendered, but I doubt that this was proper access control/security on the fields within the fieldset. So my guess is that Ryan removed that option so devs wouldn't get the wrong impression that they are setting access control on fields by setting it on a parent fieldset. So I think your options are... 1. Set access control on the fields within your fieldset. 2. So long as you know and are comfortable with the fact that it isn't proper access control, you could remove the fieldset using a hook: $wire->addHookAfter('ProcessPageEdit::buildFormContent', function (HookEvent $event) { /* @var InputfieldWrapper $wrapper */ $wrapper = $event->return; // Do some test based on roles if($event->wire('user')->hasRole('some_role')) { // Remove fieldset $fs = $wrapper->getChildByName('your_fieldset_name'); $wrapper->remove($fs); } });