Leaderboard

ProcessWire 3.0.195 contains a few fixes and optimizations relative to the previous version. While there aren't major additions, if you are running a previous version of the dev branch it's a worthwhile upgrade. Version 3.0.194 added the lazy loading fields, templates and fieldgroups, but there were still a few cases where PW would load them all. This version corrects those few cases. So if you considered 3.0.194 to be a nice upgrade, 3.0.195 is an even better version of it. There are also some useful bug fixes in this version. One notable bug fix (found by Adrian) was that the $pages->findMany() method was lagging due to some changes a couple versions back (limited to dev branch). That's been fixed so now findMany() is fast again. Also a notable addition: the included site profile (site-blank) now includes a /site/classes/ directory with an example HomePage.php file/class that serves as both a placeholder (to ensure the directory exists in Git) as well as an example custom class for the “home” template. I thought this was a good idea because many might not even know about the custom page classes feature without that obvious pointer to the feature. More core updates and additions next week. Thanks for reading and have a great weekend!

Hey, it seems to me that there is a wrong thinking or understanding to the whole subject that leads to the confusion. (?) If your comparison are between the compressed image from a third party tool, e.g. photoshop or others, and ONLY the webP output from GD or imagick, then this is comparing apples with bananas. If that's the fact, please read on. If that's not true, please excuse my post and my misunderstanding and forget / don't read the rest of the post. ? EDIT: maybe of additional interest:

The module can generate basic ICS calendar strings and files. Usage Example: $icsgen = wire()->modules->IcsGenerator; // set properties $icsgen->setArray(array( 'date' => new \DateTime('2033-12-24 12:00'), 'dateEnd' => new \DateTime('2033-12-24 13:00'), 'summary' => 'Event title', 'description' => 'Event description', )); // get path to a temporary .ics file // (using wire()->files->tempDir) $icspath = $icsgen->getFile(); // send email with ics file $mail = wireMail(); $mail->attachment($icspath, 'calendar.ics'); $mail->to($user->email); $mail->subject('ICS Demo'); $mail->body('This is a ICS demo.'); $numSent = $mail->send(); For more infos see GitHub Readme or Modules Page. If you experience reproducable issues please open a GitHub issue.

This site profile for ProcessWire offers a simple, multilingual and responsive blog which doesn't require any module. It works exclusively with some template files. See: https://processwire.com/modules/site-simple-blog-multilanguage/ Installation This site profile is intended for use with a new installation of ProcessWire. Download ProcessWire, extract all files and folders and upload it into your web server folder. Download the site profile, extract the simple-blog-multilanguage folder and upload it into the same folder. Start the installation. When prompted for Site Installation Profile select Simple and Multilingual Blog Profile for ProcessWire 3x and continue with installation.

@horst Thanks very much for your detailed explanations that help me quite a lot. Following your arguments, I’m indeed comparing apples with bananas. Usually I’m working with a mixture of your strategies A & B by using one image "as is" and create further JPG variations of them, mostly thumbnails, where neither quality nor file sizes are somehow critical. As I’m planning to use WebP and a broader palette of size variations, I should probably seize the opportunity to overthink my (bad) habits and switch to pure strategy B. Embarrassingly, I never came up on the idea to use config settings for image processing, probably because I didn’t feel an urgent need for it. With strategy B they seem to be useful if not essential. So thanks for that important hint too. I will do a serious testing with all those brand new perceptions.

This week I've bumped the dev branch version to 3.0.194. Relative to last week, there are a few commits fixing minor issues. Last week we covered some fairly major updates and I've not come across any concerning side effects, so figured it's a good day to bump the version. Next week my kids are out of school for winter break so I'll be around but I don't expect I'll have much in terms of updates to report next week, but definitely will the following week. Thanks and have a great weekend!

Hello, @teppo! Can you please tell me whether it is possible or not to use Wireframe's components on templates where it is not initialized? It is needed because some parts of our site work on Wireframe while some aren't, but we need some component that will work across all templates.

@teppo, should we lock this thread to encourage to create dedicated posts?

Sorry for the unclear question but your answer @monollonom was exactly what I need. Thank you

Hi @Sava, I'm not sure I get your question... do you want to know how to get a URL of the QR code to be able to download it ? In the unformatted output the QR code is already in the form of an <img> (or <svg>), but I went ahead and added a "raw" key in the unformatted output. You can download the latest version and try to do something like... $qrcode = $page->getUnformatted("qrcode_field"); foreach($qrcode as $qr) { $filename = $sanitizer->snakeCase($qr["label"]); $label = "Download QR code for \"{$qr["label"]}\""; echo "<a href=\"{$qr["raw"]}\" target=\"_blank\" download=\"$filename\">$label</a>"; } Hope this helps!

It works in 3.0.194. Good tip!

@wbmnfktr, @kongondo I just want to throw in a thought about a point I read somewhere above, regarding (native) endpoints in PW based on templates. If you think about the possible different processes only upon the access methods of an URI, reflected by $config->ajax (true|false). You can define an output of text/html or application/json for an template. In PW, the default is text/html. Within a general hook you we can check for registered templates and then switch the output processing according to AJAX or FETCH access. Does this make any sense to you? Or have I missed the point? EDIT: also upon the access method, we dynamically can switch the processing filename of the templates, not only the output type.

don't worry we have all made every kind of mistakes or omissions you can imagine at our turn... and solving them is the best way to learn and not forget again ? glad everything works fine now have a great pw trip ? and of course, have a nice day ?

I admit that this functionality could/should be included in the kernel (but disabled by default) as I personally use it for every installation, but still I didn't feel the need for it (getting it in the core) as I find the flexibility provided by the module AppApi made by @Sebi more interesting. Just include this module in your setup and you are ready. Anyway the argument is really good about that it will excite new users who have not yet tried ProcessWire but want to give a try when they see that they can use/build an API out-of-the-box.

Everything comes down to the content management needs. I personally like managing content with markdown files and front matter, but obviously not ideal solution or non-technical non-dev users. Also, theres clients that want you manage content for them, and content is rarely changed. In this case you dont really need a cms, but when you need it, this is where headless cms comes into play. And can work very well. Use headless cms to add/manage content Fetch content with SSG and build front-end with favorite generator / framework. Deploy your static site to the preferred service (github, cloudflare, netlify, vercel....). Use webhooks, or github actions to trigger rebuild when content is changed. As re-generating static site takes a bit of time, and compute, this is not ideal for all situations and needs. It depends on how frequent content is changing. If you have a directory for example, and visitors can publishing content, obviously this would not be a good solution. There's a lot of headless cms-s out there, but non of them from my experience is good as processwire. What pw is missing is is "external headless" features, REST api. Yes, we can build it our self, and can make json feeds fairly easy, but having it out of the box would be great. Im not an api or security expert, dont know implications, but from what i see most/all of the cms (especially headless) out there have this...

Same idea, but personally I've never used it or seen anybody using it here on the forum ?

Did you try using a utility class? https://wireframe-framework.com/docs/patterns-and-practices/utility-classes/

https://pwgeeks.com/

@slkwrm Thanks for the hint. Actually it turns out that the repeater page's parent is not the page where the repeater field is, but this page can be got by calling the method getForPage. So the correct code is: $containerPage = $page; if ($page instanceof RepeaterPage) { $containerPage = $page->getForPage(); } // can be checked with echo $containerPage->id; I added this container page calculation at the right place (I hope!) in TextformatterHannaCode.module and the repeater field case now seems to work for hanna codes.