Leaderboard

The latest version on the dev branch will actually get the version bump tomorrow, as I'm currently on a 7-day work schedule with shorter days (factors outside my control). So what I'd usually be doing Friday is happening Saturday or Sunday instead. But the updates in 3.0.176 are well enough defined to write about here, and everything is there already, it's primarily just additional testing that remains before the version bump. Relative to 3.0.175 version 3.0.176 contains about 25 commits or so with most of the focus being resolution of minor issue reports. However, 25 commits is a lot so there are also some new things here too. First off, as requested, PW now supports multiple database read-only configuration settings rather than just one. When more than one is present, it will select one randomly. To use multiple read-only connections, simply specify a regular PHP array of 2 or more associative arrays in your /site/config.php file, like this: $config->dbReader = [ [ 'host' => 'mydb1.domain.com' ], [ 'host' => 'mydb2.domain.com' ], [ 'host' => 'mydb3.domain.com' ], ]; In each array item, you can specify 'host' (as above), along with any other setting (name, user, pass, port, etc.) that differs from the primary DB connection. There's another benefit to having multiple dbReader hosts as well: If the connection for one fails, it'll move on to the next, and keep moving on till it either finds a working connection or finishes the list. Next up, ProcessTemplate (Setup > Templates) gained a "Manage Tags" feature just like the one you have in ProcessField (Setup > Fields). So now it's a lot easier than before to define and manage tags for multiple templates as a group. In addition to this, both ProcessField and ProcessTemplate now have an actual Tags field (like the one available for files/images) rather than just a plain text input. The Template class also gained several new API functions for working with tags on templates. Templates in PW have supported tags for a long time, but now they are backed up by a much better API and admin interface to them. In order to support the new tags inputs in ProcessTemplate and ProcessField, a Tags Inputfield module was developed, named InputfieldTextTags (the name InputfieldTags was already taken). This module is now in the core, and it uses the existing Selectize tags functionality already present in the core, but previously only used by file and image fields. While developing this, I found it was a nice alternative to AsmSelect for sortable multiple selection, so made it available as an additional input option for both Page and Options fields. When used in a multiple-selection context, it ends up being a multiple selection input that takes up no more space than a text input, which can be quite handy for a lot of situations, and more space friendly then AsmSelect or even PageAutocomplete. I've noticed travel websites using a similar solution for multiple selection of destinations or amenities in search forms, and perhaps this one has some front-end potential as well. Since it's just an Inputfield without a dedicated Fieldtype, it is likely to work just as well on front-end forms (like FormBuilder) as it does on admin forms. Longer term I imagine we'll have an optional FieldtypeTextTags module as well, which will be useful for supporting user-entered tags sharable between pages. Currently it does support user entered tags if you choose it as an input option for a regular "text" field (see bottom of Details tab in field editor), and it can optionally be combined with predefined selectable tags as well. While all of these updates are on the dev branch now, look for the version bump this weekend after I've had a little more time testing. Though if you'd like to help test, feel free to grab it now. Thanks for reading and have a great weekend!

There's no overhead to pages that is worth worrying about. In my opinion Page Reference fields are a better choice than Select Options fields in 90% of cases - they're more powerful, flexible and future-proof. They're very easy to set up thanks to @adrian's wonderful Page Field Select Creator module. And they do what you're wanting out of the box - via the core "Allow new pages to be created from field?" setting, or via Page Field Edit Links if your referenced pages evolve to contain multiple fields and you want to fill those out as new pages/options are created.

wire()->addHookAfter('FieldtypeOptions::markupValue', function($e){ $page = $e->arguments(0); $e->return = $page->select_options_field->id; });

I've been meaning to revise PageimageSrcset for a while now, to remove some features that I felt were unnecessary and to implement a better rendering strategy. The result is PageimageSource. What does it do? It provides a configurable srcset method/property for Pageimage It allows WebP to be enabled for images it generates. It allows Pageimage:render() to return a <picture> element It provides a Textformatter that replaces <img> elements with the output of Pageimage:render() Although it is based on a current module, this should still be considered beta and not used in production without a prior development stage. Here's the README: PageimageSource Extends Pageimage with a srcset property/method plus additional rendering options. Overview The main purpose of this module is to make srcset implementation as simple as possible in your template code. For an introduction to srcset, please read this Mozilla article about responsive images. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.165 and PHP >= 7.3 are required to use this module. Configuration To configure this module, go to Modules > Configure > PageimageSource. Default Set Rules These are the default set rules that will be used when none are specified, e.g. when calling the property: $image->srcset. Each set rule should be entered on a new line, in the format {width}x{height} {inherentwidth}w|{resolution}x. Not all arguments are required - you will probably find that specifying the width is sufficient for most cases. Here's a few examples of valid set rules and the sets they generate: Set Rule Set Generated Arguments Used 320 image.320x0-srcset.jpg 320w {width} 480x540 image.480x540-srcset.jpg 480w {width}x{height} 640x480 768w image.640x480-srcset.jpg 768w {width}x{height} {inherentwidth}w 2048 2x image.2048x0-srcset.jpg 2x {width} {resolution}x How you configure your rules is dependent on the needs of the site you are developing; there are no prescriptive rules that will meet the needs of most situations. This article gives a good overview of some of the things to consider. When you save your rules, a preview of the sets generated and an equivalent method call will be displayed to the right. Invalid rules will not be used, and you will be notified of this. WebP If enabled, WebP versions of the image and srcset variations will be generated and these will be returned by Pageimage::srcset(). As with the default implementation, the image with the smaller file size is returned. In most cases this is the WebP version, but sometimes can be the source. Make sure to experiment with the quality setting to find a value you find suitable. The default value of 90 is fine, but it is possible that lower values will give you excellent kB savings with little change in overall quality. For more information on WebP implementation please read the blog posts on the ProcessWire website. Rendering These settings control how the output of Pageimage::render() is modified. Use Lazy Loading? When enabled this adds loading="lazy" to the <img> attributes. It is useful to have this on by default, and you can always override it in the options for a specific image. Use the <picture> element? When enabled, the <img> element is wrapped in a <picture> element and <source> elements for original and WebP variations are provided. This requires WebP to be enabled. For more information on what this does, have a look at the examples in Pageimage::render() below. Remove Variations If checked, the image variations generated by this module are cleared on Submit. On large sites, this may take a while. It makes sense to run this after you have made changes to the set rules. Please note that although the module will generate WebP versions of all images if enabled, it will only remove the variations with the 'srcset' suffix. Usage Pageimage::srcset() // The property, which uses the set rules in the module configuration $srcset = $image->srcset; // A method call, using a set rules string // Delimiting with a newline (\n) would also work, but not as readable $srcset = $image->srcset('320, 480, 640x480 768w, 1240, 2048 2x'); // The same as above but using an indexed/sequential array $srcset = $image->srcset([ '320', '480', '640x480 768w', '1240', '2048 2x', ]); // The same as above but using an associative array // No rule checking is performed $srcset = $image->srcset([ '320w' => [320], '480w' => [480], '768w' => [640, 480], '1240w' => [1240], '2x' => [2048], ]); // The set rules above are a demonstration, not a recommendation! Image variations are only created for set rules which require a smaller image than the Pageimage itself. This may still result in a lot of images being generated. If you have limited storage, please use this module wisely. Pageimage::render() This module extends the options available to this method with: srcset: When the module is installed, this will always be added, unless set to false. Any values in the formats described above can be passed. sizes: If no sizes are specified, a default of 100vw is assumed. lazy: Pass true to add loading=lazy, otherwise false to disable if enabled in the module configuration. picture: Pass true to use the <picture> element, otherwise false to disable if enabled in the module configuration. Please refer to the API Reference for more information about this method. // Render an image using the default set rules // WebP and lazy loading are enabled, and example output is given for <picture> disabled and enabled echo $image->render(); // <img src='image.webp' alt='' srcset='image.jpg...' sizes='100vw' loading='lazy'> /* <picture> <source srcset="image.webp..." sizes="100vw" type="image/webp"> <source srcset="image.jpg..." sizes="100vw" type="image/jpeg"> <img src="image.jpg" alt="" loading="lazy"> </picture> */ // Render an image using custom set rules echo $image->render(['srcset' => '480, 1240x640']); // <img src='image.webp' alt='' srcset='image.480x0-srcset.webp 480w, image.1240x640-srcset.webp 1240w' sizes='100vw' loading='lazy'> /* <picture> <source srcset="image.480x0-srcset.webp 480w, image.1240x640-srcset.webp 1240w" sizes="100vw" type="image/webp"> <source srcset="image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w" sizes="100vw" type="image/jpeg"> <img src="image.jpg" alt="" loading="lazy"> </picture> */ // Render an image using custom set rules and sizes // Also use the `markup` argument // Also disable lazy loading // In this example the original jpg is smaller than the webp version echo $image->render('<img class="image" src="{url}" alt="Image">', [ 'srcset' => '480, 1240', 'sizes' => '(min-width: 1240px) 50vw', 'lazy' => false, ]); // <img class='image' src='image.jpg' alt='Image' srcset='image.480x0-srcset.webp 480w, image.1240x0-srcset.webp 1240w' sizes='(min-width: 1240px) 50vw'> /* <picture> <source srcset="image.480x0-srcset.webp 480w, image.1240x0-srcset.webp 1240w" sizes="(min-width: 1240px) 50vw" type="image/webp"> <source srcset="image.480x0-srcset.jpg 480w, image.1240x0-srcset.jpg 1240w" sizes="(min-width: 1240px) 50vw" type="image/jpeg"> <img class='image' src='image.jpg' alt='Image'> </picture> */ // Render an image using custom set rules and sizes // These rules will render 'portrait' versions of the image for tablet and mobile // Note the advanced use of the `srcset` option passing both `rules` and image `options` // WebP is disabled // Picture is disabled echo $image->render([ 'srcset' => [ 'rules' => '320x569, 640x1138, 768x1365, 1024, 1366, 1600, 1920', 'options' => [ 'upscaling' => true, 'hidpi' => true, ], ], 'sizes' => '(orientation: portrait) and (max-width: 640px) 50vw', 'picture' => false, ]); // <img src='image.jpg' alt='' srcset='image.320x569-srcset-hidpi.jpg 320w, image.640x1138-srcset-hidpi.jpg 640w, image.768x1365-srcset-hidpi.jpg 768w, image.1024x0-srcset-hidpi.jpg 1024w, image.1366x0-srcset-hidpi.jpg 1366w, image.1600x0-srcset-hidpi.jpg 1600w, image.jpg 1920w' sizes='(orientation: portrait) and (max-width: 768px) 50vw' loading="lazy"> TextformatterPageimageSource Bundled with this module is a Textformatter largely based on TextformatterWebpImages by Ryan Cramer. When applied to a field, it searches for <img> elements and replaces them with the default output of Pageimage::render() for each image/image variation. Assuming a default set of 480, 960 and lazy loading enabled, here are some examples of what would be returned: Example <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.jpg" width="300" /> </a> </figure> WebP enabled <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.webp" width="300" srcset="/site/assets/files/1/example.300x0-is-hidpi.webp 480w" sizes="100vw" loading="lazy" /> </a> </figure> <picture> enabled <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <picture> <source srcset="/site/assets/files/1/example.300x0-is-hidpi.webp 480w" sizes="100vw" type="image/webp"> <source srcset="/site/assets/files/1/example.300x0-is-hidpi.jpg 480w" sizes="100vw" type="image/jpeg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.jpg" width="300" loading="lazy" /> </picture> </a> </figure> Because the variation is small - 300px wide - the srcset only returns the source image variation at the lowest set width (480w). If the source image was > 1000px wide, there would be a variation at both 480w and 960w. PageimageSrcset This module is built upon work done for PageimageSrcset, which can be considered a first iteration of this module, and is now deprecated. Migration PageimageSource is a simplified version of PageimageSrcset with a different approach to rendering. Most of the features of the old module have been removed. If you were just using $image->srcset(), migration should be possible, as this functionality is essentially the same albeit with some improvements to image variation generation.

Kerim Pamuk https://www.kerimpamuk.de/ Client details Kerim Pamuk a turkish/german author and cabaret artist with such a kind of detailed humor for details you have to listen very closely and think twice to really appreciate his Wortspiele (en: puns) and anecdotes. Some more details about Kerim Pamuk (one of our first clients with a personal Wikipedia page): https://de.wikipedia.org/wiki/Kerim_Pamuk Design details As you can see... Bright colors, big typo, and subtle animations to emphasize the already bold visual statement. No miss but a lot of hits wherever you watch, like the stage program performed by Kerim Pamuk himself. The original design and the entire frontend were built in Webflow by the designer but was migrated over to ProcessWire later on. Some tweaks were made during the migration process to keep things a bit more flexible and easier to maintain on the long run. Technical details There is not that much in the backend to show or tell. Only a few tweaks and hooks in order to maintain all events automatically. Adding additional press statements, books or any other kind of content is simple and straightforward as always in ProcessWire. Modules used: Cookie Management Banner: for the obvious reason FieldtypeColor: for custom colors on sub-pages if needed PageHitCounter: as alternative to Google Analytics and Matomo ImportPagesfromCSV: importing new events to the site with ease (maintained by the client) Markup Sitemap XML: you know why Jumplinks: in case things change or someone needs a nice pretty link ProCache (Pro): ProcessWire is fast - with ProCache even faster VerifiedURL (Pro): to keep track of all linked event locations The team behind this: Muskaat for the technical part (yes, I'm part of Muskaat) https://www.muskaat.de/ Polimorf for the design part https://www.polimorf.de/ I hope you'll enjoy this site as much as I do!

This week I didn't get as much time as I'd hoped to work on the core, but still managed to get a few things done. I did get some small core updates in place, but not enough for a version bump, and got the second covid vaccine, kids back to in-person school (3 hours a day, after a year of being away), and a couple more major module upgrades released. In last week's post, someone asked for an update to the ProcessWireUpgrade module, and I had a look and a realized it was long overdue for one, so I tried to cover a lot of ground there. The new version is now out and improved throughout. Grab this latest version of ProcessWireUpgrade if you are interested. It's always been pretty useful, but it's even more so now. I've also updated the modules directory feed so that it can let you know when Pro module upgrades are available as well (as requested). The ProcessWireUpgrade module reports this Pro module information in a clear manner too. Some improvements have also been made to the core version updating features as well. The other module updated was FieldtypeEvents, a module that demonstrates how to create simple a Fieldtype+Inputfield module pair that has repeatable rows of multiple columns. The last version was made for PW 2.x, so I largely rewrote the module while updating it for PW 3.x. It's been simplified quite a bit so that it can be even more clear how to adapt it to create your own custom module. Being PW 3.x exclusive also opened more doors in keeping it simple but powerful. If you don't mind doing a little customization in adapting the code for your purposes, this module can be every bit as powerful in solving custom needs as Repeaters, but without Repeater overhead. I updated this module because another ProcessWire user was asking about how to store multiple columns of repeatable data for 20-million pages. Repeaters would be too much overhead at that scale, though FieldtypeTable could fit the bill. But at such a large scale, I thought a custom Fieldtype would be even better. So FieldtypeEvents shows you how to do it, and it's [hopefully] simpler than you might think. This has nothing to do with PW, but to follow up from last week, that second dose of the covid vaccine was an interesting experience. I got the shot (jab?) and strangely didn't feel a thing. I walked home and took the band-aid off my arm and noticed there was no sign of anything, no little pin prick or red spot, and a completely clean band-aid. I started to wonder if I'd been fooled or something. If someone sticks a needle in your arm, you should feel it right? And there should be some evidence of it? Well there wasn't (and no I didn't watch the needle, who would do that?). They also told me I'd feel ill for a day or two, and I felt completely fine even the next morning. But then 10 am rolled around and my arm started feeling sore and I was suddenly very tired. So tired that it was laborious to walk, sit at the computer, or do anything other than chill on the couch. That might sound undesirable, but it wasn't uncomfortable, and it was kind of funny being so ridiculously tired, but also really relieved. It meant it was working and my body was getting a download on how to battle covid, and putting all its resources into taking it seriously. It was fascinating, so I just crashed on the couch, relaxed and let it do its thing. By the next day, full energy was back, batteries recharged, upgrades installed. From what I understand, some people have no side effects, but I was one of those that did. Though if anything I enjoyed the different experience for a day, and the comfort of clear evidence it was working.

I went to update a site today, but as soon as I hit the backup databsase button, it shot to 98% CPU. I tried it on another PW site and that did it when I hit the Upgrade link. Any bright ideas what might be causing it? PHP version? (I am on 7.4 and made the change relatively recently.) Something with HTACCESS perhaps that was changed with the last update I did? (I think I updated the Pro-cache module not long back) I tried turning on Debug, but since the site gets stuck, it doesn't cough up anything. And hello to everyone! Joss EDIT The solution or workaround is not to hit the backup button, but to just backup with phpmyadmin (which I do anyway). However, why it is getting stuck, I am not sure. This seems to be less about CPU overload and more about timing out. See my later post with the reply from the host who has been brilliant.

Hi @adrian I'm using BrowserSync in my dev setup with proxying to test domain. So when I run BrowserSync I can access site through mydomain.test:4000 The issue is that after update 4.21.7 => 4.22.2 of TD module, the TD bar doesn't load when I access site with port number and I get an error in the browser console Uncaught SyntaxError: Unexpected end of input When accessing the site without port TB bar loads normaly. Do you have any idea what can cause it?

I have removed all logs and it bar started to load, then I have refreshed modules and again it stopped to load. http://360px.com.ua/monosnap/chrome_nrIfSIDBVh.png That`s all that I have in the logs. Changing mentioned line to any of this version fixes issue $entriesArr[$itemKey]['url'] = json_encode('<a href="' .$entry['url']. '">'.$entry['url'].'</a>'); // or $entriesArr[$itemKey]['url'] = '<a href="\\' .$entry['url']. '">'.$entry['url'].'</a>'; // or $entriesArr[$itemKey]['url'] = "<a href='".$entry['url']."'>".$entry['url']."</a>";

@adrian I have tracked it down that if I remove ProcessWire Logs panel from the list of loading panels TB bar loads.

Your provider isn't blocking anything at this point. Editing the files is quite easy. download the module from either processwire.com/modules or the Github page extract the ZIP file to your local machine open up the module files in VS Code or whatever tool you are using add the namespace upload the module try again

Just installed the module BUT I had to add the ProcessWire namespace to the module files. My overall setup is exacyly like yours (3.0.165, 7,4, 2.3.3)

Thanks for the hint @elabx Your code makes ALL options fields available in the Lister columns to display the same values. Here is how I did it: $wire->addHookAfter('FieldtypeOptions::markupValue', function($event) { if($this->process != 'ProcessPageLister') return; $field = $event->arguments(1); $value = $event->arguments(2); if($field == "my_options_field") { $event->return = $value->value; } });

Truly amazing. For how I work, probably one of the greatest additions to my PW toolkit. Thank you!

I am not aware of such a field. Go with Page Reference. It is not really an overhead - you really need to store data somewhere, so why not in pages? And if working in PW you use pages as "everything is a page"), remember ))

Hi Phillip – I'm so incredibly sorry for neglecting this. I noted in the merge requests that I'd get to it, and then never did. I'm going to go ahead and accept both and release, however I have no reliable way to test without configuring dev-environments for it. So if there are any issues, we can deal with them on an as-and-when-needed basis. Edit: Managed to test. Very strange. Seems like something that would need to be fixed in the underlying package. Updating to v6.6 now as part of the above merge request at least. ?

This is probably the "right" way to do it: https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/config.php#L1274-L1280 Also note that most / all WireMail modules have their own settings for this as well which is where I typically set it.

Or a simple hook to modify the page edit form ? <?php $wire->addHookAfter("ProcessPageEdit::buildFormContent", function($event) { $page = $event->process->getPage(); if($page->template != 'yourtemplate') return; $form = $event->return; $f = $this->wire(new InputfieldMarkup()); $f->label = 'Help'; $f->icon = 'picture-o'; $f->value = "<img src='https://via.placeholder.com/350x150'>"; $form->insertAfter($f, $form->get('title')); });

v0.0.6 allows page selectors that result in multiple levels. The use of “sort=path” is permitted in selectors, even though this normally has no effect. If it is used, the pages will be sorted in parent-child order, using the ‘natural’ sort order (e.g. XYZ100 is greater than XYZ20). This means that parents should be installed before children. For ‘removed’ pages, the order is reversed so that children are deleted before parents.

The only thing I can see at this time is the word "remote". Any time you venture outside the loopback (127.0.0.1), all sorts of external factors come into play; dns lookup, hop latency, etc. I'm not suggesting that is where the problem lies, just that more areas are opened up to check this issue. Do you (or any of your team) experience this delay via SSH, SCP, SFTP, etc.? Is there noticeable improvement at different times of the day? Any firewall in place? Can you tail your network to see if it jives with Tracy's database request listing? I'm just thinkin' out loud.

I just stumbled across this video, and wasn't sure if it found its way here already. It's a very different take than the tutorials that were available when I was first trying to learn ProcessWire, and I think something like this might have been helpful for me. Trying out ProcessWire (Part 1) [YouTube]