Robin S

Thanks @adrian, I knew there would be a simple solution. And, thanks @kongondo

Is it possible to define a variable in the place that the hook is attached (e.g. ready.php or a template file) and then access that variable inside the hook function? $animal = 'cat'; $this->addHookAfter('Class::method', function($event) { // is there some way to use $animal here? }); I tried passing the variable as a second argument in the anonymous function but got an error. Missing argument 2 for ProcessWire\ProcessWire::{closure}()

FYI, I released a Limit Repeater module.

FYI, I released a Limit Repeater module.

I'm really enjoying module development in PW. The flexibility that comes from hooks is brilliant. A couple more modules due shortly. An all-time classic.

LimitRepeater Allows restrictions and limits to be placed on Repeater fields. For any Repeater field you can limit the number of items that may be added and also prevent the use of drag-sorting, toggling of published state, and the trashing of items. There is also an option to hide the clone button when the limit is reached. Usage Install the LimitRepeater module. Since v0.2.0 the module settings are configured at Setup > Fields > [your Repeater field]. The settings are contained within the "Restrictions" fieldset on the "Details" tab. Please note that the restrictions limits are applied in Page Edit with CSS/JS so should not be considered tamper-proof. Setting restrictions via a hook Besides setting restrictions in the field settings, you can also apply or modify restrictions by hooking LimitRepeater::checkRestrictions. This allows for more focused restrictions, for example, applying restrictions depending on the template of the page being edited or depending on the role of the user. The checkRestrictions() method receives the following arguments: $field This Repeater field $inputfield This Repeater inputfield $page The page that is open in ProcessPageEdit The method returns an array of restrictions for the Repeater field. An example of a returned array: Example hook Prevent non-superusers from trashing any items in "my_repeater_field": $wire->addHookAfter('LimitRepeater::checkRestrictions', function(HookEvent $event) { $field = $event->arguments('field'); $restrictions = $event->return; if($field->name === 'my_repeater_field' && !$this->user->isSuperuser()) { $restrictions['notrash'] = true; } $event->return = $restrictions; }); Upgrading from < v0.2.0 There are two major changes to be aware of when upgrading from earlier versions of the module. The settings are no longer defined on the module config page, but rather in the field settings of each Repeater field: Setup > Fields > [your Repeater field]. If you visit the module config page you'll find shortcuts to the settings for each Repeater field. In earlier versions you could apply restrictions to a particular role. This is still possible but is now handled by hooking LimitRepeater::checkRestrictions as this is a more flexible and powerful approach. If you were applying restrictions to a particular role or roles you'll need to add hook code to achieve the same effect after you upgrade the module. See the hook information above in this readme. https://github.com/Toutouwai/LimitRepeater http://modules.processwire.com/modules/limit-repeater/

@MaryMatlow, the commented default options in the MarkupSimpleNavigation docs say this... 'list_tpl' => '<li%s>||</li>', // template string for the items. || will contain entries, %s will replaced with class="..." string %s is a placeholder for the dynamic classes such as 'has_children', 'level-n', etc. If you remove the %s placeholder in list_tpl as you have done in your options there is nowhere for the dynamic classes to be inserted. So revert back to the default for list_tpl (and as @Speed said, you only need to set options you are changing from the default). If you want 'dropdown' to be added to the classes of every list item you set this... 'list_field_class' => 'dropdown', ...or if you want it to be added to the classes of only list items that have children you set this... 'has_children_class' => 'has_children dropdown',

Go for it.

This is something I used in a couple of modules recently and it could be useful as a standalone hook. It adds classes to the body tag in the admin theme for: roles the user has if the user is a non-superuser the user's name You could use this if you want to tweak the admin interface for a role using CSS/JS (e.g. with Admin Custom Files). There is also an old wishlist item requesting this. $this->addHookAfter('AdminTheme::getExtraMarkup', function($event) { $theme = $event->object; $user = $this->user; foreach($user->roles as $role) { $theme->addBodyClass("role-{$role->name}"); } if(!$user->isSuperuser()) $theme->addBodyClass("role-nonsuperuser"); $theme->addBodyClass("user-{$user->name}"); });

v0.0.5 released - improved config system (screenshot updated in first post).

v0.0.6 released. PageTables may now be restricted by role (uses CSS/JS so not suitable for mission-critical restrictions) New options to prevent trash, prevent drag sorting, and removal of all "Add" buttons regardless of template. Improved config system (screenshot in first post updated)

@LimeWub, one thing to be aware of is that this will make your module incompatible with PW2.x. But that may not be a problem to you.

Here is a server-side alternative to (or backup for) the JS validation. $this->addHookBefore('ProcessPageAdd::processInput', function($event) { $form = $event->arguments('form'); $input = $this->input; $sanitizer = $this->sanitizer; $template = $sanitizer->int($input->post->template); if($template !== 43) return; // the ID of the template you want to limit page names for $name = $sanitizer->pageName($input->post->_pw_page_name); $parent_id = $sanitizer->int($input->post->parent_id); $uri = $_SERVER['REQUEST_URI']; $blacklist = ['cat', 'dog', 'hamster']; // your blacklist if(in_array($name, $blacklist) ) { $name_field = $form->children->get('_pw_page_name'); $error = "The page name '$name' is reserved. Please choose a different name."; $name_field->error($error); $this->session->redirect("{$uri}?parent_id=$parent_id"); } }); A little awkward but does the job. You could incorporate into a module to get a configurable template selection and name blacklist.

You have more than the event->return available to you in the hook - you have $event->object, which is the inputfield. $this->addHookAfter('InputfieldFile::renderItem', function($event) { $inputfield = $event->object; $files = $inputfield->value; // find file you want in $files });

How is that you have a path to a file (the $filename argument in your function) that exists in a field on a page without any information about the page and field? Where does $filename come from?

@ethfun, if I understand right you would like to validate the page name during the Add Page process. This ought to be possible with a hook to ProcessPageAdd::processInput or InputfieldPageName::processInput, but stuffed if I can get PW to give a field error and return to Add Page; the error is displayed but the page is still added. I thought you could set an error to the inputfield... $my_field->error('That value is not allowed'); ...and the form wouldn't validate but I can't get that work for Add Page. Hopefully someone knows how to do this. BTW, members without a Form Builder license will not be able to read the thread you linked to with the background info. Might be good to include the details here.

That's not the case - I always keep my PageTable items under the Admin branch of the tree and don't have any issues with non-superusers viewing and editing PageTable pages. You just need to make sure: The editor role has edit access (and of course view access) for the template used for the PageTable pages. The editor role has "Add children" access for the template used for the parent page of the PageTable pages. You set this in the "Access" tab of the settings for each template.

The field may not be necessary but I think you'll have to associate the file with a Page (it is called a Pagefile after all). You can do this: $my_files = new Pagefiles($some_page); $my_files->add('/path/to/file.pdf');

Well, it has me stumped. I haven't had or heard of this issue before. I doubt the GitHub issue szabesz linked to is related as that is specific to PageTables added to the user template.

So if you go to those child pages in the tree (not via the PageTable field), can the editor edit those pages? Does the editor role have edit and view permission for the template used by the pages?

Doesn't see them on the front-end or in the admin? Where in the tree are the PageTable pages stored? Are the PageTable pages viewable by editor if you load them directly on the frontend (i.e not via the PageTable field)?

$my_files_field->add('/path/to/file.pdf'); Same for Pageimages, which inherits the methods and properties of Pagefiles. https://processwire.com/api/ref/pagefiles/ https://processwire.com/api/ref/pagefiles/add/

The use cases are the same as those for any inputfield dependency: you want to show or require one field based on the state of another. This module just adds Image and File fields to the types of fields you can use in an inputfield dependency selector. Off the top of my head: you have an images field for an optional gallery and you want to remind the site editor to add a summary/introduction for the gallery if images are added. Also, there was this request for help. @szabesz is right - the screen recorder tool is LICEcap. I discovered it via this post by @bernhard.

All your fields will be added directly to your template - Page fields and other fields. For the Page fields, it is the selectable options for the field that you will create as individual pages elsewhere in the tree. You could put these 'option' pages and their parents directly under the Home page, but I like to group them under a 'Selects' page to separate them from the rest of the site pages. Home Selects Make Toyota Volkswagen ... Color ... A couple of easy ways to create these pages: 1. Use adrian's great Page Field Select Creator module. This is good for when you want to include the ability to add pages (i.e. options for the select) via Pages > Add New because it will create dedicated templates for the option page and the parent page. The module creates the Page field for you. 2. When I don't need the use of the Add New feature and want to avoid unnecessary extra templates I use ImportPagesCSV with the "Paste in CSV Data" option. If all you need is the title then for example you would enter: title Toyota Volkswagen ... With this option you would create the Page field yourself and choose selectable pages, etc.

@szabesz, glad you approve. I have plans for another module relating to inputfield dependencies. Watch this space.