Leaderboard

It's spring break here and my kids are going back to school next week after being out for more than a year. Since it's a break week, the weather is great, and it's also the last week of the year-long covid break from school, I've spent a little less time at the computer this week. I've focused on some smaller module projects rather than the core. More specifically: posted a major update and refactor of the TextformatterHannaCode module, and a completely rewritten TextformatterVideoEmbed module. While making these updates, I've also made note of and attempted to resolve any reported issues in the GitHub repositories. Next week, it's back to the core, with both issue resolutions and pull requests scheduled for upcoming versions. Next week I also get my 2nd shot of covid vaccine, and I'm told it may slow me down a bit for a day, but will be well worth it. I had a day of tiredness from the 1st shot, but it was greatly outweighed by feelings of gratitude and reduction of worry. I highly recommend it as soon as you can get it, if you haven't already.

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.

Thanks. The v0.3.0 update to HannaCode is actually a major refactoring of the module so there were a few things in HannaCodeDialog that needed updating for compatibility. The new v0.4.0 of HannaCodeDialog should be compatible with HannaCode v0.3.0 and it requires HannaCode >= v0.3.0.

Thanks for showing those modules some love Ryan - much appreciated!

@markus_blue_tomato Sorry to hear that, I hope they have it available soon. I figured we'd be the last to get it here because the for-profit healthcare system in the US doesn't often lend itself well to public health, unless you are wealthy. (Just getting a covid test was $400). Luckily it seems the vaccine isn't being handled by the healthcare companies, and it's free. My parents got their vaccine at an appliance store drive-through, my wife got hers at the grocery store, and I got mine at the office of some technology company in our town square. That might sound sketchy but they are all legitimate and it seems to be working well for once.

Please don't spend a lot of time on this. I'll see if I can work it out in the weekend.

@kongondo's FieldtypeRuntimeMarkup can do exactly that. You just need to add a snippet of code to retrieve and output the relevant messages.

Thanks for the tips @horst but I think I am being dumb. I tried with wireHttp and even plain curl with CURLOPT_COOKIE and in both cases sending wire or wire_challenge on their own doesn't work, but if I send both together, eg: $http->setHeader('Cookie', 'wire='.$this->wire('input')->cookie->wire.';wire_challenge='.$this->wire('input')->cookie->wire_challenge); then it just keeps loading until apache times out, but I don't get any errors. I don't have time to spend fiddling with this today. Maybe I'll revisit later, or if someone else can see what I am doing wrong, any tips would be greatly appreciated.

Hehe, There are days, and there are days like these. At 0.0.9 now, even refactored the code a bit and added syntax highlighting for embedded PHP snippets. I think I'll call it a day now though.

In case you are still experiencing this, it appears it is related to the server upgrade, a mod_security issue, not ProcessWire. I just ran into this myself and my searching led to an acquaintance's similar issue in this post. I filed a support ticket with DH and expect they'll get it fixed shortly. It is probably a per-domain or per-account issue, so I'd suggest contacting support if you haven't already.

My wife loves to cook, and I always like to further my knowledge around Processwire. So I thought I'll build a small page with the some small function to learn something. Used modules: ProMailer RepeaterMatrix Pages2PDF AIOM and some other litte modules Current functions: JSON-LD for recipes and page search Automatic ingredient calculation when changing the number of servings Creation of a PDF of the recipe Basic PWA (here is something to do, actually) Planned functions: a lot ? Site: https://www.dothiscookingthing.de

Since I updated to the version ProcessWire 3.0.165 installing modules from URL, directory and Upload won't work anymore. I have already added $config->moduleInstall('download', true); to my /site/config.php file, but it still doesnt work. Has anyone a solution for this?

As everyone working in IT should know, it's important to use effective antivirus systems. ?

Lucky you! In slow vaccinating Austria we have a word for my little feeling called "Impfneid" which means some kind of "vaccination envy/jealousy" ;-D

@Pixrael this code replaces the if query in one line? Edit: It has no nested brackets ?

There's of course a (simple) solution for your problem: Create a site with the name "Messages" (I use a template called "options" for this only with a title) Create a template for the messages e.g. with title and body field. Create a field "Choose messages" fieldtype "Page Reference" Setup this field - see: Add this field to your "development" template Code ? foreach($page->messages as $mes) { echo $mes->titel;} Hopefully this will you - if you have any questions, please don't hesitate to ask ? Greets!

Thanks for the suggestions. Putting it down to a 'who knows?' Nothing changed and all small images that failed yesterday uploaded fine today. That's net-life for you! LOL

Just a heads up that I added a note about the ModSec rules being tripped in another form post here:

A bunch of my old clients started having this issue on Dreamhost as well. Like @cstevensjr, I noticed that any domains on a VPS weren't affected. However, some domains on shared hosting plans were affected while other ones were not. Probably a difference between servers, but not certain why shared servers would have different ModSec settings. Anyway, I was lucky to chat with a tech that was patient and knew his stuff. (Shout out to John B!) We worked through one of the affected domains and he figured out what ModSec rules were being tripped by the uploads. So he had to add exceptions to those rules until the uploads worked - even with the Extra Web Security option still enabled for the domain. After we got one domain working, he replicated the same exceptions to the other domains and we tested each one as we went. He kindly shared the list of rules that were causing the problem after I asked for them (in case this issue popped up again or if I had to speak to another agent about another domain). The rules being tripped were: application-multi language-multi platform-multi event-correlation attack-generic If you have to talk to a Dreamhost tech to get this problem resolved, it may be helpful to point them to this post or simply pass them the list of rules being tripped that need exceptions added. Like I mentioned earlier, and unfortunately, these rule exceptions need to be added on a domain-by-domain basis.

Thanks @Robin S - new version looks good.

As of about 5 years ago, I strongly prefer to use DigitalOcean to host my ProcessWire websites. By that, I mean I usually start with a clean Ubuntu droplet (not their pre-configured LAMP droplet) and then build the LAMP stack manually by running installing and configuring the necessary software. I can get a server going in about 5-10 minutes doing it "by hand" (i.e., not running an automated setup script). With this approach, I get a server that runs what I want without any bloat (bloat being Cpanel and all the beginner / GUI type-stuff you get with a typical host provider). I am comfortable with command line (not an expert by any means) but know how to figure out issues as they arise, such as installing any necessary or missing Apache modules and edge-case things like that. I don't consider myself a hosting expert either by any means, so in the back of my mind I often wonder if I have any glaring holes in my setup. For example, is using the default port of 22 really that bad if there's already login throttling? So far, I've never had an issue and I believe the defaults these days cover you pretty well. Ubuntu by default automatically installs updates and reminds you to reboot the server when necessary. Is Ubuntu LTS a "bad" distro to use for web servers for any reason compared to others? With that being said, I wanted to get some thoughts here from those who host themselves and any thoughts on DIY servers. Also, Apache, MySQL and PHP all have alternatives: Apache --> Nginx/Caddy MySQL --> MariaDB PHP --> HHVM (is this still a thing?) My belief when it comes to these alternatives is that while they might be "superior" and might provide some benefit, it seems the default software (Apache/MySQL/PHP) eventually catch up to the point where the alternative doesn't really make much of a difference, or at least in my use cases it won't. I prefer to stick with the defaults because it just works and ProcessWire is specifically tested with this stack. -- I guess this is a way of me saying that web tech changes quite rapidly, but playing this catch-up game of using the new, hot thing or getting anxiety because I feel like I'm not keeping up with it --VERSUS-- the reality (in my case) of it totally not making a difference when it comes to the bottom line has made me feel that the default / out-of-the-box way is totally fine. -- Note: I might consider using this in the future for automated LAMP setup: https://github.com/teddysun/lamp

Sorry, I just realized what you were getting at regarding https. I am testing this locally, so it's http and therefore wire / wire_challenge, rather than wires / wires_challenge. Out of interest, I tried this on a https server and I still get the same timeout issue.

Just tried activated it for https://corporate.blue-tomato.com/ which runs on Digital Ocean. Seems it works well.

You can create/modify the fields/templates/pages however you like in the development environment. Then create the migration page by just defining what has been added/changed/deleted. Sure, but why bother (see the above)? Minor tweaks by hand are OK if the json file isn't quite what you want, but better to let the code generate it. My module does not track changes - that can get very messy. You just define the scope of changes (in the right dependency order) and it picks up the current state - not how it got there. Perhaps this might work better than the real-time hooking. A suitable compromise that might be workable is a separate component that just logs what has changed since last time (without knowing how). That could then build a draft migration page, but the sequence may need to be hand-sorted as getting the system to work out the dependencies could be tricky. In theory, you could use json files to snapshot the whole database and then take diffs from that to create the migration page, but that could be pretty resource-intensive - at the very least you would want to restrict the page tree to exclude user pages which are not maintained in the dev. It definitely has that advantage, provided you took a snapshot before you started work on the changes. On the other hand (a) it is a good idea to document what you are doing ? and (b) if you are working on 2 or more sets of (disjoint) changes, your approach would bundle them as one. So while it may be a good idea (and maybe achievable as per the above comments), you would definitely want it to be optional - e.g. have a button "Create migration page from snapshot". I couldn't agree more, and would appreciate @ryan's take on this. It is the only thing about PW that irritates me. I'm not sure he would agree - the whole import/export stuff seemed to have been left unfinished years ago - for example this. And by all means look at my code, but you might wish to wear gloves ?

Hi Adrian, I'm not sure how to do it with wireHttp, means haven't used it until now. But the native header for sending cookies back to the server looks like this: GET /processwire/page/ HTTP/2 Host: www.example.com Cookie: key1=value1; key2=value2 Its a simple key=value pair list separated by semicolons send as a header. Maybe it can be done like this: $http = new WireHttp(); $http->setHeader('Cookie', $cookieList); References: https://tools.ietf.org/html/rfc6265 https://chenhuijing.com/blog/understanding-browser-cookies/

Wow. This looks so cool. The creation of fields and templates via the admin might not be for everyone, but I think you can generate the migration file also by hand, right? A feature that has been requested multiple time, is that all changes that you do in the admin should be tracked and added to a migration. I like the basic idea behind it, and think of a hook, that gets triggered after creating a field/template, or making modifications to a field, which automatically or after confirmation modifies or adds a migration file. As you are also running a diff, you might create a migration automatically, to see what changes have been made to templates/fields/contents since the last migration. Then you would just choose which templates/fields/contents should be included in the migration. For example you added a new field, added it to two templates and created a new page with one of the templates. Now your module could run a "Get changes" command, that fetches all differences since the migration and asks which of them you want to integrate. With this behaviour you would not have to remember and "define the affected elements" as in your video. What you think about this approach? I am also happy to have a look at your code and try it out, because I think migrations is a major issue with ProcessWire right now. I am using @bernhards RockMigration atm, but also like your approach. Migrations should be an important part of the core IMHO.

@Robin S - Ryan's update to the HannaCode module yesterday has broken this. Looks like it's probably just because he namespaced it, so should be an easy fix. PS - @teppo - I wonder if your HannaCodeHelper module might suffer the same fate?

Bern hard u.can does $wire->addHook('/mymodule/{foo}/{bar}(/{baz})?/', function($e) { return "<pre> foo: $e->foo bar: $e->bar baz: $e->baz "; }); @ bern berna hard @ @bernhard

Thanks a lot ☺️ I can show you the structure of the recipe template. Here are all accordions open. Tags are reference fields for the categories as well as the ingredients that are used as reference for individual ingredient pages. New categories and ingredients are created automatically when you enter the recipe. Especially with the ingredients there is still a lot to do, because the individual pages (e.g. https://www.dothiscookingthing.de/zutaten/balsamico/ ) should still get texts and images. Maybe also a bit of SEO texts. ?

You are in Flow! ? ?

Maybe a file and directories ownership issue since you state that: I am assuming you have also tested with 'small sized' images. I would look into file and directories ownership first. The usual scenario is there is a www-data user and group. ProcessWire would belong to that group and will be able to write to /site/assets/files/. Have a look at this page to troubleshoot permission issues: https://processwire.com/docs/security/file-permissions/ Regarding this: It usually means PHP responded with a fatal (or other) error. If you have $config->debug = true, or better, have TracyDebugger installed, you will see the exact error the server returned. You can also see these in your sites error logs. The text of the the response breaks the JSON (malformed), hence the Unrecognized token.... This is the so-called 418 I'm a teapot response! ?.Basically, the server is saying you are asking it to do the impossible; brew coffee but it is a teapot! You can read more about it here https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418 and how an April Fool's joke turned into this status by reading here https://sitesdoneright.com/blog/2013/03/what-is-418-im-a-teapot-status-code-error .

@benbyf, moderator note A near identical topic was created yesterday. I have combined your threads. @Simi I have modified the thread title slightly to better reflect the issue you are facing.

Running PW 3.0.165 and have added to config.php: $config->moduleInstall('directory', true); $config->moduleInstall('download', true); $config->moduleInstall('upload', true); but with no change in the admin... stil unable to update modules, or grab them via urls ? whats the deal here?

In v0.0.2 I have added a hookable method that supplies the array of tag names for the dropdown menu. You can use an 'after' hook to control what appears in the dropdown. A couple of examples... Define the tags for a given template: $this->addHookAfter('HannaCodeDialog::getDropdownTags', function($event) { $page = $event->arguments('page'); // Show only these tags on pages using the 'basic_page' template if($page->template == 'basic_page') { $event->return = ['some_tag', 'another_tag']; } }); Remove certain tags for a given template: $this->addHookAfter('HannaCodeDialog::getDropdownTags', function($event) { $page = $event->arguments('page'); $tags = $event->return; // Remove these tags on pages using the 'basic_page' template if($page->template == 'basic_page') { $filtered_tags = array_filter($tags, function($tag) { return !in_array($tag, ['some_tag', 'another_tag']); }); $event->return = array_values($filtered_tags); } });

It is possible $field2 = $page->field2; $result = $pages->find("template=something, field1>$field2"); Edit: ah hehe, ok this is what you're looking for. $results = new PageArray(); foreach( $pages->find('template=something') as $p) { if($p->field1 > $p->field2) $results->import($p); } Anyway have you tried your version if it would work?