Robin S

@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/

FYI, you can view all the template access overrides for a field on the Overrides tab of Edit Field.

I think it is out of scope for this module, but it sounds like a useful thing to have in a separate module. I'll add it to my list of things to do.

If the issue is incorrect password then LRP normally shows a failure message, but I'm not seeing any notice at all, the form just reloads. FYI, for the backend login form you have to substitute the @ in your email address with an underscore.

I started experiencing the same thing a week or so ago and emailed @ryan about it. He wasn't able to reproduce the problem, but the only way I was able to log in to the modules directory was via the backend login form (best if I don't post the URL for that publicly). Now I'm getting reports of a similar issue on one of my own sites that uses LoginRegisterPro, but I'm not able to reproduce it when I try the LRP login form. My suspicion is that it's a problem with CSRF validation, as if I deliberately tamper with the CSRF token I get the same behaviour of the form reloading with no failure notification. This makes me think a couple of things: 1. LoginRegisterPro should give the user some feedback in this situation, if only to help the developer diagnose the cause. 2. PW should log CSRF validation failures, or at least have an option to log them.

Show Image Custom Field Errors Makes custom fields for images visible when there is an error, e.g. empty required fields. Purpose Image fields have three view modes: square grid, proportional grid, and vertical list. In square grid and proportional grid modes only the thumbnail is visible and custom fields for an image are hidden until the thumbnail is clicked. This can cause an issue when any of the custom fields is an error state (e.g. a required field that has been left empty) because the relevant field will not be visible in the Page Edit interface, making it more difficult for the user to locate the field that needs attention. The Show Image Custom Field Errors module forces image fields into vertical list mode when there is an error in a custom field. When the error is resolved the image field is returned to the view mode that was in use before the error occurred. https://github.com/Toutouwai/ShowImageCustomFieldErrors https://processwire.com/modules/show-image-custom-field-errors/

Hi @ryan, This new version of WireRequestBlocker has a breaking change relative to the previous version in that it now requires PHP >= v8, due to the use of str_starts_with(). Because pro modules are not upgradable via the PW admin users don't see notices about requirements before upgrading (and the PHP 8 requirement isn't stated in getModuleInfo() in any case). Could you please highlight the PHP 8 requirement somehow, or change the code so it has the same requirements as previous versions of the module? Thanks.

@Stefanowitsch asked about using the File Mover module with a "media library" page that is accessed via a modal. I thought I would share some hook code publicly in case it's useful for others too. // Add a button to file and image fields to open a media library page in a modal // Hook InputfieldFile::render to affect file and image fields, // or InputfieldImage::render to affect only image fields $wire->addHookAfter('InputfieldFile::render', function(HookEvent $event) { $inputfield = $event->object; // The field associated with the inputfield (if any) $field = $inputfield->hasField; // The page containing the inputfield (if any) $page = $inputfield->hasPage; // Don't add the button to fields on the media library page // as we don't want the possibility of nested modals if($page && $page->template == 'media_library') return; // You can also check the field name if the button should only be added to a specific field, e.g. // if($field && $field->name !== 'article_images') return; // Get the media library page $media_library = $event->wire()->pages->get("template=media_library"); // Construct the URL to edit the media library page $url = $media_library->editUrl; // Add &modal=1 so the admin header isn't shown $url .= '&modal=1'; // We don't need other tabs or fields besides the image/file field(s), // so specify the field name(s) in the URL // Unfortunately there is this layout bug: https://github.com/processwire/processwire-issues/issues/1972 $url .= '&field=images,files'; /** @var InputfieldButton $f */ $f = $event->wire()->modules->get('InputfieldButton'); $f->href = $url; $f->value = 'Open media library'; $f->icon = 'picture-o'; // Add pw-modal class so the button link opens in a modal $f->addClass('pw-modal'); // Make it a large modal $f->addClass('pw-modal-large'); // Add a bit of space above the button $f->attr('style', 'margin-top: 10px;'); // Append the rendered button to the inputfield $event->return .= $f->render(); });

@biber, you could of course create several different images fields with different sets of custom fields. But if there's an advantage to you of just dealing with a single images field then in your custom fields setup add all the different fields (ingredients, places, etc) you need across all the different templates the field is added to (recipe, plant, etc). Then you can use the Custom Inputfield Dependencies module to only show certain fields depending on the template of the page that's open in Page Edit.

It's working for me, so might have been a temporary outage at the modules directory. Or if it's a recurring issue for you please add some more detailed steps to reproduce on a clean installation.

Thanks for the module! Just wondering about the name. Maybe it should be RockDaemon, or is that an intentional misspelling?

I wasn't sure if this module would be of much general interest but Teppo has mentioned it a couple of times in recent issues of PW Weekly so I'm adding it to the modules directory and creating a support topic for it. Page Action: Include File A generic action for Lister Pro allowing the selection of a PHP file containing the action code. This can be useful for quickly applying API processing to pages without going to the trouble of creating a custom Page Action module for the purpose. Large quantities of pages can be processed thanks to Lister Pro's feature that splits the pages into chunks. Usage The module creates a folder at /site/templates/PageActionIncludeFile/ on install. Place your PHP files inside this folder. Within each file, the $item variable refers to the page that is currently being processed. There is no need to save the page within your code because Lister Pro does this automatically. Example action file: append_foo_to_page_title.php <?php namespace ProcessWire; /** @var Page $item */ // Append " foo" to page title $item->title .= " foo"; Enable the PageActionIncludeFile action in the config of one or more Lister Pro instances. In the Lister Pro instance, set the filters or select the pages as needed and then choose the "Include File" action. Use the select field to choose a file you have added to /site/templates/PageActionIncludeFile/. Click "Execute" to apply the action. https://github.com/Toutouwai/PageActionIncludeFile https://processwire.com/modules/page-action-include-file/

@AAD Web Team, the issue of if PW is not doing something it should isn't something we can resolve in the forum as it's a question for Ryan and he doesn't routinely read all topics. To get an answer on that you'll need to raise an issue in the Issues or Requests repos, depending on if you think it's a bug or rather a feature you would like to have. But to solve your immediate problem you can use the hookable method I mentioned. You use whatever custom code you have to get a username back from the supplied email address and then use that with the supplied password to attempt a login. $wire->addHookBefore('ProcessLogin::loginFailed', function(HookEvent $event) { $session = $event->wire()->session; $username_or_email = $event->arguments(0); // Maybe return early if not dealing with an email address if(strpos($username_or_email, '@') === false) return; // Dummy function indicating where you get the username from an email address using your custom code $username = getUsernameFromEmail($username_or_email); $password = $event->wire()->input->post('login_pass'); $u = $session->login($username, $password); if($u) { // Login was successful for the given username and password // Redirect to admin $session->redirect($event->wire()->config->urls->admin); } });

You could hook ProcessLogin::loginFailed()

I'm surprised a textarea field value can be null rather than an empty string. Maybe something to do with multi-language. I'm casting $text to string in v0.1.3 so hopefully fixed. Thanks for the report.

Good idea, I've done that in v0.1.2

@adrian, I've added most of your requests in v0.1.1. But not the colour-coding because the results don't fall into universal good or bad categories - it depends on the intended audience, e.g. you would expect a high grade level on a website for an academic journal.

Text Readability A module that uses the PHP Text Statistics class to evaluate the readability of English text in textarea fields according to various tests. The available readability tests are: Flesch Kincaid Reading Ease Flesch Kincaid Grade Level Gunning Fog Index SMOG Index Automated Reability Index Spache Readability Score Dale Chall Readability Score Coleman Liau Index The results of the enabled tests are displayed at the bottom of textarea fields – either when the "book" header icon is clicked, or at all times, depending on the option selected in the module configuration. An interpretive tooltip appears when you hover any of the result values. Requires ProcessWire >= 3.0.246 and PHP >= 7.2.0 Why is readability important? Readable.com says: And: The Wikipedia article on readability has useful information too. Module configuration Select which readability tests you want to enable. For each test there is an "about" link to information about the test. Select whether the results of the enabled readability tests should be shown only when the header action icon is clicked (default), or if the results should always be shown. For multi-language sites, select which ProcessWire language represents English (as the tests are only intended for English text). Advanced If you want to disable the readability test results for a particular textarea field you can hook TextReadability::allowReadabilityResults. Example: $wire->addHookAfter('TextReadability::allowReadabilityResults', function(HookEvent $event) { $field = $event->arguments(0); $page = $event->arguments(1); // Disable readability results for the "body" field on the "home" page if($field->name === 'body' && $page->template == 'home') $event->return = false; }); https://github.com/Toutouwai/TextReadability https://processwire.com/modules/text-readability/

Have you looked at this module? https://processwire.com/modules/wire-mail-gmail/

Which approach to take depends on where you want the added markup to appear, relative to things like description and notes. Demo: $wire->addHookBefore('InputfieldText::render', function(HookEvent $event) { /** @var InputfieldText $inputfield */ $inputfield = $event->object; if($inputfield->name !== 'text_1') return; $inputfield->prependMarkup('<div>prependMarkup</div>'); $inputfield->appendMarkup('<div>appendMarkup</div>'); }); $wire->addHookAfter('InputfieldText::render', function(HookEvent $event) { /** @var InputfieldText $inputfield */ $inputfield = $event->object; if($inputfield->name !== 'text_1') return; $event->return = '<div>before render</div>' . $event->return . '<div>after render</div>'; }); Related request: https://github.com/processwire/processwire-requests/issues/536

@Morphosis, the value of a populated "single" Page Reference field... ...is a Page object. So it's redundant to get the ID of the Page Reference field value and then get the Page object from the ID, because you already have the Page object. So you probably want something like this: // If the Page Reference field is populated (i.e. its value is not a NullPage having an ID of zero) // and there are some images uploaded to the selected page if($page->gallery_cta_source->id && $page->gallery_cta_source->gallery_images->count) { // Then output the images foreach($page->gallery_cta_source->gallery_images as $image) { // ... } }