Leaderboard

I was in New Orleans at the gymnastics Nationals most of this week. In her age group and level, my 10-year old daughter won 4th overall and 3rd on bars and beam. After a long drive, we're now back home in Atlanta and it's been a very short work week, but there's still a new dev branch version to write about. ProcessWire 3.0.221 continues primarily with minor issue fixes, working towards our next main/master version. Included are 11 resolved issues, 2 PRs, and code contributions from @matjazp and @dotnetic. In terms of new features, this version updates the language translating _n() function to support languages that consider 0 quantities as singular rather than plural in calls like _n('%d item', '%d items', $quantity); Previously this call has always used the plural "items" version for 0 quantities (i.e. "0 items"), which is correct in English, but may not be in other languages like French (as I've learned from issue #1757, though I think it has come up once before too). To define whether a language should consider 0 quantities plural or singular, use ProcessWire's language translation tool: Setup > Languages > [any language] > Find files to translate > wire/modules/LanguageSupport/LanguageTranslator.php ... when translating that file, you'll see the setting at the top labeled "Is zero (0) plural or singular?": That screenshot above also shows another new feature that was added, which is the ability to use Select and Radios fields when defining translatable text. Previously you could only use text, textarea and number fields. Let's say you wanted to have the person translating choose a color name for the language as part of the translation: $color = __('Red'); // What color? type=radios options=[Red, Green, Blue] As before, the "What color?" part is an optional description for the translatable text. Also as before, the "type=..." defines what Inputfield type to use. The supported values are any Inputfield name (minus the "Inputfield" part). Known to work values for this include: text, textarea, integer, float, radios and select. The "options=[...]" is the newly added part, and this enables you to define the selectable options for select or radios inputs. If you wanted to use separate value and label, you can also do that. In the example below, city abbreviations are used for the values and full city names as the labels: $city = __('ATL'); // What city? type=radios options=[ATL:Atlanta, CHI=Chicago, NYC:New York City] Another example is the one we used in the core for plural vs. singular here. By the way, if any of your values or labels need a literal comma, you can optionally use a pipe "|" as the separator rather than a comma. This ability to use Select and Radios is a fairly minor addition, but does open up better support for having certain language settings (rather than just translatable text) be part of language translation packs going forward. The plural vs singular setting for 0 seemed like a good first one to support with this. Next week we'll continue preparing our next main/master version. Thanks for reading and have a great weekend!

ProcessWire might still work on older PHP versions, but it's not being actively tested on anything prior to PHP 7.x anymore. I'll update the version requirement to: "PHP 8.x recommended (PHP 7.x versions also supported)". I run on PHP 8.2 here, and I think that's the preferred version to run for the dev branch at least.

Hi, We've been looking at using Postmark for some clients and we were delighted to see an existing module WireMailPostmark - https://processwire.com/modules/wire-mail-postmark/. However the note in the initial forum post about it not being used in production by the authors meant that for us we would need to build something a little bit more in line with what we need and can maintain through usage. WireMailPostmarkApp is an implementation of postmark-php, somewhat in line with a previous WireMail module we built WireMailgun - https://processwire.com/modules/wire-mailgun/ - and its usage will be familiar to those who have used that module. Here's the README: https://github.com/nbcommunication/WireMailPostmarkApp/blob/main/README.md Cheers, Chris

Forums often don't understand ironic, sarcastic or other kinds of conversations which normally do work face to face. In face to face conversations, your counterpart does not only hear your words (or read your text in the forum), but also sees the smile in your face or your mimic or gestures. Writting in formus gets even more difficult, if you need to translate things from your first language to a foreign language you learned 20 years back in school but with only little practice. Often the use of a smiley doesn't get the meaning of your text right if it was already missunderstood by the reader in first place. That is at least my experience in various forums ?.

In your Pages::saveReady hook, the $event->object is actually \Processwire\Pages. The actual page being saved is what's returned from $event->arguments(0). In this case you are assigning it to $user, but that won't always be meaningful; only when you're saving a user. Bernhard's solution will work of course, but it may also be advisable to assign $event->arguments(0) to the variable $page (rather than $user) to avoid confusion in the future. You can then check for $page-template == 'user' if you want to do something specific for users being saved.

I try to stay up with PHP/Python etc. like I do for my Windows/Linux systems too. So I would use PHP live cycle as a „target“. All EOL versions should be avoided for new projects or upgrades and not be promoted. At least try to update/recommend the lowest PHP version still maintained or at least still receives security fixes. https://www.php.net/supported-versions.php Personally I develop with PHP 8.1.x and test stuff with 8.2.x too so I spot possible deprecated stuff early. Similar to my Python, nodejs, npm projects.

PHP says something different https://www.php.net/manual/en/security.current.php and this blog post https://kinsta.com/blog/php-versions/ lists some good reasons for staying up to date. So in general I think it's a good idea to stay up to date. Note that my intention is not to blame anyone not updating his/her setups or modules. I'm still running some sites on PHP7.4 because that are low budget sites or sites for friends or personal projects. There are reasons why it can be better to stay on an old version, but there are also many good reasons to keep up to date. For example better performance and better security. Personally the php-supported-versions page has helped me to communicate to my clients that some kind of maintenance is important for every project. Some clients have the expectation that developing software means pay once and then it works forever without any additional costs. And we all know that this is not true. And even though PW is a lot better than other systems (which I find great) I think that we as web professionals have to educate our clients to continuously invest something into the assets that we made for them. I'm not talking about WP Update Hell but doing maintenance every 2 or 3 years should really not be too much for a professional website. And it also makes sense from a business perspective for ourselves! It's like having a car and doing regular maintenance and changing oil etc. before the engine takes damage. Also it's better to take smaller steps (PHP5 --> 7 --> 8 --> 9 than waiting for a long time until you hit a "relaunch or die" situation). Personally I'm not recommending to my clients to update to the latest & hottest sh* all the time, because being an early adopter usually comes with additional costs. But I'm trying to keep them up to date with officially supported versions. And I try to use newer PHP versions on my own projects so that I can report issues that I find. That way we can continuously fix those issues when they come up and before they get critical (meaning fixing warnings rather than bugs/errors). And I think it would be good if ProcessWire showed commitment for that and communicated that in clear and understandable way so that everybody interested sees the benefits and the reasons behind the strategy. And so that everybody sees ProcessWire as what it is: A serious and professional tool that you can trust and that is actively developed. "PW needs PHP5.4+ but we recommend PHP7+" clearly does not do that in my opinion. When PW was mentioned on other platforms I read comments like "latest commit 2 years ago - that project is dead" or similar. Just because they didn't realise there is a dev branch. That shows the same problem from a different angle in my opinion. And it shows that having minor releases like PW3.1 or 3.2 can be a good thing. And the solution (and intention) is not to push devs into a version number race but to have a strategy and communicate that clearly. So that everybody knows what to expect and so that we have less assumptions (which is clearly the case as this discussion shows). Have a great weekend ?

@AndZykThe term „ideally should“ in German means one should at least try to target no warnings/errors or even blank pages in public Github main/dev branches in general - no matter what project it is. I have not written PW dev does not run with PHP 8.2 nor that I found errors or experienced a white page of death. I have seen some deprecation warnings some weeks back, thats all. Hope this makes things more clear. There is always a chance for getting things wrong in forums, especially if you have to write in languages other than your first language.

I think this is an unfair statement. In my experience PW had no warnings or errors with PHP 8.1 since PW 3.0.210. And for compatibility with PHP 8.2 there is a GitHub issue where you can report warnings or errors: https://github.com/processwire/processwire-issues/issues/1664 So if you @cwsoft really have experienced a warning, error or "blank page of death", could you please provide an example or report it to this thread? ? Since PHP 8.2 is the latest version and PW has a big core, I think it is fair not to expect it to be compatible with it over night. Requirements In my opinion I think the minimum recommended PHP version should be the last supported PHP version: https://www.php.net/supported-versions.php So at the moment this would be PHP 8.0. Recommending an unsupported PHP version maybe would not make a good first impression. Versioning In my opinion I also would recommend switching the versioning of PW. PW 3.0.xxx started in 2015 and while I understand the explanation for the versioning process, from a marketing and user perspective there is lack of distinction between the different versions. Other CMS celebrate major upgrades with a major version bump (3.1 or 4.0) and some give those versions even silly names just to make it clear in the marketing or for the users, that this version has something special to offer. ? But as always, much love for PW. ❤️

I think there are pros and cons and I think @wbmnfktr has made a good suggestion in bringing up the topic. While writing that post I've had to lookup the requirements page. This is what it says: I imagine if I didn't know anything about ProcessWire and someone gave me the link to the PW website and this was the first thing I saw I'd turn around and run. Actually that was what happened in 2013 but gebeer was patient and kind enough to make me have a second look. PHP7+ recommended? How can a system that I should build my business on and that markets itself as security as top priority recommend a PHP version that has been end of life for more than half a year now: https://www.php.net/supported-versions.php ? And it's not like PHP8 is totally new... We have it since 2021 and PHP8.1 since 2022 So while I'm a huge fan of ProcessWire being a timeless tool that can run untouched for years without updating either PHP or PW I'm also really liking the idea of having a clear cut and maybe even bumping the version with that cut to PW3.1; Maybe it should just be communicated in another way! When looking at the requirements page nobody knows that it's a timeless tool and that this is besides security one of the top priorities. Also... PW3.0.220... That's such a weird version number that I've never seen in any other library. In my ProcessWire lovestory I mentioned that and I framed it as "not a single breaking change for 220 weeks" and that's not a lie I guess, but my feeling says that moving forward to PW3.1 with minimum required PHP8.1 would be a good thing. If anybody didn't like that he/she could just use PW3.0.222, no? Also more feelings than facts ?

Congrats to your daughter! And looking forward for the next master.

Yo @kongondo How far off is the following code as an interim solution for mine and @Spinbox's requirements? It doesn't seem to be working and I can't see what I'm missing. (I've changed the actual domain to 'domain.com' and admin page name to '/processwire/' for posting here) $this->addHookAfter('PadloperProcessOrder::sendConfirmation', null, 'sendOrderConfirmationToAdmin'); function sendOrderConfirmationToAdmin(HookEvent $event) { $object = $event->object; $orderPage = $event->arguments(0); if (is_null($orderPage)) { $orderPage = $object->getOrderPage(); } if (empty($orderPage->id)) return; $orderId = $orderPage->id; // Drop this in place of $loginLink to send the request straight to the print order link // $printInvoiceUrl = "https://www.domain.com/processwire/shop/orders/print-invoice/?id=$orderId"; $loginLink = "https://www.domain.com/processwire/shop/orders/view/?id=$orderId"; $shopEmail = wire('padloper')->getShopEmail(); $mail = wireMail(); $mail->to("email@domain.com"); $mail->from('no-reply@online.domain.com'); $mailSubject = sprintf(__("New Order - #%s"), $orderId); $mail->subject($mailSubject); $mail->body("There's been a new order #$orderId!"); $mail->bodyHTML("<p>There's been a new order #$orderId!</p><p><a href='$loginLink'>Click to login and view</a></p>"); $mail->send(); }

@alexm. Sorry, my bad! I get you now. I'll add this to the settings together with your other idea about a 'from email address'. I'll make a variable, $storeDetails or something like that available to invoice-content-html.php. This will give you access to the bank details saved in the store config. Do you need more than these three pieces of info? Cheers.

@bernhard, thanks! Quite an elegant solution, works like a charm.

@kongondo sorry about my long overdue response. I think there might be some confusion, unless I'm having a bit of a moment. When the customer buys from the store I wouldn't need to get their bank details, but they would need to have the store's bank details to make the payment to the store. Therefore there would be no need to have the ability to collect the customers bank details at checkout as they won't need paying. However the invoice template in general, whether it be that the customer checked out via 'invoice' payment or 'stripe' etc would probably be advisable to include the stores bank details for receiving payments. Hence, I would think that most people will want the ability to add their store's bank details on the store configuration so they can be displayed on invoices sent/or printed via the system so customers can make bank transfer payments. For no I have hard coded it ??

@bernhard Thank you. I am using that extension. I'll be sure to follow your guidelines regarding logic as I move forward. Greg

So I guess you are calling $page->save() somewhere in that endpoint, right? In that case you can just add whatever runtime property you want to that page and then use that as a flag in your hook: <?php // api endpoint ... $page->isFrontendSave = true; $page->save(); // hook, eg in init.php $wire->addHookAfter("Pages::saveReady", function($event) { $page = $event->arguments(0); if($page->isFrontendSave) { // do something } else { // do something else } });

Thank you Robin! Great job ?

If it's around next 2 weeks don't bother and save your time ❤️

Hi @Spinbox. This is coming in the next version (hopefully next week, there are quite a number of changes to it, so it is taking a bit of time). Meanwhile, do you mind using a Hook? I can show you how. Thanks.

A bit weird and probably nothing to listen to while programming - still awesome.

Mau P @ Academy - Los Angeles 2023

My absolute favourite tool for developing still is: LARAGON Since I left Windows a few years ago... I still miss it. It's so easy to use, super fast setup/installation, new sites are only one click away. AWESOME! Installing DDEV on Linux is quite a big task, reboots included. After the 3rd or 4th time it get's easier but still quite a bit of work. AND it's big. It takes quite a bit of space on your disk. A few gig at least. I remember my first DDEV setup and I swore to myself: NEVER EVER AGAIN! But then I tried my old setup with installing Apache, MySQL, PHP, and all the other stuff... it was quite humiliating and I installed DDEV again. Yet, never got it up and running on any Arch-based setup, which is fine, as I'm running Debian now. What I really enjoy is chaining commands (using aliases). Something like: ddev start && ddev launch && code . && exit from the terminal, wrapped in a FZF script or local .sh file... Nice! Which brings me to the benefits of DDEV... you can create your very own workflow with DDEV using aliases. A new PW instance or maybe even the other CMS some people are talking about... you can do quite a lot, still the docs are sometimes a bit hard to read and maybe too verbose (too much fluff in this case). My personal most loved features is that you can share your config to setup an identical environment with ease. .ddev/config.yaml for the win! Looking for and grabbing those setup prompts for DDEV to get the setup you need is just pure Gold! Some of you may remember I wasn't a fan of DDEV in the past. ?

@Tintifax, Ryan has fixed the issue. So to get ProcessDatabaseBackups working as normal: download PW 2.0.220 again to get the latest commits, update the wire folder of your site, uninstall ProcessDatabaseBackups if it is already installed and then reinstall ProcessDatabaseBackups.

To be abolute honest here... right now working with ProcessWire (Dev) on a recent hosting setup using my loved modules, feels a bit awkward. Besides one of my main hosters, all use PHP 8.1 as the default now - old instances not included, they still run 5.4+. I don't want to force anyone doing things they don't want to do right now, because it's not really/absolutely necessary. I'm totally fine with this. Latest PW Stable, PHP 7.4... total peace and harmony. My thought, see above, doesn't name a date or even a date range. Yet I somehow have the feeling that ProcessWire should somehow set a date for a minimal PHP 8.x version so everyone, especially module devs, have a roadmap/timeline for their modules. Even Core modules have issues with PW Dev on PHP 8.1 so I know that this isn't a thing we could or would see in the next 3-6 months. Still somehow developing with the latest and greatest PW/PHP seems a bit wonky (sometimes). To make it absolute clear here: Even though it sounds like I am complaining (which is fair, and true), it's more that I am worried. I have had 2 encounters now were people asked me why certain errors/warnings show up. They used a PHP 8.1 setup AND the latest PW DEV with some of our awesome modules as they were curious and wanted to try it, after I pushed them towards it. I did miss to say: Don't use PHP 8.1, which is a hype right now. Sorry! This is more a feeling, than a fact.

You have to use getRows() $items = $rockfinder->find("parent=/foo/")->addColumns(['title','text','date',]); //d($items); foreach ($items->getRows() as $item) { echo $item->title.$item->text.$item->date; } and the result will be objects, you have to use "->" instead of the square brackets

Hi @nbcommunication, thanks for the quick reaction! The update fixed it for me. ? Cheers, Flo

Please note: I changed my initial forum name zx80 to my Github name cwsoft. Never thought I will release two PW modules within a month after my initial registration to the ProcessWire community forum ?. Hope this makes it more transparent for possible future contributions to the PW eco system.

Hey @zx80 great to have a new module author ? congrats! FYI: You can also just copy and paste the link to the ZIP file into the "install from url" field then you don't have to rename anything. I see that you inject both the JS and the CSS file in the site's head. I wonder what you or others think about that approach to inject such small files into the site. I think since HTTP2 it should not matter but tools like pingdom speedtest still show the "number of requests" as KPI. Personally I'd prefer splitting things into multiple files and then just including them over complicated build tools. And I'm already doing it similarly with RockFrontend. But I'd be interested what others think or if anybody has some good resources to read.

I just read this after I got home from Saturday morning netball with my 11 year old daughter. Sounds like ProcessWire kids are a thing. ?

Thanks to @teppo for the ProcessWire Weekly shoutout! I wanted to share some updates to show I haven't been a lazyass some more detail and information since my last update post. Caching is optional and can be cleared. Translations are persisted for 1 month which helps even out month-to-month API usage, but also expires so if DeepL improves their translation then you still get the latest and greatest. I haven't formally timed it but cached translations feel near instantaneous. Modified content? If the content of a field has changed since the page edit screen was loaded- then the tab text is italicized and an accent is added. This tracks changes whether you typed the text, or if you used the translator to change the content. It's stateful so if you return the content to the original value, the accent is removed to indicate that the content has not changed. Oh, and this is tracked independently for each field, and separately for each language. So it is now much easier to see if there are fields that weren't translated. Heck, it even helps users make sure they didn't miss anything anywhere before they hit Save. Table fields are now supported. I forgot to mention that before. Fluency has been tested with all ProFields and is 100% compatible. TinyMCE is ready to go and, as promised, CKEditor regular and inline are also supported Error handling! Fluency is aware of all errors that are possible to be received back from DeepL. It's also smart enough to know if the DeepL service is unavailable or if you lost connection to ProcessWire (what wifi?). This helps make it very clear where the error happened, which may save you some headaches during development (and maybe emails from your clients/users later). In my case DeepL rejects requests when I'm on a VPN even if my internet is workin' alright. Localization is here. Every single aspect of Fluency is translatable using one central file in the admin language configuration. That's it. No chasing different files in the module to translate things. English is the default language in these pics, but it also shows the proper language if your default isn't. Achtung! Even the errors speak your language. I got you, international friends. For the nerds... One field, one file, full documentation. Each field adheres to standardized public interface methods so they are modular and completely independent of the rest of the codebase. If the old code was structured like this TinyMCE would have been ready the day after it was announced by Ryan. Not every inputfield needs its own module because some fields just use others- a repeater containing a textarea still just counts as a textarea. Less module updates, more translating! All of these are core Fluency features. I'm prioritizing this over any work on a Pro module to get this out for testing and into everyone's hands sooner. Still work to be done, already 3x more code than the last version, but we're bringing the ? More updates to come!

Yes that's the feature. If you have a large music collection it could take some time to process all of it, and the sonic adventure features do not work until the scanning process is not active - but once you have turned it on it adds material as you go. For around 1200 albums it took my media machine about 4 days to process. I haven't used the ChatGPT connected feature Sonic Sage, but i've heard some folks like it. Track Radio is also a great understated feature. I don't use spotify and I haven't tried connecting Youtube Music. I do know Tidal is not supported - I think it needs to access your files because it doesn't phone home - it literally uses whatever audio files are on your plex server, meaning really obscure stuff you have will get included in the analysis and mixes that may not be available through normal channels.