Robin S

Thanks @ukyo. I'm now thinking that the module itself should remove the XML declaration when setting the svg property in the formatted value, seeing as the most likely use would be for inline SVG. Do you agree? If so I'll release an update.

@d'Hinnisdaël, I was curious about organising a PageArray into a hierarchy, so here is some hook code for modifying a normal InputfieldCheckboxes (when used with a Page Reference field) that you could experiment with. $wire->addHookBefore('InputfieldCheckboxes::render', function(HookEvent $event) { /** @var InputfieldCheckboxes */ $inputfield = $event->object; $field = $inputfield->hasField; if(!$field || $field->name !== 'YOUR_FIELD_NAME') return; function buildHierarchy($pagearray) { // Organise pages by their parent ID and collect all IDs $grouped = []; $itemsById = []; $allIds = []; foreach($pagearray as $page) { $itemsById[$page->id] = $page; $allIds[$page->id] = true; $grouped[$page->parent->id][] = $page; } // Find orphaned parents - parent IDs that don't exist in the PageArray $orphanedParents = []; foreach($grouped as $parentId => $items) { if($parentId !== null && !isset($allIds[$parentId])) { $orphanedParents[] = $parentId; } } // Recursive function to build children function buildChildren($parentId, &$grouped, &$itemsById) { if(!isset($grouped[$parentId])) { return []; } $children = []; foreach($grouped[$parentId] as $item) { $node = clone $item; // Not using "children" as the property name here to avoid clashing with native property $node->nodeChildren = buildChildren($item->id, $grouped, $itemsById); $children[] = $node; } return $children; } // Build trees for all orphaned parents $hierarchy = []; foreach($orphanedParents as $parentId) { $hierarchy = array_merge($hierarchy, buildChildren($parentId, $grouped, $itemsById)); } return $hierarchy; } function renderCheckboxesList($items, $inputfield) { $out = "<div class='nested-checkboxes-list'>"; foreach($items as $item) { $label = $item->getFormatted('title'); $checked = ''; if($inputfield->isOptionSelected($item->id)) $checked = " checked='checked'"; $out .= "<div class='nested-checkboxes-item'><label><input$checked type='checkbox' name='{$inputfield->name}[]' value='{$item->id}' class='uk-checkbox'><span class='pw-no-select'>$label</span></label>"; if($item->nodeChildren) $out .= renderCheckboxesList($item->nodeChildren, $inputfield); $out .= "</div>"; } $out .= "</div>"; return $out; } $options = $inputfield->getOptions(); $optionIdsString = implode('|', array_keys($options)); $selectable = $event->wire()->pages->find("id=$optionIdsString, sort=parent.sort, sort=sort"); $hierarchy = buildHierarchy($selectable); $out = renderCheckboxesList($hierarchy, $inputfield); $out .= <<<EOT <style> .nested-checkboxes-list:not(.InputfieldCheckboxes > .nested-checkboxes-list) { padding-left:25px; } .nested-checkboxes-item input { margin-right:0.5em; } </style> EOT; $event->replace = true; $event->return = $out; }); Before: After: There's no JavaScript (I'll leave that to you), but in any case you would likely need to use PHP logic to set the selection state of parent items on Pages::saveReady() or else the field value would get out of whack any time an option was set via the API rather than via the inputfield. That's why having the parents/grandparents in the field value is something that can't really be handled by a module that is an inputfield only and is probably best done in custom code that's specific to your project.

Thanks! Sorry, no, the exclusion of the grandparents and parents from the Page Reference field value is baked in. What you're describing would need to be handled by a different module.

@ryan, could you please take another look at this breaking change before releasing the next master: https://github.com/processwire/processwire-issues/issues/2157 I have modules that break when updating to the most recent PW version.

Iconify Icon A bundle of fieldtype, inputfield, and admin helper modules for searching and displaying Iconify icons. Over 200,000 open source vector icons are available for selection. Requires the FileValidatorSvgSanitizer module. Be sure to abide by the license terms of any icons you use. The license of each icon set is viewable on the Iconify website. Fieldtype and inputfield modules When the FieldtypeIconifyIcon and InputfieldIconifyIcon modules are installed you can create a field of type IconifyIcon. Field config options Iconify icon set prefixes: In most cases you will want to define one or more icon set prefixes for the field, to limit the search to those particular icon sets. This is because the number of icons available through Iconify vastly exceeds the maximum of 999 results that can be returned via the Iconify search API. You can find the prefix of an icon set from its URL by browsing at https://icon-sets.iconify.design/. For example, the prefix of the icon set browsable at https://icon-sets.iconify.design/mdi/ is "mdi". Enter the icon set prefixes into the config field separated by commas. Icon preview size: Enter a width/height in pixels for the preview of the selected icon if you want to override the default. Using the inputfield Type an icon name (or part of an icon name) into the search input and a list of matching icons will be displayed. You can hover on an icon in the results to see the set prefix and name of the icon. Click on an icon to select it. If you have not defined any icon set prefixes in the field config then you can limit the search to particular icon sets by entering icon set prefixes into the search input before a colon. For example, entering "mingcute,tabler:flower" would search for icons with "flower" in their name from the "mingcute" and "tabler" icon sets. When the page is saved the selected icon is downloaded from Iconify, sanitized via the FileValidatorSvgSanitizer module, and stored within the /site/assets/iconify/ directory. Icons are not automatically deleted from this directory if they are no longer used in a page value, but if you want to clean up this directory at any point you can delete it and icons will be automatically re-downloaded when they are next needed. The field value The formatted value of a IconifyIcon field is a WireData object with the following properties: set: The icon set prefix name: The icon name path: The path to the icon file url: The URL to the icon file svg: The SVG code of the icon raw: The raw icon value that is stored in the database For example, if your icon field was named "icon" and you were outputting the src attribute of an <img> tag, you would use $page->icon->url. Or if you were outputting inline SVG code you would use $page->icon->svg. The unformatted value of a IconifyIcon field is the raw database value. Normally you won't need to deal with the raw value when using the inputfield, but if you want to use the API to set a field value then the format of the raw value is iconify--[icon set prefix]--[icon name]. Example: iconify--mingcute--flower-line. Example of object properties: Using Iconify icons in the ProcessWire admin Installing the AdminIconifyIcon module allows you to use Iconify icons as field, template or page icons in the ProcessWire admin. Icons used in the ProcessWire admin are monochrome so any colours or shades in selected icons will not be preserved. Module config You can define icon set prefixes and the icon preview size in the module config. These settings are applied to the inputfields used to set Iconify icons for fields and templates. Field and template icons An "Iconify icon" field is added to the Edit Field and Edit Template screens. When this field is populated it overrides any selection in the core "Icon" field and this field is hidden. Page icons To use an Iconify icon as a page icon for admin pages in the ProcessWire menus, create a IconifyIcon field named "page_icon" and add it to the "admin" system template. For any page using the admin template (e.g. a page representing a Lister Pro instance), open it in Page Edit and select an icon in the "page_icon" field. An example of a "Countries" Lister Pro instance with an Iconify icon: https://github.com/Toutouwai/FieldtypeIconifyIcon https://processwire.com/modules/fieldtype-iconify-icon/

@Kiwi Chris, check that you are loading your URL segment with a trailing slash. If you're using the "nav" item in the module info your URLs should have the trailing slash like shown the ProcessHello demo module: https://github.com/ryancramerdesign/ProcessHello/blob/189029f494870760107d8a621dfb5a59db53959c/ProcessHello.info.php#L55-L77

It's working for me. public function ___executeFoo() { $lister = $this->wire()->modules->get('ProcessPageLister'); return $lister->execute(); } Maybe check your browser console for JS errors, or start with a minimal example like the one above.

The core issue is not fixed as it still constitutes a breaking change. I'm not going to change a before hook to an after hook as they have different effects. If you need to use this module you'll have to stay on a PW <= 3.0.252 until the core issue is resolved.

@DrQuincy, for the image field that you want everyone to be able to view you should enable access control and grant view access to guest. It's normal for the folder to have the hyphen prefix - that is how PW knows to manage access control for the files on that page via PHP rather than allowing direct file access. If you've given view access to a role for a files/images field then PW will take care of serving the files to that role even though the URL (deliberately) does not match the real file path. If by any chance you are using the Delayed Image Variations module you'll need to upgrade to v0.1.6 to get support for secure Pagefiles.

Thanks for the suggestion @BitPoet. But these config settings are for fields using the Fieldtype (and stored in the "fields" table) rather than part of the module config (stored in the "modules" table). I did get to the bottom of why the problem exists and how to work around it: You would think that when setting a default value you could check if the config setting is null (or not part of the data array for the Field) - if it's null then it means it's never been set, and if it's an empty string then it means the user has deliberately cleared the value. But saving a field goes via WireSaveableItems::save() -> WireSaveableItems::encodeData() -> wireEncodeJSON(), and the last is used without $allowEmpty set to true. So any empty value is removed from the saved data and therefore the setting will be null rather than an empty string. I saw a solution in FieldtypeText::saveFieldReady(). In your Fieldtype module you do this to check if a Field is newly created and if so set any default config values: /** * Hook called when field is about to be saved * * @param Field $field * @since 3.0.212 */ public function ___saveFieldReady(Field $field) { parent::___saveFieldReady($field); // If the field is new (it has no ID) and is being saved in ProcessField... if(!$field->id && $this->wire()->page->process == 'ProcessField') { // Set some default field config values $field->set('myFieldtypeConfigSetting', 'foo'); // ... } } This method is only available in PW >= 3.0.212 so I guess prior to that you only had the unappealing option of creating an additional autoload module bundled with your Fieldtype module and hooking Fields::save().

In a Fieldtype module you can define config inputfields for a field that uses the Fieldtype in the ___getConfigInputfields($field) method. The saved values become properties of the Field object ($field). But how do you set a default value for a config inputfield in a way that doesn't prevent the user from clearing the default and leaving the inputfield empty? It's the first time I've had this need and I can't work out how to do it. I looked at the core Fieldtype modules but I couldn't find one that applies a default value that is allowed to be cleared. A simple module to explain it more clearly: <?php namespace ProcessWire; class FieldtypeTest extends FieldtypeText { public static function getModuleInfo() { return array( 'title' => 'Test Fieldtype', 'summary' => 'Test default config values.', 'version' => '0.1.0', ); } /** * Config inputfields * * @param Field $field * @return InputfieldWrapper */ public function ___getConfigInputfields(Field $field) { $inputfields = parent::___getConfigInputfields($field); /* * How can I set a default value for "greeting" in a way that * doesn't prevent the user from saving an empty value? * * The below doesn't work because it will apply the default value * when the user has attempted to clear it. * * */ if(is_null($field->get('greeting'))) $field->set('greeting', 'Hello'); $f = $this->wire()->modules->get('InputfieldText'); $f->label = 'Greeting'; $f->attr('name', 'greeting'); $f->attr('value', $field->get('greeting')); $inputfields->add($f); return $inputfields; } } Does anyone know the right way to do this? Maybe @ryan has a suggestion? Thanks in advance.

Nested Checkboxes An inputfield for Page Reference fields that groups options by their parent page, and optionally by grandparent page too. This can help editors understand the grouping of the selectable pages, and also makes it quicker for an editor to select or unselect an entire group of pages. The checkboxes at the parent and grandparent level are not for storing those pages in the field value - only for quickly selecting or unselecting groups of pages at the lowest level of the hierarchy. For example, in the screen recording above the "Cities" Page Reference field allows only pages with the "city" template, and the pages at the country and continent level are not included in the field value. The inputfield is only for use with Page Reference fields because the structure comes from the page tree. Requires PW >= v3.0.248. Configuration For each field that uses the inputfield you have these options: Checkboxes structure: choose "Parents" or "Parents and grandparents". Collapse sections that contain no checked checkboxes: this option makes the inputfield more compact. There are also the standard column width and column quantity options familiar from the InputfieldCheckboxes inputfield. These apply to the selectable pages at the lowest level of the hierarchy, and the structure is arguably more readable when these are left at their defaults. https://github.com/Toutouwai/InputfieldNestedCheckboxes https://processwire.com/modules/inputfield-nested-checkboxes/

@DrQuincy, responding to the title of the topic: PW allows for access control at the field level as well as the template level. I don't think you need to do anything special with repeaters or child pages to achieve what you're describing. In your template settings: Do you want to manage view and edit access for pages using this template? > Yes Allow view access for "guest", seeing as you generally want the page to be viewable by everyone. Prevent direct access to file assets owned by pages using this template? > Yes always, regardless of page status or access control In the fields listing for the template, click to edit the files field in template context. Enable access control for the field and remove view access for "guest" (and any other roles who are not allowed to view the files). Now guest users will be able to view the page, but not access the files.

@Ivan Gretsky, see here for how to render a page with URL segments:

@PWaddict, this is due to a breaking change in the core, which I think has been done by mistake. I've opened a GitHub issue for it here: https://github.com/processwire/processwire-issues/issues/2157

@ottogal, my suggestion is to delete the /site/modules/FormBuilder/ folder and everything inside it. It's not the ideal way to uninstall a module but PW will handle it okay. This should stop any fatal errors and then you'll be able to log in and do a Modules > Refresh. There will probably be some FormBuilder-related items on the "Missing" tab of the Modules section. For any item listed on this tab, click on it and then choose the "Remove this module from the database?" option.

@taotoo, I've released v0.3.8 which appends the field name in square brackets after the field label.

@Jonathan Lahijani, I've released a new module that provides an overview of field access settings:

Field Access A Process module that provides an overview of field access settings, including template overrides. Usage The table has a sticky header so that the columns can be understood when the table is scrolled. The empty space underneath the table is to allow scrolling to the bottom of the table. There are fields for filtering the table by field name or by template name. The field names link to the Access tab of the field settings, and the template names link to edit the access settings for the field in the context of that template. A collapsed field at the top of the page has information about the meaning of the table column headers, and tips for understanding the values in the table: Table column headers Control: Is access control enabled for this field? View: Roles that can view the field Edit: Roles that can edit the field Show: Show field in page editor if viewable but not editable (user can see but not change) API: Make field value accessible from API even if not viewable Overrides: Overrides of the field access settings in template context Tips If the guest role has view access then it means that all roles have view access. You can hover the guest role in the View column to see a tooltip with all the role names if you want a reminder of those. Overrides: when access control is enabled as a template override, the Control, View, Edit, Show and API columns only display settings that are different from the field access settings. If a column is empty it means the field access setting applies. https://github.com/Toutouwai/ProcessFieldAccess https://processwire.com/modules/process-field-access/

Thanks for reporting this @BrendonKoz. It should be fixed in v0.1.4

@adrian, it might be something that only happens with particularly complex modules, because I think I've added the namespace to a bunch of my earlier modules and never struck that problem. And if I test with a dummy module... <?php class TestModule extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Test Module', 'summary' => 'Test applying namespace', 'version' => '0.1.0', 'autoload' => true, ); } public function ready() { $this->addHookAfter('AdminTheme::getExtraMarkup', $this, 'doSomething'); } protected function doSomething(HookEvent $event) { $parts = $event->return; $parts['masthead'] .= "hello"; $event->return = $parts; } } ...then I can add the namespace without issue. If I remove the namespace from a namespaced module then I get a server error, but that's not something anyone would need to do. Just a guess, but you could try removing the previously compiled module files from /site/assets/cache/FileCompiler/site/ in the upgrade() method to see if that makes a difference.

Great post, thanks @ryan. I remember you saying somewhere that when hooking a $pages method it is more efficient to add the hook to the API variable. So better to do this... $pages->addHookAfter('saveReady', function(HookEvent $event) { // ... }); ...than... $wire->addHookAfter('Pages::saveReady', function(HookEvent $event) { // ... }); Is that still true? And if so, is it just the $pages variable that the advice applies to or is it broader than that?

Maybe one of these?

This is an inputfield module I made as a replacement for InputfieldPageListSelect, due to frustration with it not opening the page structure to the currently selected page. Please note the requirement of ProcessWire >= v3.0.248 when using it as an inputfield for a Page Reference field due to this now fixed core issue. The module doesn't make the PW version a strict requirement in case you just want to replace instances of InputfieldPageListSelect via the bundled ReplacePageListSelect module. Page Tree Select An inputfield for selecting a single page from the page tree. This inputfield is similar to the core InputfieldPageListSelect, but it has the following advantages: It automatically expands the tree to the currently selected page. This avoids having to drill down through the tree when you want to change the selection to a sibling or child of the currently selected page. This was the primary motivation for creating the module. It's faster to navigate through because the whole tree is rendered at once rather than branch by branch. It provides a filter feature to locate pages by title anywhere in the tree. When the tree is filtered you can hover a page title to see the breadcrumb path to the page in a tooltip. It provides buttons to clear the current selection, to restore a changed selection, and to scroll to the selected page. Configuration The following config options are available when using the module as an inputfield for a Page Reference field: Exclude admin pages: excludes pages from the tree that have the admin template (only affects superusers who can otherwise see pages with this template). Exclude pages by template: pages having any of the templates you select here will be excluded from the tree. Descendants of any excluded pages are also excluded. Limit for total pages in the tree: this limit is applied to the selector that finds pages for the tree (default is 5000). Limitations and considerations Performance seems to be reasonable when the tree consists of up to 5000 pages. Your mileage may vary and the module may not be suitable for sites with a very large number of pages (unless excluding pages by template in the inputfield configuration). Pages in the tree show their titles rather than any custom setting defined for the template "List of fields to display in the admin Page List". Page titles are only shown in the default language. The module does not reproduce some of the quirks/features of ProcessPageList such as excluding pages that are hidden and non-editable, and forcing the sort position of special pages like Admin and Trash. ProcessWire >= v3.0.248 is needed for the inputfield to appear as an option in Add Field due to this now fixed core issue. Replacing InputfieldPageListSelect in the ProcessWire admin An autoload module named ReplacePageListSelect is bundled with InputfieldPageTreeSelect. Install the module if you would like to replace all instances of InputfieldPageListSelect in the ProcessWire admin with InputfieldPageTreeSelect. For advanced use cases there are two hookable methods: ReplacePageListSelect::allowReplacement($inputfield): set the event return to false to disable replacement on particular instances of InputfieldPageListSelect. ReplacePageListSelect::getPageTreeSelect($inputfield): set excludeAdminPages, excludeTemplates and limitTotalPages properties on the event return InputfieldPageTreeSelect object when replacing particular instances of InputfieldPageListSelect. https://github.com/Toutouwai/InputfieldPageTreeSelect https://processwire.com/modules/inputfield-page-tree-select/

Image Hotspots Allows a Repeater field to be used to define hotspots on an image. Being able to add multiple fields of any type to the Repeater provides flexibility for the information you can store for a hotspot. Setup 1. Install the module. Two decimal fields will automatically be created on install: hotspot_x and hotspot_y. You can set custom hotspot and highlight colours in the module config if needed. 2. Create a "single" image field (i.e. maximum number of files = 1) that you will use store the image that will have hotspots defined on it. Add this field to a template. 3. Create a Repeater field and add the hotspot_x and hotspot_y fields to the Repeater. Add any other fields you need to store information about the hotspots you will create. Save the Repeater field. 4. In the "Details" tab of the Repeater field, expand the "Image Hotspots" section (this section appears for any Repeater field that has the hotspot_x and hotspot_y fields). For "Image field", select the image field you created in step 2. The "Image height" setting defines the maximum height of the image when displayed in Page Edit. 5. Add the Repeater field to the template you added the image field to in step 2. Usage in Page Edit When an image has been saved to the image field, the Repeater field will display a preview of the image at the top of the field. Click "Add New" to create a new hotspot. The hotspot appears at the top left of the image initially and can be moved by clicking and dragging it to the desired location on the image. The X/Y coordinates of the hotspot will be automatically updated as the hotspot is moved. For precise adjustments you can modify the X/Y coordinates directly and the hotspot position will be updated. To identify which Repeater item corresponds to a given hotspot, click on the hotspot. The corresponding Repeater item header will receive an orange outline. Click the hotspot again to remove the orange outline. To identify which hotspot corresponds to a given Repeater item, expand the Repeater item and focus either the X or Y coordinate fields. The corresponding hotspot will be highlighted in orange. On the frontend It's up to you to display the hotspots on the frontend in any way you need. The values of the hotspot_x and hotspot_y fields are percentages so when given absolution positioning over the image your hotspot markers can preserve their positions as the image scales up or down in a responsive layout. https://github.com/Toutouwai/ImageHotspots https://processwire.com/modules/image-hotspots/