Leaderboard

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.

I would kindly ask you @bernhard to consider making the setting for remBase a config setting. Background: Not all people use a framework like Uikit for their frontend output when it comes to CSS. I adopted a best practice from Css-Tricks(RIP ?) a few years ago and still roll with it. Font-sizes are easier to spot You note in your CSS: html {font-size: 62.5%;}/* set scale for the document */ body {font-size:1.6rem;} /* this makes 1.6rem 16px, 2rem 20px, and so on... rem sizes are easier to read that way */ But... that doesn't play well with the fixed setting in RockFrontend.module.php (line 165) $this->remBase = 16; // default base for px-->rem conversion When working with rfGrow all values are now way to small, like 80px are calculated as 50px... In order for me to work I had to edit the value to 10. What do you think?

This week the core dev branch version has been bumped to 3.0.231. There are about 15 commits in this version relative to the previous. In the dev branch commit log you'll find a good mix of issue fixes and improvements. If you are already using the dev branch, this version is worth the upgrade. If using the main/master branch then it should be a safe upgrade as well, though none of the updates are urgent. And it won't be long till they are also merged to the main/master branch soon too. This week I've also been working on 2 new related modules: FieldtypeDateRange and InputfieldDateRange. These modules allow selection of starting and ending dates to support a date range. It also calculates and stores the number of days and nights for querying and sorting purposes. The "date from" and "date to" can be independently queried from $pages->find(), as can the days or nights. The InputfieldDateRange module can be used independently of its companion Fieldtype module, making it possible to use the date range Inputfield in FormBuilder or other Inputfield forms. One context where the Inputfield might be useful is when selecting travel dates on a front-end form, such as one from FormBuilder. When used as a Fieldtype, you might use it to specify availability of something, start and end dates to publish content, event dates, or any number of other use cases. Below is a screenshot of the Inputfield as well as its configuration tab. The JS-based input widget comes from an existing package that I've made some modifications to, and it works really nicely, with a polished and easy-to-use UI. I originally found it booking some travel online, and really liked the way it worked. I was able to track it down on GitHub here and thought it would be useful to build an Inputfield module around it. It can be set up to work like the core date picker where it appears when you focus in the input, or it can be configured "inline" where it is alway s visible (and the related text input is hidden). In the following screenshot, I've specified that Sundays can't be used for start/end selections and that November 23 is not available. The selected range spans two months. If you want it to span more months, you could click the right arrow in the December calendar to find your desired month, leaving the first calendar in November. In this manner, you can select ranges that span multiple months, or even years: Here's the Inputfield configuration screen so far. All of these settings are hookable as well, as some of them are more likely to be useful dynamically, especially min/max start and end dates, non-selectable dates, etc. (Note the screenshot below does not necessarily reflect the settings in the screenshots above). More on this next week. Have a great weekend!

Hey @Klenkes sure, I can make everything configurable that needs to be configurable ? Could you please explain the issue in detail so that I better understand? Could you please provide a step by step example?

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))]; }); }); });

PageImage::removeVariations takes an associative array of options as its argument, which in turn is passed on to PageImageVariations::remove and PageImageVariations::find. The docs for the latter say (irrelevant parts snipped): /** * @param array $options Optional, one or more options in an associative array of the following: * - `width` (int): only variations with given width will be returned * - `height` (int): only variations with given height will be returned * - `width>=` (int): only variations with width greater than or equal to given will be returned * - `height>=` (int): only variations with height greater than or equal to given will be returned * - `width<=` (int): only variations with width less than or equal to given will be returned * - `height<=` (int): only variations with height less than or equal to given will be returned * - `suffix` (string): only variations having the given suffix will be returned * - `suffixes` (array): only variations having one of the given suffixes will be returned * - `noSuffix` (string): exclude variations having this suffix * - `noSuffixes` (array): exclude variations having any of these suffixes * - `name` (string): only variations containing this text in filename will be returned (case insensitive) * - `noName` (string): only variations NOT containing this text in filename will be returned (case insensitive) * - `regexName` (string): only variations that match this PCRE regex will be returned */ So ["width" => "201"] should work (untested though).

It does if you pass a filter function to the beforeShowDay option, though I haven't found a way to set that without modifying InputfieldDatetime.js.

@bernhard Since it has a Fieldtype the ability to query it from selectors comes baked in. Though it uses the terms "date from" and "date to" rather than "starts" and "ends". Each are MySQL DATE (not DATETIME) columns, so time isn't a factor. Days and nights will also queryable from selectors. I've not yet added a custom getMatchQuery() method to the Fieldtype, but I think most of the examples you mentioned may even be possible with it using the one inherited from the base Fieldtype class, but I've not tested that far yet. I'm planning to add a custom getMatchQuery() method either way for the days/nights support, so may tweak it further too. @PavelRadvan The disabled days or days of week would be possible. Though if this is for restaurant reservations, I'm not sure that a date range is what you'd need, unless a reservation spans more than one day? Plus, aren't reservations about time as much as date? (There's no time selection in date range). Since it would likely be just one day, I'm thinking the regular/core FieldtypeDatetime/InputfieldDatetime is probably better, plus it also supports time. It uses the jQuery UI datepicker, though I don't think that one supports disabled days. In any case, you could always use a hook or JS to alert the user when they've selected a day that reservations aren't allowed on. If you want to explore it more post in the FormBuilder board and let's see what's possible. @BitPoet I wasn't thrilled with that label either. I converted all (or most) of the JS library's config settings to a PW settings screen and used the descriptions from the JS library in some cases, at least to start. I don't yet fully understand what that option does, so was going to figure it out and then come up with a better label/description.

Related tutorial is located here:

Hey @ryan that looks great! Are you also planning to add an API to select pages matching a date range? That would be great, because when working with date ranges the INPUT is only one part of the equation. May I ask you to have a look at this thread? https://processwire.com/talk/topic/23097-previewdiscussion-rockdaterange-fieldtype-inputfield-to-easily-pick-daterange-or-timerange/ It shows what I came up with some time ago. I didn't proceed with the module, but some parts of selecting pages where quite promising: <?php // find events in 2023 (meaning from 2023-01-01 00:00:00 to 2023-12-31 23:59:59) $pages->find("template=event, my_range=2023"); // find events in taking place in 2023-11 (meaning from 2023-11-01 00:00:00 to 2023-11-30 23:59:59) // this would also find an event starting in 2023-10 lasting to 2023-12 $pages->find("template=event, my_range=2023-11"); // find events in taking place in 2023-11-17 (meaning from 2023-11-17 00:00:00 to 2023-11-17 23:59:59) $pages->find("template=event, my_range=2023-11-17"); // find events starting after 2023-11-17 00:00:00 $pages->find("template=event, my_range.starts >= 2023-11-17"); // find events ending before 2023-11-17 00:00:00 $pages->find("template=event, my_range.ends < 2023-11-17"); Not sure how/if that works when dealing with different timezones, but for my use case it was of great help to have this easy human readable API, because when using timestamps it quickly get's complicated and prone to errors (like forgetting to use <= instead of < or such): <?php // find events taking place in 2023-11 $from = strtotime("2023-11-01"); $to = strtotime("2023-12-01"); $pages->find("template=event, my_range.starts >= $from, my_range.ends < $to"); That example is actually not working, because for real world queries you'd need to take more possibilities into account: So if 2023-11 starts at the first black line and ends at the second, then you'd need this query to find events that take place in 2023-11: // find events that either // start within 2023-11 (meaning start after or at 2023-11-01 00:00:00 and start before 2023-12-01 00:00:00) // or end within 2023-11 (meaning end after or at 2023-11-01 00:00:00 and end before 2023-12-01 00:00:00) // or start before 2023-11-01 00:00:00 and end after or at 2023-12-01 00:00:00 That shows that it quickly gets very complicated and you need to be really careful with all the times and comparison operators! IMHO using the other syntax makes code a lot easier to read and maintain. For my use case (showing events in a calendar) it was a lot easier to use this syntax, because you don't have to find the timestamps of the first second of the month and the last second of the month or the first second of the next month etc.; You just use "range=2023-11" and that's it.

When writing API code I often refer to the PW admin to get particular page IDs or field names. And when I'm writing client instructions I often need to insert the labels of particular fields. To make this quicker and more convenient I added some custom JavaScript to the PW admin that copies these things to the clipboard on Alt + click and Ctrl + click. The Page List item and inputfield header are briefly highlighted in yellow to signify that the copying has occurred. This is tested in Windows and I'm not sure if the Alt key / Ctrl key detection is the same for other operating systems but you could adjust the key detection as needed. In /site/ready.php // Add custom JS file to $config->scripts FilenameArray // This adds the custom JS fairly early in the FilenameArray which allows for stopping // event propagation so clicks on InputfieldHeader do not also expand/collapse InputfieldContent $wire->addHookBefore('ProcessController::execute', function(HookEvent $event) { // Optional: for superuser only if(!$event->wire()->user->isSuperuser()) return; $config = $event->wire()->config; $modified = filemtime($config->paths->templates . 'admin-assets/copy-on-click.js'); $js_url = $config->urls->templates . "admin-assets/copy-on-click.js?m=$modified"; $config->scripts->add($js_url); }); In /site/templates/admin-assets/copy-on-click.js $(document).ready(function() { // Copy a string to the clipboard function copyToClipboard(string) { const $temp = $('<input type="text" value="' + string + '">'); $('body').append($temp); $temp.select(); document.execCommand('copy'); $temp.remove(); } // Copy page ID when Page List row is Alt + clicked $(document).on('click', '.PageListItem', function(event) { if(event.altKey) { const classes = $(this).attr('class').split(' '); for(const item of classes) { if(item.startsWith('PageListID')) { const id = item.replace('PageListID', ''); copyToClipboard(id); $(this).effect('highlight', {}, 500); break; } } } }); // When InputfieldHeader is clicked $(document).on('click', '.InputfieldHeader', function(event) { let text = ''; // If Alt + clicked then copy the input name the label is for, or the ID as a fallback if(event.altKey) { event.preventDefault(); event.stopImmediatePropagation(); text = $(this).attr('for'); if(!text) text = $(this).parent().attr('id'); text = text.replace(/^Inputfield_|wrap_Inputfield_|wrap_/, '').trim(); } // If Ctrl + clicked then copy the label text else if(event.ctrlKey) { event.preventDefault(); event.stopImmediatePropagation(); text = $(this).text().trim(); // If AdminOnSteroids is installed use the below instead to exclude text within the AOS field edit link // text = $(this).clone().find('.aos_EditField').remove().end().text().trim(); } if(text) { copyToClipboard(text); $(this).effect('highlight', {}, 500); } }); }); Demo (using the Tracy console only as a convenient place to paste into for demonstration): Copying the field label is useful for getting the name of config fields too, for when you need them in your API code.

ProcessWire automatically sanitises the names of files that are uploaded to a Files field. For example, a file named "Café meals under $30.pdf" will become "cafe_meals_under_30.pdf" after it is uploaded. Since v3.0.212 ProcessWire stores the original unsanitised filename of each uploaded file, and this is accessible via $pagefile->uploadName https://processwire.com/blog/posts/pw-3.0.226/#file-and-image-improvements https://processwire.com/api/ref/pagefile/upload-name/ So if I have a field named "files" on my page and I want to provide downloads of the files with their original filename I can output links like this: $out = ''; foreach($page->files as $file) { // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); $out .= "<p><a href='$file->url' download='$original_name_unencoded'>$file->uploadName</a></p>"; } echo $out; So far, so good. But I want my site visitors to be able to view PDFs in the browser rather than force a download, yet if they do download them after viewing them I want the files to get the original filename. For this I can use a URL hook to deliver the PDF via PHP rather than directly loading the file. In /site/ready.php: $wire->addHook('/view-pdf/{page_id}/{filename}', function($event) { $id = (int) $event->page_id; $filename = $event->wire()->sanitizer->text($event->filename); if(!$id || !$filename) return 'Invalid request'; // Get the Pagefile via PagefilesManager $pm = $event->wire()->pages->get($id)->filesManager; $file = $pm->getFile($filename); if(!$file) return 'File not found'; // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); // Set headers and output the PDF content header("Content-Type: application/pdf"); header("Content-Disposition: inline; filename=$original_name_unencoded"); header("Content-Transfer-Encoding: binary"); header("Accept-Ranges: bytes"); @readfile($file->filename); return true; }); In the page template file: $out = ''; foreach($page->files as $file) { if($file->ext === 'pdf') { // Deliver PDF files via the URL hook $out .= "<p><a href='/view-pdf/$page->id/$file->basename'>$file->uploadName</a></p>"; } else { // Other files receive a download attribute // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); $out .= "<p><a href='$file->url' download='$original_name_unencoded'>$file->uploadName</a></p>"; } } echo $out;

Sometimes you need to execute a slow task after some event occurs in the PW admin, and normally you have to wait for this task to finish before you can continue using the admin. This is because PHP is "blocking", meaning that while one thing is executing nothing else can execute. There are potentially lots of different kinds of tasks that could be slow, but just as an example suppose you want to generate resized variations of images on a page, and there are a lot of images. You might have a hook like this so that any non-existing variations are created when the page is saved: $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Create an image variation for each image foreach($page->images as $image) { $image->size(1200, 1200); } } }); When you save a gallery page in the PW admin, the admin will be unresponsive and will only load again after all the variations have been created. I wanted to find a way for slow tasks to be triggered by events in the PW admin and for the website editor not to have to wait for the task to finish before continuing with other work in the admin. Inspired by this StackOverflow answer I came up with the following solution that seems to work well. Using the image variations task above as an example... First we make use of the URL hooks feature to set up a URL that can trigger tasks to run when it is loaded: // A URL that will trigger tasks when loaded $wire->addHook('/run-task/', function($event) { $input = $event->wire()->input; // A simple check to avoid unauthorised access // You could implement more advanced checks if needed if($input->post('key') !== 'cTdPMBQ7x8b7') return false; // Allow the script to keep running even though we have set a short WireHttp timeout ignore_user_abort(true); // The "create variations" task if($input->post('task') === 'create-variations') { $page_id = (int) $input->post('page'); $p = $event->wire()->pages->get($page_id); // Create an image variation for each image foreach($p->images as $image) { $image->size(1200, 1200); } return true; } return false; }); Then in the Pages::saveReady hook we use WireHttp to load that URL and post parameters that define what task to run and anything else needed for the task (in this case the ID of the page that has been saved). $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Load the /run-task/ URL using WireHttp $http = new WireHttp(); // Set a short timeout so we don't have to wait until the script finishes // Timeout values shorter than 1 second can be tried once a core issue is fixed // https://github.com/processwire/processwire-issues/issues/1773 $http->setTimeout(1); $url = $event->wire()->config->urls->httpRoot . 'run-task/'; $data = [ 'key' => 'cTdPMBQ7x8b7', 'task' => 'create-variations', 'page' => $page->id, ]; $http->post($url, $data, ['use' => 'curl']); } }); By doing it this way the task runs in a separate request and the website editor doesn't have to wait for it to finish before they can continue working in the PW admin.

When a blog post article receives many comments ? your start to consider to apply pagination to comments. Looking around this forum, I found some useful hints, but I couldn't find how to take full advantage of PW built-in pagination. In particular the ukBlogPosts() function in Uikit 3 Site/Blog Profile renders a list of paginated posts. ukBlogPosts() is calling a ukPagination() function which permits to navigate the posts. ? After some unsuccessful attempts to use it with CommentArray … ? I decided to insist. ? And here is the result. The ukPagination() function in _uikit.php expects an argument $items of type PageArray. Of course a CommentArray ... is not a PageArray ... ? so we have to remove this blocking point. Going deeper inside the function you will notice that pagination is achieved through a call to a render() method of MarkupPagerNav. Let's look at its declaration: public function ___render(WirePaginatable $items, $options = array()) Interesting ? here $items are declared of type WirePaginatable. What's that? ? a class? No! It's an interface! ? Looking around further I discovered that WirePaginatable interface is used by PageArray, PaginatedArray, and CommentArray.. bingo! ?? We got what to do first, modify ukPagination() function in _uikit.php changing $items argument type from PageArray to WirePaginatable: //function ukPagination(PageArray $items, $options = array()) { function ukPagination(WirePaginatable $items, $options = array()) { //>>>>> REPLACE WITH THIS LINE Now the function accepts our CommentArray as argument, but to make it work we need to set its Limit, Start, and Total attributes as PW does automatically when dealing with pages. In order to do that we will use the WirePaginatable methods setLimit(), setStart(), setTotal(). In this process our Start attribute will have to be calculated dynamically to consider the page number when navigating the comments. To do that we will largely ? modify the function ukComments() in _uikit.php: function ukComments(CommentArray $comments, $options = array()) { if(!$comments->count) { //>>>>>NEW-start if(input()->pageNum > 1) { // redirect to first pagination if accessed at an out-of-bounds pagination session()->redirect(page()->url); } return ''; } //>>>>>NEW-end $defaults = array( 'id' => 'comments', 'paginate' => false, //>>>>>NEW 'limit' => 3, //>>>>>NEW ); //if(!count($comments)) return ''; $options = _ukMergeOptions($defaults, $options); $language = user()->language->id; //>>>>>NEW $comments = $comments->find("language=$language"); //>>>>>NEW if($options['paginate']) { //>>>>>NEW-start $limit = $options['limit']; $start = (wire()->input->pageNum - 1) * $limit; $total = $comments->count(); $comments = $comments->slice($start, $limit); $comments->setLimit($limit); $comments->setStart($start); $comments->setTotal($total); } //>>>>>NEW-end $out = "<ul id='$options[id]' class='uk-comment-list'>"; foreach($comments as $comment) { $out .= "<li class='uk-margin'>" . ukComment($comment) . "</li>"; } $out .= "</ul>"; if($options['paginate'] && $comments->getTotal() > $comments->count()) { //>>>>>NEW-start $out .= ukPagination($comments); } //>>>>>NEW-end return $out; } As you will notice we have added two options to the function [paginate => false] and [limit => 3]. In such a way the ukComments() function will operate as before. If you wish to use pagination you will have to pass [paginate => true] as argument of the function. Of course you can freely choose the limit value or by pre-setting it in the function or by passing it as an argument to the function. Please note that the modification implements the necessary changes (2 lines) to make comments language-aware as described in the tutorial: We are now just to steps away to see our paginated comments. ? First you will need to enable pagination in the templates where you want comments to be paginated. Login to PW Admin and select your template. In the tab URLs enable the "Allow Page Numbers?" option. Second you will need to modify the associated php template, in our example blog-post.php, to change the call to ukComments() as follows (sorting is not necessary, depends on your preferences): //echo ukComments($comments); echo ukComments($comments->find("sort=-created"), ['paginate' => true]); //>>>>> REPLACE WITH THIS LINE And here we are! Below a snapshot our paginated comments! ??? As you can see on the bottom of the comments you have the standard PW pagination navigator, without being forced to rewrite a new one for the purpose! ? I hope you can find something useful with this tutorial.