Robin S

I've been thinking of adding this for a while. Now configurable in v0.3.10

Hear, hear! I love the PW Weekly - a highlight of the week! Putting out such a well-written newsletter week after week for 10 years - what an incredible contribution to the community! Hats off to @teppo! I like to read each new issue when it's hot off the press, which is normally on a Sunday (NZ time), but the official email from newsletter@processwire.com doesn't arrive until the following Saturday. A long while ago I asked Ryan why this is and there was a sensible reason that I've forgotten now, but I can't wait that long for my PW news ?. So my solution has been to set up an email alert for the RSS feed using Blogtrottr - that way I can dive into each issue when it's at maximum freshness ✨?

@bernhard, thanks for the heads-up. The new tab option was working for child items but not for the top level menu items. Fixed in v0.1.5 and in this version I've also added an option to define an icon for the top-level items - these are only visible in the sidebar menu so probably not seen all that often but still good to have control over.

@bernhard, the /site/assets/div-queue/ directory was only used in v0.1.0. From v0.1.1 onwards the queue files are distributed in the same location as the variation files, e.g. /site/assets/files/1234/, and so the /site/assets/div-queue/ directory isn't needed.

The matrix field is likely to be rendered inside a markup region, and so this output would end up as a nested markup region, which isn't supported. See this response to a similar question for how a FilenameArray or WireArray can be a solution:

@howdytom, I think I see where the confusion comes in. In more recent PW versions the require() line in /site/templates/admin.php is... require($config->paths->core . "admin.php"); ...whereas in earlier versions it is... require($config->paths->adminTemplates . 'controller.php'); These both end up doing the same thing so you should only have one require() in the file. The functional part of my code is this bit: // Get the user's IP address $ip = $session->getIP(); // Define the allowed IP addresses $allowed_ips = ['111.111.111.111', '222.222.222.222']; // Check user's IP is allowed if(!in_array($ip, $allowed_ips)) { return 'Access denied'; } I only include the require() line to indicate that my code needs to be inserted above the existing contents of /site/templates/admin.php

There isn't anything in that code that should cause an error in any version of PW. Just a guess, but given that the error message originates from /wire/core/admin.php make sure you have edited /site/templates/admin.php and not /wire/core/admin.php by mistake.

That's possibly a browser cache issue, because the variation filename doesn't change when the quality option changes. This problem is the motivation behind this module: https://processwire.com/modules/unique-image-variations/

Maybe check again because I just tested PageimageRemoveVariations and it removed image variations from repeater pages.

There's an open request for this: https://github.com/processwire/processwire-requests/issues/424

Following on from an earlier tutorial for using $pagefile->uploadName... Tip 1 Suppose your website audience uses a non-latin alphabet and you have a file to upload with a filename like this: (I don't know any Chinese but Google Translate tells me that this is a translation for "my example filename") If this file is uploaded to a PW files field it ends up as shown below because none of the filename characters are allowed. This makes it hard to identify what the file relates to. Since PW 3.0.212 the original filename will be saved to the uploadName property of the Pagefile but it would be nice to improve the actual filename assigned to the file. The hooks below in /site/ready.php make use of the SanitizerEasySlugger module to transliterate the original filename to latin characters that are allowed in a PW files field. // When a file is added to InputfieldFile $wire->addHookAfter('InputfieldFile::fileAdded', function(HookEvent $event) { /** @var Pagefile $pagefile */ $pagefile = $event->arguments(0); // The uploadName property is not available at this point so just flag that the file is new $pagefile->isNewFile = true; }); // When InputfieldFile is processed in Page Edit $wire->addHookAfter('InputfieldFile::processInputFile', function(HookEvent $event) { /** @var Pagefile $pagefile */ $pagefile = $event->arguments(1); // Only for newly added files if(!$pagefile->isNewFile) return; // Only if the uploadName property is different to the basename if($pagefile->uploadName === $pagefile->basename) return; // Divide the upload name into parts $parts = pathinfo($pagefile->uploadName); // Transliterate non-latin characters in the filename using the SanitizerEasySlugger module // https://processwire.com/modules/sanitizer-easy-slugger/ $transliterated = $event->wire()->sanitizer->utf8Slugger($parts['filename']); // Rename the file (renamed file will be visible after the page is saved) $pagefile->rename($transliterated . '.' . $pagefile->ext); }); After saving the page the filename now at least has some connection to the original filename, and this is presumably more useful to a Chinese speaker: Tip 2 When using CKEditor or TinyMCE to link to a file, by default you can only see the sanitized name: But it would be helpful to also see the original filename that has been saved to $pagefile->uploadName. Add the hook below to /site/ready.php: // When the Add Link form is created $wire->addHookAfter('ProcessPageEditLink::buildForm', function(HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->return; // Get the "Select File" select /** @var InputfieldSelect $select */ $select = $form->getChildByName('link_page_file'); // Get an instance of PagefilesManager via the Home page $fm = $event->wire()->pages->get('/')->filesManager(); // For each of the options in the select foreach($select->options as $filename => $label) { if(!$filename) continue; $pagefile = $fm->getFile($filename); if(!$pagefile) continue; // Only if the uploadName is different from the filename if($pagefile->uploadName === $pagefile->basename) continue; // Add the uploadName to the option label $select->replaceOption($filename, $filename, $label . " ($pagefile->uploadName)"); } }); Now the uploadName is appended to the select option label:

One way is to set the option when the datepicker field is focused: $(document).ready(function() { // The days to disable const disabledDays = ['2023-11-27', '2023-11-28']; // When field "date_1" is focused $('#Inputfield_date_1').on('focus', function() { $(this).datepicker('option', 'beforeShowDay', function(date) { return [!disabledDays.includes($.datepicker.formatDate('yy-mm-dd', date))]; }); }); });

Yes, that's mentioned in the readme: I'd say it's not the size of the site that matters but the number of image variations on any particular page. But in any case, if the way variations are created by default in PW is not presenting a problem then you won't need the module.

That's what the code in the first post is for, so I think I don't understand the question. If the PHP file is not being created make sure you have created a "hannas" directory inside /site/templates/

Version 0.1.3 is released. This adds a button to generate all currently queued variations: The readme is also updated to add some important notes about 404 configuration in .htaccess and ProCache configuration.

I made some updates in v0.1.1 so that unprocessed queue files get deleted if the original Pageimage is deleted. That sounds like a simple solution. In v0.1.1 the queue file is just the variation URL with ".txt" at the end. So for a variation that will have a URL "/site/assets/files/1234/myimage.500x500.jpg" once it is created the queue file would be at "/site/assets/files/1234/myimage.500x500.jpg.txt". So in your loadFilesOnDemand() method you could check if DelayedImageVariations is installed and if so check for the existence of the queue file in addition to the variation file. @bernhard, in v0.1.2 I've changed the queue file extension to ".queue" because it will allow me to identify the queue files more efficiently for another feature I have in mind to release soon. So the section in strikethrough above will now be: In v0.1.2 the queue file is just the variation URL with ".queue" at the end. So for a variation that will have a URL "/site/assets/files/1234/myimage.500x500.jpg" once it is created the queue file would be at "/site/assets/files/1234/myimage.500x500.jpg.queue".

Thanks, fixed now.

A module for you guys...

Delayed Image Variations Delays the creation of image variations until their individual URLs are loaded. Image variations being generated one-by-one: Background Normally when you create new image variations in a template file using any of the ProcessWire image resizing methods, all the new variations that are needed on a page will be created from the original Pageimage the next time the page is loaded in a browser. If there are a lot of images on the page then this could take a while, and in some cases the page rendering might exceed your max_execution_time setting for PHP. So you might like to have image variations be generated individually when they are requested rather than all at once. That way the page will render more quickly and the risk of a timeout is all but eliminated. But there can be problems with some implementations of this approach, such as with the (in)famous TimThumb script: It's not ideal to have PHP be involved in serving every image as this is needlessly inefficient compared to serving static assets. It's not good to allow arbitrary image sizes to be generated by varying URL parameters because you might want to restrict the maximum resolution an image is available at (e.g. for copyrighted images). If images are generated from URL parameters a malicious user could potentially generate thousands of images of slightly different dimensions and fill up all your disk space. The Delayed Image Variations module avoids these problems - it creates variations when their URLs are loaded but only allows the specific dimensions you have defined in your code. It does this by saving the settings (width, height and ImageSizer options) of every new Pageimage::size() call to a queue. The module intercepts 404s and if the request is to an image variation that doesn't exist yet but is in the queue it generates the variation and returns the image data. This only happens the first time the image is requested - after that the image exists on disk and gets loaded statically without PHP. Usage In most cases usage is as simple as installing the module, and you don't need to change anything in your existing code. However, there might be some cases where you don't want the creation of a particular image variation to be delayed. For example, if you created a variation in your code and then immediately afterwards you wanted to get information about the variation such as dimensions or filesize. $resized = $page->image->width(600); echo $resized->height; echo $resized->filesize; This wouldn't work because the actual creation of the resized image hasn't happened yet and so that information won't be available. So in these cases you can set a noDelay option to true in your ImageSizer options and Delayed Image Variations will skip over that particular resizing operation. $resized = $page->image->width(600, ['noDelay' => true]); echo $resized->height; echo $resized->filesize; For advanced cases there is also a hookable method that you can return false for if you don't want a delayed variation for any particular resizing operation. Example: $wire->addHookAfter('DelayedImageVariations::allowDelayedVariation', function(HookEvent $event) { /** @var Pageimage $pageimage */ $pageimage = $event->arguments(0); // The Pageimage to be resized $width = $event->arguments(1); // The width supplied to Pageimage::size() $height = $event->arguments(2); // The height supplied to Pageimage::size() $options = $event->arguments(3); // The options supplied to Pageimage::size() // Don't delay variations if the Pageimage belongs to a page with the product template if($pageimage->page->template == 'product') $event->return = false; }); 404 handling For Delayed Image Variations to work your .htaccess file needs to be configured so that ProcessWire handles 404s. This is the default configuration so for most sites no change will be needed. # ----------------------------------------------------------------------------------------------- # 2. ErrorDocument settings: Have ProcessWire handle 404s # # For options and optimizations (O) see: # https://processwire.com/blog/posts/optimizing-404s-in-processwire/ # ----------------------------------------------------------------------------------------------- ErrorDocument 404 /index.php ProCache If you are using ProCache then make sure it is not configured to cache the 404 page or else PHP will not execute on 404s and queued image variations will not be generated. Generate queued variations Before launching a new website you might want to pre-generate all needed image variations, so no visitor will have to experience a delay while a variation is generated. To queue up the image variations needed for your site you will need to visit each page of the website one way or another. You could do this manually for a small site but for larger sites you'll probably want to use a site crawler tool such as Xenu's Link Sleuth. This may generate some image variations but it's likely that some other variations (e.g. within srcset attributes) will not be requested and so will remain queued. To generate all currently queued variations there is a button in the module config: This will search the /site/assets/files/ directory for queue files and render the variations. https://github.com/Toutouwai/DelayedImageVariations https://processwire.com/modules/delayed-image-variations/

Does anyone know of a way to prompt a file download from code that is executed in the Tracy Console panel? When I try things that would normally prompt a download if executed in a template file, such as... header('Content-type: text/csv'); header("Content-Disposition: attachment; filename=myfile.csv"); // ... ...or... $files->send($myfile, ['forceDownload' => true]); ...the output is always sent directly to the Console panel and no download is prompted. No big deal if it's not possible but sometimes it would be handy to export some data or files in the form of a download using the Console panel. Maybe @adrian or anyone else knows a solution for this? Thanks in advance.

Awesome, thanks for creating this @BitPoet! I am going to be locked into CKEditor for the foreseeable future because in addition to my public modules I have a number of private modules that integrate with CKEditor and rebuilding them all for TinyMCE will be a big job. And for the types of sites I work on I don't see many advantages of TinyMCE over CKEditor so I don't have much motivation to do all the rebuilding at the moment - I'll probably get to it eventually but not any time soon. So it's great that HannaCodeDialogTiny is available for anyone who wants to switch to TinyMCE sooner than I do.

Sounds quite specific to your particular use case, but it was easy to support so in v0.1.2 I've added a checkbox in the module config to not show the menu. Thanks for pointing this out - it's now collapsed in v0.1.2 as that info isn't something that non-superusers need to be bothering themselves with. I forget that PW has this open by default because I use the AdminOnSteroids option that automatically collapses it. Too niche to bother with in the module config. It can be translated if needed, either in the core translations for multi-language sites or via wireLangReplacements() in site/ready.php wireLangReplacements([ 'Modules' => ['My menu title', 'LimitedModuleEdit'], ]);

For any future readers of this thread, here is a module for this purpose:

@MarkE, I've released a module that allows non-superusers to configure selected modules, which might be helpful for your current project:

Limited Module Edit Allows non-superusers to edit a limited selection of modules. Of course, there are good reasons why non-superusers are normally not allowed to access the configuration screen of modules so use this module with caution. Usage 1. Install Limited Module Edit. 2. In the module configuration select one or more modules in the "Modules enabled for limited editing" field. When you enable a module here a corresponding "lme" permission is installed. For example, if WireMailSmtp is enabled here then a permissioned named "lme-wire-mail-smtp" will be installed. 3. For any role that you want to allow to configure the previously selected modules, enable the "module-admin" permission and the "lme" permissions for any module they may configure. 4. Users with these permissions will now see a special Modules section in the main menu that provides links to configure only the modules they have been given permission for. These users are not allowed to install modules nor are they allowed to uninstall the modules they have permission to configure. https://github.com/Toutouwai/LimitedModuleEdit https://processwire.com/modules/limited-module-edit/