Robin S

I just tested and couldn't find any problem with required if conditions inside a repeater - like you said, they seem to work fine. And I tried it some while ago and couldn't find a problem then either: So maybe there are some specific types of required if conditions that don't work, or maybe it was a limitation that was later fixed. Do you want to file a GitHub issue so Ryan can take a look and either clarify the types of condition that don't work or else remove the notice? Edit: scratch all that - the required if conditions don't work as expected inside a repeater. At first it seems that they do work, because when you fulfill the required if condition the asterisk appears and the field is indeed required. But the problem is that field is always required, so even if you don't fulfill the required if condition and the asterisk is removed the field is still required.

There is a notice Regarding "Page List" input types... But the "specify only the parent" part of that is contradicted by the requirements for the core "allow new pages to be created from the field" option, so if you want that you would need to specify a template also. The template only relates to the new page that is added - it doesn't restrict the selectable pages for a Page List input type. If you're committed to the Page List input type and want to try workarounds for restricting the types of pages that can be selected you could look at hiding the "Select" button according to the class of page item in the inputfield. See the thread below for a different context but the same general idea:

If you mean you want to have different toolbars for different matrix types that use the same CKEditor field then changing field settings in template context is not going to be a solution because all matrix types within a Repeater Matrix field use the same template. And some hook that checks the matrix type is not going to be a solution either because there is only a single CKEditor configuration per CKEditor field that is sent to the ProcessWire.config JS object. So all instances of a CKEditor field on a page get the same config. I think the only way to have different CKEditor configs for different matrix types is to use a different CKEditor field for each matrix type that needs a custom toolbar. If you want to use those CKEditor fields in different templates besides the Repeater Matrix template then you can use template context for overrides.

Nice one @Sebi2020! Maybe you could look at enhancing the module by allowing the configuration of some Tagify options within the field settings. In particular I'm thinking it would be good to be able to set the "whitelist" and "maxTags" options.

I've added support for CKEditor within a Table field in v0.1.10.

Your cache function doesn't return JSON though, but rather a PageArray with the full user objects. I suggest only returning the JSON data you need to see if that makes a difference. That's correct. A solution is to use $pages->findMany() with the user template. $members = $cache->get('members', '+10 minutes', function($pages) { $member_pages = $pages->findMany('template=user, roles=member, sort=lastname, limit=3000, check_access=0'); return json_encode($member_pages->explode(['name', 'email'])); // Whatever fields/properties you need from the member pages });

You can set the default sort via a hook in /site/ready.php: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { /* @var ProcessPageLister $lister */ $lister = $event->object; // Only for Users lister if($lister->parent->id !== 29) return; // Set the sort to whatever $lister->defaultSort = 'email'; }); Note that the user can change the sort within the lister, and this will persist for the current session. So to get back to the default sort you are setting in the hook the user would need to reset the lister: Or if you want the default sort to apply every time the Users lister is visited (but still allow the user to change the sort while they are using the lister) then you could do this: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { /* @var ProcessPageLister $lister */ $lister = $event->object; // Only for Users lister if($lister->parent->id !== 29) return; // Reset the sort when the lister is first loaded if(!$event->config->ajax) $lister->sessionSet('sort', ''); // Set the sort to whatever $lister->defaultSort = 'email'; });

JSON in the description field is detected if the first character is { and the last character is }, or if the first character is [ and the last character is ]. See here. So one workaround could be to prefix the JSON with some character... *{"json": "here"} ...and then trim the first character before the module decodes the JSON.

Thanks for the updates @ryan! Going forward, what do you think should be done about the sanitizer methods included in the PhpDoc of WireInputData? These sanitizer methods are also the basis for what gets an entry in the API documentation for WireInputData. As noted in this request the sanitizer methods included in the WireInputData PhpDoc were already out of date (i.e. incomplete). The new $santitizer methods added in 3.0.125 are also not included there. Do you think the PhpDoc of WireInputData should just aim to keep pace with new $sanitizer methods as they are added? Or now that multiple methods can be chained together... // access sanitizer on $input as method $q = $input->get->text50_entities('q'); ...in a way that couldn't be handled as lines in the PhpDoc, perhaps it would be better to drop the list of sanitizer methods and instead include some general note about how $sanitizer methods (with a link to the $sanitizer documentation) can be used/chained with $input?

@szabesz, there's nothing broken in the "official version" of FieldtypeDecimal that's in the modules directory. I use it in nearly every project without problems. Arjen's fork adds a feature for distinguishing empty and zero values in a selector that a person may or may not need (personally I've never needed it so far).

There are limitations to the number of significant figures that can be stored by the FLOAT column type in the database. There are also precision limitations to how floats are handled in PHP. These are fundamental limitations and PW cannot do anything about them. However it would be good if the PW admin warned the developer about them so people aren't caught out - there is a request for this but it hasn't been actioned yet: https://github.com/processwire/processwire-requests/issues/173 Best to use the Decimal fieldtype in cases where the limitations of the Float fieldtype are a problem.

I had to do something like this recently. The "include" clause in the selector applies to the whole selector - you cannot have an include clause apply only to one OR-group. So the solution is to use include=hidden outside of the OR-groups, then exclude hidden pages within the OR-groups where you don't want the include=hidden to apply. So the selector for your example above would be: $results = $pages->find("(template=x|y|z, status!=hidden), (template=a), title|body~=$searchquery, include=hidden");

If you want to load your CSS/JS assets last in the <head> then see this approach too:

v0.1.1 released. Adds a config option to hide the inputfield label in the form. Note: this feature not currently working for the Basic framework due a FormBuilder issue.

Try this... $wire->addHookBefore('ProcessPageAdd::execute', function(HookEvent $event) { // Get the id of the parent page the new page is being added under $parent_id = $event->input->get->int('parent_id'); // Return early if not the id of the parent page you want to target if($parent_id !== 1234) return; // The following line probably not strictly necessary because we will redirect in a moment anyway $event->replace = true; // Create the page $p = $event->pages->add('your-template-name', $parent_id, 'your-page-name'); // Make the page unpublished to begin with $p->addStatus(Page::statusUnpublished); // Save the unpublished status $p->save(); // Redirect to edit the page just created $event->session->redirect($p->editUrl); });

I see what you mean, although there isn't really any "cost" to a Process module being installed because it doesn't do anything unless you visit its page. So for the sake of new users trying to understand the different ways they can use Duplicator I still think it would be good to auto-install the Process module and CRON-only users can just ignore it, or uninstall it if they don't want to see the item in the Setup menu for some reason. But now that I have used Duplicator for a bit I could figure it out either way.

Speaking personally, I wouldn't want to reveal the admin URL to visitors on the frontend. I haven't thought about the practicality but if I wanted to render admin form elements and Process module output on the frontend I think my approach would be to render it via frontend templates and include whatever admin CSS or JS was needed. So basically the approach taken by FormBuilder, and if an iframe could be used that would of course reduce the chance of CSS conflicts. Where AJAX responses were needed (e.g. PageAutocomplete fields) then some special frontend page/template would be needed for this, or perhaps the idea I floated here:

I agree the wording could be clearer here. If you look at the method code for Page::hasField() it is: return $this->template ? $this->template->fieldgroup->hasField($field) : false; So it's just an alias for Fieldgroup::hasField() where the fieldgroup is that used by the page's template. And the explanation for Fieldgroup::hasField() is: Not great English but you get the meaning. So if the given field name / field id / field object is not part of the page's fieldgroup then Page::hasField() will return false. @Henner7, if your intention is to check whether $item has an ID property and the property is not 0 (i.e. it is not a NullPage) then typically you would just check the "truthiness" of the ID property... if($item->id) { //... }

In the API documentation, for some reason all the methods under any of the Core Classes (e.g. Fieldgroup, Template) are trying to link to pages under the "Page" documentation - often linking to pages which don't exist. For example... Fieldgroup::getTemplates() links to: https://processwire.com/api/ref/page/get-templates/ Templates:getNumPages() links to: https://processwire.com/api/ref/page/get-num-pages/

@flydev, just trying this module for the first time today. Very nice! The subfolder exclusion options are coming in handy. Do you think the main Duplicator.module should automatically install ProcessDuplicator.module? Otherwise if you install by entering the Duplicator classname then the Process module doesn't get installed and it's not immediately obvious why the link from the config screen to the Package Manager results in an "Unrecognized path" error.

Yes. The Lister Pro class extends ProcessPageLister.

Check out the PLUs (Page Lister URLs) module. Or if you want to go the hook route try manipulating the defaultSelector property of the Lister: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { // Only for the initial load, not for subsequent user changes if($event->config->ajax) return; $lister = $event->object; // Do something here to identify if this is the lister you want to modify and return early if not // Then manipulate the defaultSelector property... // E.g. append to the existing defaultSelector $lister->defaultSelector .= ', your_field=your_value'; });

A page's ID is a property of the page but it's not a field that belongs to the page's template/fieldgroup. So $page->hasField() would not be expected to return true for 'id'.

True. Although the code suggested in the message would still resolve the issue so long as you haven't overwritten $page. If things go in the direction that I think Ryan has hinted at of the Functions API being the new default approach then maybe we'll see message references to API variables start switching over to the Functions API equivalents.

It's sort of breaking a cardinal rule in the first line though. If people overwrite core API variables then confusing error messages would be just the beginning of their troubles. ?