Robin S

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) { // ... } }

Assuming that the field would be changed in Page Edit rather than as result of some other API code, you can validate the user input in a hook to InputfieldText::processInput. Example: $wire->addHookBefore('InputfieldText::processInput', function(HookEvent $event) { $inputfield = $event->object; $input = $event->arguments(0); $field = $inputfield->hasField; $page = $inputfield->hasPage; // For a particular field name and template name if($field && $field->name === 'text_1' && $page && $page->template == 'events') { $old_value = $page->getUnformatted('text_1'); // Return early if the old value is empty if(!$old_value) return; $new_value = $input[$inputfield->name]; // If the first three characters have changed if(substr($new_value, 0, 3) !== substr($old_value, 0, 3)) { // Show an error message $inputfield->error('You are not allowed to change the first three characters of the "Text 1" field.'); // Replace the hooked method so the new value won't be saved to the field $event->replace = true; } } });

No, because this module is a helper for the admin interface. Doing bulk operations on a set of pages is what the PW API is for. The key method you would use for this is Pageimages::add(). The basic idea assuming two different pages are involved: // Get the first page in whatever way you like $p_1 = $pages(1234); // Turn off output formatting $p_1->of(false); // Get the image from the image_1 field // The first() method is used because the value of an image field // is always a Pageimages object when output formatting is off $image = $p_1->image_1->first(); // Get the second page in whatever way you like $p_2 = $pages(1235); // Turn off output formatting because you are about to change a field value $p_2->of(false); // Add the image to the image_2 field on the second page // This is an example of Pageimages::add() $p_2->image_2->add($image); // Save the change to the second page $p_2->save('image_2'); // Now perhaps you want to remove the image from the first page? $p_1->image_1->remove($image); $p_1->save('image_1'); If you are copying between two fields on the same page you'll have to work around this issue: https://github.com/processwire/processwire-issues/issues/1863 In FileMover I deal with this by calling Pagefile::install(): https://github.com/Toutouwai/FileMover/blob/0020e365557730e59bad87286548e69f562be0d8/FileMover.module.php#L165-L166 The filename will then be automatically incremented. The incremented filename is something you'll want to consider if anything is linking directly to the image as the link will be broken once you remove the original image. Of course you'll want to test everything carefully in a safe environment before you do any bulk operation on a live site. If it all sounds too difficult or risky, then consider if it's even necessary. Why not just keep two different image fields instead of consolidating them into one?

I'm not sure what the technical reason is for the 404 not being handled from ready.php, but as a workaround you could set a custom property on the $page object to indicate that a 404 should be thrown and then throw the 404 later, e.g. from a template file or from _main.php. // Your conditional in ready.php if($foo === 'bar') $page->throw404 = true; // In template file or _main.php if($page->throw404) wire404();

I'm not aware of anything changing that would make this module redundant, but it will be easy for you to check and find out. When using the Image & File Dependencies module, if your image field is named "image" you would use the selector string: _image>0

@dragan, this module works by hooking into Pageimage::size(), so it's only going to create an AVIF version of images that have been through some Pageimage sizing method.