Robin S

Is the event handler specific to the page reference field inside only new repeater items, or should it handle events of the page reference field inside all repeater items? Because if it's the latter you probably don't need to do anything in particular when a new repeater item is added - rather you can attach the handler to "document" and then use a selector to filter descendants. So supposing your handler is for the "change" event of selects named "foo" inside repeater items... $(document).on('change', 'select[name^=foo_repeater]', function() { console.log('repeater select changed'); }); Edit: and if only inside new repeater items then this seems to do the job: $(document).on('change', '.InputfieldRepeaterItemRequested select[name^=foo_repeater]', function() { console.log('new repeater item select changed'); });

To do this you would set the "maxFiles" property of the inputfield dynamically. In the field settings set "0" for "Maximum files allowed" (i.e. no limit). In /site/ready.php: $wire->addHookBefore('InputfieldImage::processInput', function(HookEvent $event) { /* @var InputfieldImage $inputfield */ $inputfield = $event->object; $process = $event->wire('process'); $user = $event->wire('user'); // Only for a specific field if($inputfield->hasField != 'images') return; // Only in ProcessPageEdit if($process != 'ProcessPageEdit') return; $page = $process->getPage(); // Only for a specific template if($page->template != 'basic-page') return; $limit = null; if($user->hasRole('basic-member')) $limit = 2; if($user->hasRole('silver-member')) $limit = 5; // Only if a limit applies to this role if(!$limit) return; $inputfield->maxFiles = $limit; });

For 90% of these kinds of cases I do it like @Jens Martsch - dotnetic suggested, and in the template of the page (event, news item, etc) I have: // Throw 404 if item is future-dated if(!$user->isLoggedin() && $page->getUnformatted('date_1') > time()) throw new Wire404Exception(); But on a complex site where the pages might be queried from many selectors in many different places then unpublishing is the way to go.

@FlorianA, you can probably achieve what you want by using hooks. ProcessForgotPassword::renderEmailBody is hookable and includes the link URL as an argument, to which you could add the verification code (which is also an argument) as a GET parameter. Then you could hook before InputfieldText::render and if the field name is "verify" (you could do additional checks if needed) you could check $input and set the value from the GET parameter.

The $page->links() method takes two optional arguments: NAME TYPE(S) DESCRIPTION selector (optional) string, bool Optional selector to filter by or boolean true for “include=all”. (default='') field (optional) string, Field Optionally limit results to specified field. (default=all applicable Textarea fields) You are passing only one argument, so this is interpreted as the first argument. Passing "$field='blog_body'" doesn't make this become the second argument - your code is saying "pass the string 'blog_body' as the first argument and also assign the string 'blog_body' to a variable named $field". If you want to specify the second argument (field) but not the first (selector) you need to pass a value for the first argument, and in this case you would pass the default value which is an empty string. So you would do this: $items = $page->links('', 'blog_body'); It would be reasonable to think that you could pass a sort as part of the selector argument, but actually this doesn't work because behind the scenes this method is ultimately just getting some page IDs and then loading data from the database using those IDs without any ORDER_BY clause. So you'll need to sort the links after you get them: $items = $page->links('', 'blog_body'); $items->sort('-blog_date');

The way that I find easiest is to get the Field object that is associated with the Inputfield via hasField and check its name, because the Inputfield object's name changes inside a Repeater but the Field object's name doesn't. So something like this: $wire->addHookAfter('InputfieldDatetime::processInput', function(HookEvent $event) { $inputfield = $event->object; $field = $inputfield->hasField; if(!$field || $field->name !== 'your_field_name') return; // ... });

Yes. Some possible solutions, in order from easiest to hardest or least recommended: 1. Use FieldsetGroup instead of FieldsetPage if you have ProFields. 2. Use a normal Fieldset instead of FieldsetPage, and just bite the bullet if you have to spend some time setting up the fields in multiple templates. 3. Write some custom JS for the admin that adds/removes the HTML required attribute to the adjacent field depending on the state of the checkbox. 4. Use a hook to a processInput method to do custom validation for the required fields. So if your required field is a text field then you would hook InputfieldText::processInput. Here is an example for a text field named "text_1" that is required if a field named "checkbox_1" is checked inside the same Repeater item (or FieldsetPage item): $wire->addHookBefore('InputfieldText::processInput', function(HookEvent $event) { /* @var InputfieldText $inputfield */ $inputfield = $event->object; // Get field $field = $inputfield->hasField; // Only for field "text_1" if(!$field || $field->name !== 'text_1') return; // Get page $page = $inputfield->hasPage; // Only for fields in a Repeater page if(!$page instanceof RepeaterPage) return; // Repeater suffix $r_suffix = '_repeater' . $page->id; // Get checkbox field $wrapper = $inputfield->parent; $checkbox = $wrapper->getChildByName('checkbox_1' . $r_suffix); if(!$checkbox) return; // If checkbox is checked then field is required if($checkbox->value) { $inputfield->required = 1; } else { $inputfield->required = 0; } }); If you have multiple required fields you'll need to adjust this to suit. 5. I posted some suggested changes to the core to support required-if inside Repeaters here: https://github.com/processwire/processwire-requests/issues/262 But making custom changes to the core is not recommended because they will be lost when you upgrade.

If you have the Version Control module installed it might be the issue linked to below, which has been fixed in an update to the module:

Hey @adrian, What do you think about the idea of adding a link to the "Restore" page somewhere within the main interface? I know it's accessible via the flyout menu but it's easy (for me at least) to overlook or forget this and there have been a few times where I've started to worry that I don't have the ability to restore a backup when an action fails due to an error or I've navigated away from the success screen which includes the restore link. Then after a moment I remember where the link is and breathe a sigh of relief. ?

Loaded pages are cached: https://github.com/processwire/processwire/blob/master/wire/core/PagesLoaderCache.php Try calling $pages->uncacheAll() between renders of the same page.

Inputfield Selector Select ID Uses the Page List Select inputfield for user-friendly input of page IDs into Inputfield Selector. Overview This module adds a feature to Inputfield Selector, which is most commonly seen in Lister (Find) and Lister Pro. When adding a filter row for "Parent", "Has parent/ancestor" or "ID" the user is expected to enter a page ID to match against. But this is not as user-friendly as it could be because the user may be able to identify the desired page by its title or location in the tree but not know its ID. This is particularly the case for site editors who may not even understand the concept of a page ID. So this module adds a thunderbolt icon to relevant rows in Inputfield Selector. When the icon is clicked a Page List Select inputfield opens in a modal window, allowing the user to visually select a page from the tree. When the modal is closed with "OK" the ID of the selected page is inserted into the filter row. Tip After a page selection has been made in the modal window the "OK" button will automatically receive focus so if you prefer you can close the modal by hitting the Enter key rather than mousing to the OK button. Installation Install the Inputfield Selector Select ID module. https://github.com/Toutouwai/InputfieldSelectorSelectID https://modules.processwire.com/modules/inputfield-selector-select-id/

You need to create a database and a user for the database before you complete that part of the PW installation process. Then you will know the database name, user name, and password for the user. I'm not a XAMPP user but I'm pretty sure that it comes bundled with phpMyAdmin. So you open phpMyAdmin in your browser (probably at http://localhost/phpmyadmin) and then the quickest way is to create the user and database in one step at User accounts > Add user account After you have created the user/database then you will know the user name, database name (which will be the same as the user name) and the password so you can complete the PW installation process.

Thanks for the report. PHP 7.3 apparently makes some changes to the regex engine and so an update to the bundled Simple HTML Dom Parser was needed. Done now in v0.1.6 of this module.

Very helpful, thanks! I see the module gives a warning if a tag is created that has the same name as an existing template. Tags added to a template via the core way on the Advanced tab don't give this warning. Is there a catch to watch out for if a tag name is also a template name? Also, it's only a small thing but maybe this module only needs to autoload in the PW admin ("autoload" => "template=admin") rather than for the front-end also.

Hi @bernhard, I gave this module a try to see if it might be a good way to get data for a CSV download (on the front-end). But I'm having trouble getting off the ground. I installed the module, put some demo code in my template file... $rf = new RockFinder2(); $rf->find("id>2, limit=5"); $rf->addColumns([ 'title', 'modified', ]); ...and I get this error: Call to a member function __invoke() on null The same code seems to execute in the Tracy Console in the back-end without an error. Is this module only for use in the PW admin? I had trouble understanding the GitHub readme - are those just notes to yourself? It wasn't clear to me how the SQL examples at the top of the readme relate to the module, and several of the code examples use "new RockFinder()" when this module class is RockFinder2. Update: fixed as per post below

@adrian, there is already a config option for that:

@Jens Martsch - dotnetic, @rjgamer, @teppo, @szabesz, @erikvanberkum, @dragan, @Lutz, @eydun, @psy, @horst, @cstevensjr, @tpr Just tagging in those who have reacted/responded to this topic in order to bring your attention to the notice above. Please don't uninstall but update to v0.2.1 or greater ASAP. Again, my apologies for the error. The intention was to have the module clean up after itself on uninstall but it's just too risky.

IMPORTANT NOTICE TO ALL USERS OF THIS MODULE! I just discovered that the uninstall routine in v0.2.0 can inadvertently delete directories that it shouldn't depending on the module configuration. If you have v0.2.0 installed please DO NOT UNINSTALL but instead update the module to the recently released v0.2.1 as soon as possible. The module can be safely uninstalled from v0.2.1 or higher. To update the module, visit the module config page, expand the Module Information section and click "check for updates". I apologise for this error.

This maybe? if(!isset($options['findAll'])) $options['findAll'] = true; https://processwire.com/api/ref/pages/find/ findAll (boolean): Find all pages with no exclusions, same as "include=all" option (default=false).

Not really. Could you explain why you want to do this? Rather than modifying asmSelect.js and needing to make changes to the Connect Page Fields module I think it might be better to adapt to how PW handles the sorting of newly added pages by default and reverse the sort order of the Page Reference field when you get it via the API. Example:

There's nothing in the core dependent selects feature that dictates how you organise your pages. A parent/child relationship to define categories and subcategories is just one that suits many scenarios, and if I understand right it's the way that was specified in the original question. The thing that determines how it works is this: So you can use "page.page_reference_field_name" in the selector string setting for the dependent field in any way that suits you. You could have all your subcategories under one parent and connect them with one or more categories using a "category" page reference field in the subcategory template. Then the selector string for the subcategory field could include "category=page.category" to limit the subcategories according to what is selected in the category field on the currently edited page. AsmSelect works with the core dependent selects, but it certainly would be nice if the range of compatible inputfield types could be expanded.

I just tested this by creating a new template named "_test" and the stub file was created normally. I can't think of any reason why a template name starting with an underscore would behave differently with this module. It's common to create a file named "_main.php" that is auto-appended to template files if you are using a delayed output strategy, but in that case the file does not correspond to any PW template. Maybe that's the case for you. Are you sure you actually have a template named "_main" in Setup > Templates?

It does, it's just not documented unfortunately. I linked to information about it in my earlier post above. Here is a demo... Page structure: Field settings for subcategory field: "page.category" will be replaced with the ID of the page selected in the Category inputfield in Page Edit, whenever that field changes. The "has_parent" part is just to avoid unwanted pages appearing in the Subcategory inputfield if the Category inputfield is changed to empty (no page selected). Result:

Yeah, makes me wonder if it would have been better if the Pages::trashed method was called immediately before saving the trashed page rather than after. Maybe Ryan has a good reason for doing it that way. I still think it's better to hook after Pages::trashed if you want to know for sure which pages are trashed because when hooking Pages::trash there are still instances where the trashing can fail. For example, there might be another Pages::trash hook in a module that deliberately prevents trashing of particular pages. If you hook Pages::trashed you can parse the parent page ID (and some other info) from the name of the page in the trash: $pages->addHookAfter('trashed', function(HookEvent $event) { $page = $event->arguments(0); $pages = $event->object; /* @var PagesTrash $trasher */ $trasher = $pages->trasher(); $name_info = $trasher->parseTrashPageName($page->name); if(!empty($name_info['parent_id'])) { $parent = $pages($name_info['parent_id']); // ... } });

An alternative is to use $files->render($filename). See the documentation about where the file is allowed to be. $emailBody = $files->render('/path/to/emailbody.inc');