Robin S

I believe this is what Inputfield::renderReady() is for: adding dependencies to $config->scripts and $config->styles, and also adding JS objects to ProcessWire.config via $config->js(). But I think all this is not well understood by module developers, myself included. Would be great to get a tutorial some time, maybe in a weekly blog post @ryan?

Hi @bernhard, Do you think it would be possible to support merged cells in FieldtypeHandsontable? Merging cells is a feature in Handonstable, but the merged status (i.e. colspan/rowspan) is lost when the field is saved and reloaded. I guess there would also need to be some way of determining if a cell is merged when getting it via the API.

Is there a way to add a filter based on template flags in Lister (or Lister Pro)? I want to exclude pages that use a system template because I don't want to see repeater pages and I'd rather not have to come back and exclude specific repeater templates as new fields are added. Seems like this should be possible but I can't see a filter option for it. Also, I thought it was possible to type in a custom filter to Lister. Or is that only supported in the standalone InputfieldSelector? Edit: okay, I could just exclude the "Repeaters" or better yet "Admin" parent page in has_parent, but the question stands: it it not possible to filter by properties of a template?

This might be because the "complexify factor" is something internal to the JS library used in InputfieldPassword - perhaps difficult or too time-consuming to port to PHP. I'm putting together a little module that adds a "Generate password" button to InputfieldPassword and from my testing it seems you can probably ignore the complexify setting in your EmailNewUser module because when set to the advised range of 0.5 - 1.0 then any randomly generated password seems to satisfy the complexify setting. Incidentally, I'm not a fan of vague settings like "complexify" because it's totally meaningless to the user who is setting the password. Imagine getting feedback like "Sorry, your password is 0.1 units not complexified enough." The inputfield currently says "too common" when failing the complexify setting but that's not really accurate because a random string can fail a high complexify setting. Settings like this can make for infuriating UX. I noticed that and found it very strange. It must be deliberate because the method comment says: But surely if you are setting a max length you want a max length for the whole password? Can't think why Ryan would have designed it that way. I have put in a feature request on GitHub.

You're absolutely right - I thought the links were opened with Javascript and that therefore I couldn't control the target tab, but I was getting them mixed up with the parent class link which just toggles the list of class methods open and closed. So all good, thanks.

@fbg13, thanks, that might have been what I was remembering. I found a better method in the same class: randomPass(). It gives you a lot more control over the generated password and avoids similar characters like I/1 and O/0. I still think it would be handy to have something that can pull settings from a given FieldtypePassword field though. And a "Generate password" button in the inputfield would be cool too.

@tpr, just following up a request from a while back. I think this is similar to the issue @szabesz raised the other day - it affects both the core Lister and Lister Pro. I'd like to keep the Lister tweaks active in AOS because the "Show action buttons on hover" is handy but I'd like to have a way to turn off the fixed selection of columns. I think if the columns AsmSelect is empty for a Lister then AOS should take that as meaning "do nothing to this Lister's columns".

Is there some API method to generate a random password that satisfies the settings of a given FieldtypePassword field? Something like: // Pseudocode $f = $fields->get('pass'); $random_pass = $f->generatePass(); I feel like I've seen something like this somewhere but maybe that's just wishful thinking. At the moment I'm doing this for random passwords (picked up somewhere in the forums here)... // Generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789!@#$%&*'; $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; ...but is there a better way that takes into account the settings of a password field?

Suppose you have an images field and you want editors to upload a specific number of images to that field. Using a hook in /site/ready.php you can display a field error in Page Edit if the number of images in the field does not match the required number. Just like the standard "required" behaviour, the requirement does not prevent the field being saved if the number of images is not correct so you would still want to check the image count in your template. $wire->addHookAfter('InputfieldImage::processInput', function(HookEvent $event) { $inputfield = $event->object; // Only for this field if($inputfield->hasField != 'images') return; // Only in ProcessPageEdit if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); // Only for this template if($page->template == 'home') { if(count($inputfield->value) !== 4) $inputfield->error("Please upload exactly 4 images to this field"); } });

Hi @adrian I just discovered the feature where the Captain Hook panel links the hookable method name to the API Explorer (if it is installed I guess). This is very cool. But just wondering if you could have it open the API Explorer in a new tab, to avoid navigating away in the current tab?

It's often better to use a PW page for your AJAX url than a standalone PHP file - just create a special template / template file / page for the purpose and call it in your AJAX function. That way everything in PW, init.php, etc, is available just like normal.

Yes, see the "Setting restrictions via a hook" section of the first post / readme.

Hmmm, neither of those is a very good transliteration. $sanitizer->pageNameTranslate() gives the better result of prospere-jouplaboum, which is also the same result you get if you paste the name when adding a user via the PW admin. Seems like the core should be using that in PagesEditor instead of the Sanitizer::toAscii option.

This fieldtype module is part of the core but it is not installed by default. Install it via Modules > Install > FieldtypeFieldsetPage

Hi @bernhard, This module's inputfield is not initialising when AJAX-loaded. So when inputfield visibility is set to "Open when populated + Closed when blank + Load only when opened (AJAX)", and inside AJAX-loaded repeater items.

You're right; I created a new issue for this: https://github.com/processwire/processwire-issues/issues/395 I know, I was just kidding a bit because I think for most people fieldgroups are one of the more arcane aspects of PW.

For high mail volumes something like Mailgun is probably better. I've only used WireMail Mailgun in one project so far but it worked great.

I discovered that when you rename a Repeater or RepeaterMatrix field, the template and fieldgroup used for the Repeater items keep the old name. So I wrote a little function for renaming a Repeater field including the associated template and fieldgroup. To be clear, you do not need to use this function to rename a Repeater field in normal circumstances. The Repeater template is a system template so it's not something you see normally, and as for the fieldgroup... what on earth is a fieldgroup, right? So this is just for perfectionists. Or if you are doing something like checking the template name in some hook and you don't want to have to deal with the old field name. /** * Rename a Repeater / RepeaterMatrix field, including template and fieldgroup * @param string $old_name The existing name of the Repeater field * @param string $new_name The new name for the Repeater field */ function renameRepeaterField($old_name = '', $new_name = '') { // Both arguments are required if(!$old_name || !$new_name) { wire('log')->error('renameRepeaterField(): Both $old_name and $new_name arguments are required.'); return; } // Rename repeater field $f = wire('fields')->get($old_name); if(!$f) { wire('log')->error("renameRepeaterField(): Field '$old_name' not found."); return; }; if(!$f->type instanceof FieldtypeRepeater) { wire('log')->error("renameRepeaterField(): Field '$old_name' is not an instance of FieldtypeRepeater."); return; } $f->name = $new_name; $label = str_replace('_', ' ', ucfirst($new_name)); $f->label = $label; $f->save(); // Rename template $t = wire('templates')->get('repeater_' . $old_name); $t->flags = Template::flagSystemOverride; $t->flags = 0; $t->save(); $t->name = 'repeater_' . $new_name; $t->flags = 8; $t->save(); // Rename fieldgroup $fg = wire('fieldgroups')->get('repeater_' . $old_name); $fg->name = 'repeater_' . $new_name; $fg->save(); } // Use the function in a one-off operation like this renameRepeaterField('sucky_old_name', 'shiny_new_name'); The function derives a label for the field by replacing underscores with spaces and capitalising the first letter of the field name. If you want a different label you can just edit the field in admin afterwards.

I have puzzled over this too, but I think the confusion comes from a non-standard use of the word "absolute" in relation to the URL. So ProcessPageEditLink never inserts an absolute URL in that it never includes the protocol or domain. But I think the absolute option means absolute relative to the site root. So the link URL starts with '/' as opposed to the two relative options which can give a link URL like '../some-page/'. The current behaviour is a good thing, because otherwise all links would break when the root domain changes (e.g. going from dev to live environment). But it would help if the meaning of the absolute option was clarified.

Yeah, I think this was in an earlier version of the regions spec and I just got used to using it (so always identifying the region you are modifying with the id attribute, and then adding pw-append / pw-prepend separately when needed). But I see now that it isn't mentioned in the most recent description of the spec. So maybe a bug/oversight that this functionality isn't working with pw-append="some-id". The main bug to watch out for though is this one: https://github.com/processwire/processwire-issues/issues/302 I really hope that it gets fixed sometime soon.

Adding classes with pw-append / pw-prepend is working for me... <body id='html-body' class='bgimage' pw-append></body>

You're probably right. It won't hurt to add the feature and users can make up their own mind what they find easiest to use. The $page argument for that method actually is the page being edited.

@tpr, I guess the question is "Why use ini format in the AOS config when you can just as easily use a hook?" The hook equivalent of the first two items in your screenshot is: $wire->addHookBefore('Field::getInputfield', function(HookEvent $event) { $field = $event->object; $page = $event->arguments(0); // Add word counter for the "title" field for non-superusers if($field->name == 'title' && !$this->user->isSuperuser()) { $field->showCount = 2; } // Set year range for a date field, if template is "news" if($field->name == 'date_created' && $page->template == 'news') { $field->yearRange = '-3:+3'; } }); Comparing the hook option to the AOS config option my thoughts are: Once the hook function is in place and the $field and $page variables defined, the code for each field override is not significantly longer. It's plain PHP, so we're already familiar with the format. It's easier to read the conditionals. It's file-based. It's easy to dump/log within the hook. It saves any additional complexity being needed in AOS.

Okay, big flip-flop ahead... ...thinking some more, maybe this isn't such a good thing to add into AOS. It introduces another "language" to learn for doing something that is already possible with hooks. And @abdus has recently posted a tutorial for how to add other field settings into the template overrides that allows the admin GUI to be used. And I can see these ini-style settings being difficult to debug. Don't know, I'm really in two minds about it. Be good to hear what others think.

Awesome! I can see this being really powerful, and a nice alternative to working with hooks. What do you think about adding an option for using a file to define these settings? For anything but the briefest snippets I much prefer working in my IDE (version control, etc). It could be a checkbox to activate the file-based option, or just check if "field-overrides.ini" exists in /site/modules/AdminOnSteroids/.