ryan

Happy 1st of September! Now that we've got the new main/master version out and running smoothly, I've been catching up with some client work this week. I'll need to do some of that next week too. But we'll also be fine tuning the core and fixing anything that comes up in issue reports. We may have have another master version out with these kinds of minor updates before digging into more major updates, feature requests and PRs on the dev branch this month. If you've not yet upgraded to 3.0.226 yet, I'd encourage you to give it a try. So far all reports have been positive and I've not heard of anyone running into any upgrade issues yet. Thanks and have a great weekend!

After 8 months in development we are excited to bring you ProcessWire 3.0.226 main/master. This version has a ton of great new features, improvements and optimizations, plus more than 100 issue fixes. This post takes an in-depth look at highlights from this great new version. While there's even more in this version than is covered fully here, we hope this gives you a good taste of what you'll find in 3.0.226! https://processwire.com/blog/posts/pw-3.0.226/

The master/main branch is now updated to version 3.0.225. Early next week I'll be adding a git tag for the version number as well. I usually like to merge dev to the master/main branch first, let it marinate for a day or two, and then tag it. That's because once we tag it, it triggers other services to pick it up and broadcast it. So letting it marinate for the weekend just adds a layer of comfort, for whatever silly reason. That's pretty much how I've always done it. When I did the merge, it reported 511 files changed, 76421 insertions(+), 23539 deletions(-), so there's quite a lot in this version. There's enough, that I'm going to need another week to document it all into a new blog post, which should be ready by this time next week. Our contributors list also continues to grow nicely with this new version. Thanks to all those that have submitted PRs, reported issues, and submitted feature requests. Big thanks to @matjazp in particular who has been helping a lot in identifying, testing, organizing and even coding the solutions for numerous issue reports. More details on this new version next week. Until then, thanks for reading and have a great weekend!

This week we've been resolving a few more remaining issues, mostly those that take more time or discussion. So there's not many commits to the dev branch this week, but that also means we're very close to having the main/master version ready. I'm hopeful we'll be there by this time next week. If you have a chance to test the current dev branch please do, and let us know if you run into any issues. Thanks and have a great weekend!

This week on the core dev branch is ProcessWire 3.0.224! Relative to 3.0.223 it has 25 commits and 17 issue resolutions (see dev branch commit log). I think we are within 1-2 weeks of having the new main/master version, so I'll be looking closely for any new reports. Consider us now in a dev branch feature lockdown in preparation for the main/master version. At this stage, there likely won't be any new features added or issue resolutions that would require significant field testing (at least not until the merge to main/master). If you have a chance to test the current dev branch version, please do, and let us know if you run into any issues. Thanks and have a great weekend!

In a recent GitHub issue report, I was asked about output formatting in ProcessWire, and where more information could be found about it. I know I've written about it numerous times, and went to locate the documentation page, only to find we didn't have one! Output formatting is such an important topic, so here is everything you need to know. I hope you'll find it simple enough, but also useful and thorough— https://processwire.com/blog/posts/output-formatting/

Like last week, work continued on preparing our next main/master version by working through remaining issue reports, this week with a focus on older and previously missed reports. Thanks for bumping up any that we may have previously missed. Thanks also to @matjazp for helping to identify and prioritize them. In addition, the version number was updated to 3.0.223 this week, as there were enough changes to warrant differentiating it from 3.0.222. It wasn't all issue fixes this week, as several minor additions and improvements were completed as well (see the dev branch commit log). Next week will continue along the same path. Thanks and have a great weekend!

@Robin S Good call! Not sure how I forgot about that one.

This week the dev branch version remains at 3.0.222 but updates and issue resolutions continue as we work towards our next main/master version. I think we are quite close. Thanks for reporting issues in our processwire-issues repo. If there are older issues that I've missed, also feel free to reply to them and that'll bump it to the top when we sort by last-updated, ensuring it gets eyes on it. Thanks and have a great weekend!

@da² Looks like a good form class. I experimented with removing that cache in InputfieldForm, but found that it was worthwhile to keep as it gets called 5 or 6 times in page editor testing, and removing it adds more overhead than I'd like. So instead I updated it so that $form->getErrors(null) forces it to re-check all the fields, clearing/bypassing that internal cache. So in your form example, you'd call $form->getErrors(null) rather than $form->getErrors(), and then it should do what you were expecting. https://github.com/processwire/processwire/commit/b77d7f98c64edda4d49b2415e092e804e4c37e70 There is no problem with it. It takes care of figuring out namespace issues and compiles a new version of the file that resolves them. Since you were using 'use' statements at the stop, I was figuring you didn't want it adding more namespace logic behind the scenes. But since you've got templateCompile=false; then you're all set.

@dotnetic I don't think there's an option like that for findRaw, but you could still use findRaw, as it'd be fast and simple to get them in the order you want: $getIDs = [ 1014, 1, 2 ]; $getFields = [ 'id', 'name', 'title', 'url' ]; $rows = []; $a = $pages->findRaw($getIDs, $getFields); foreach($getIDs as $id) { if(isset($a[$id])) $rows[] = $a[$id]; }

@hipperman When you include() ProcessWire's /index.php file, that'll leave you with a $wire variable, which is the ProcessWire instance of the site you included the index.php file from. From there, you can access any ProcessWire API variables from that $wire variable, i.e. include('/path/to/your/pw/index.php'); $page = $wire->pages->get('/about/company-history/'); echo $page->body; If need be, you can even boot multiple different instances of ProcessWire, but just make sure they are all running the same version.

@dotnetic The getByIDs method should do it: $items = $pages->getByIDs([ 4, 2, 1 ]);

@da² This way of processing a form with the process() method was introduced in PW 3.0.205, so 3.0.210 would have been the first main/master version to support it. The method wasn't present in 3.0.200, so I'm thinking most likely you were using the processInput() method instead? (example here). But it may not matter, as the process() method is just a front-end to the processInput() method to provide a more convenient API usage, as it returns a true or false as to whether the form was processed without errors. But that distinction is significant for your example. It assumes processing the form is a one-time thing and that you aren't going to manually add errors to the form once it has successfully processed, as identifying errors is part of processing. In your case, you are doing a secondary validation manually, adding errors after the form has processed. That's new to me, but if you find it useful then I'm all for supporting it. With regard to "forever cache", the cache is a request cache, not a forever cache. It is a runtime memory-only cache for the one current request, as presumably the same exact form instance won't be processed multiple times in the same request (or at least shouldn't be). The reason for the cache value is that it has to recursively iterate through every single Inputfield in the form to ask each whether it had any errors. For a large form, it can be enough overhead to warrant caching that information, as the method may get called multiple times in the request and have to repeat the same task. But is it worthwhile enough? Maybe not, given your use case. I'll look into dropping it. When you set an error, it will remain in the session until it is displayed. This is because redirects are often involved in forms, in order to prevent re-post by re-load. Form errors would be lost if they weren't remembered until used. This is because the process() method determines if there are errors and returns true (no errors) or false (errors). The processInput() method does not tell you that information and so you'd have to check for errors manually afterwards. So your first example is checking for errors BEFORE you have manually added an error to it (which is what the process method does, and sets that cache), while your second example checks for errors AFTER you have manually added an error. This is why the results are different. Unrelated, but I recommend putting "<?php namespace ProcessWire;" (or any namespace) at the top of your template file, OR setting $config->templateCompile = false; in your /site/config.php file, just so that PW doesn't attempt to unnecessarily compile your template files. Maybe you are already doing this, but just mentioning it just in case.

@kalimati That file is not actually included in the module. When you install the module, it downloads the Google Client API library directly from Google. It looks like there's a bug in the version you have installed. Actually, I remember that one, they had the arguments in the wrong order for an implode() call. That's a simple one to fix if you want to edit the file yourself. Another option would be to upgrade the library. https://github.com/googleapis/google-api-php-client/releases/ You can check the box to change the version in the module settings, but unless you are also seeing other errors, I would probably just edit the Resource.php file directly and fix it, so that you don't have to go through re-authenticate. Here's the change to make on line 297 of /site/assets/GoogleClientAPI/google-api-php-client/src/Google/Service/Resource.php // $requestUrl .= '?' . implode($queryVars, '&'); // OLD $requestUrl .= '?' . implode('&', $queryVars); // NEW

@bernhard I don't think there's much crossover between Drupal and PW on the software side, but I think there are other similarities. I did develop in Drupal for awhile (before ProcessWire) and while I liked it, I don't think ProcessWire inherited many ideas from Drupal on the technical side, other than some of its directory names. I thought Drupal already did a good job of doing things its own way, and I saw no reason to follow a similar path. I wasn't going to be able to make a better Drupal than Drupal. Not to mention, some of my own preferences also made me not enjoy working in it as much as some others do. Instead, I'd say it helped to cement some of strategies in ProcessWire to be the opposite of those in Drupal, because it seemed like there was more opportunity there, and more consistent with the way I wanted to work with the tool. For instance, at least at the time, Drupal's output/markup was really mixed around in lots of different files and components, and it seemed very opinionated about how it should all work. While that's great for being able to plug in components and use things in a more turn-key and consistent fashion, I found it challenging for the way I wanted to use it, as much designer as developer at the time, and especially on an e-commerce site I had to build and maintain. So that's why ProcessWire is very non-opinionated about how you handle your output and markup, and why it's always been largely markup agnostic. That's just one example of many things. But what I really liked about Drupal was the community behind it and how passionate people were about using it. To them it was not just a software, but a timeless tool with many facets and uses, one that you could build anything in, at any scale, and that had a real following, positive reputation and quality community. I thought it would be great if ProcessWire was similar in those respects.

@LMD I think maybe this is what you want? This is saying to match template=repeater_gallery on the first argument to the method: $wire->addHook('Pages::saveReady(template=repeater_gallery)', function($event) { $page = $event->arguments(0); $event->message("Saving page with template=$page->template"); });

The new dev branch version 3.0.222 contains about 20 commits and 16 issue resolutions. In terms of new features, last week I mentioned some upgrades to WireHttp, and below are this week's additions: Multi-language month and day names The WireDateTime class (aka the $datetime API variable) has been updated to support multi-language month and day names. Now all month and days are translatable in the WireDateTime file (/wire/core/WireDateTime.php). So if you request any date in a format that uses month names or abbreviations, or day names or abbreviations, they now support multi-language, whether you requested it from the wireDate() function or the $datetime API variable. ProcessWire has long supported multi-language month and day names when using a PHP version prior to 8.1 and you've requested a strftime date format that uses them. But PHP 8.1 dropped the multi-language supporting strftime() function, without leaving a suitable replacement. PHP's IntlDateFormatter can't be relied upon since it's not always compiled with PHP. But as of PW 3.0.222, now we have a suitable replacement. Though it does require you to translate the 7 days and 12 months for file /wire/core/WireDateTime.php using ProcessWire's language translation tool. Note that unlike the previous strftime() solution, the new solution no longer requires you to use strftime() format codes and you can instead use regular date formats and they will be translated automatically. New conditional hooks that match by argument type Another new addition this week is support for conditional hooks that match by argument type. I think this is especially useful combined with ProcessWire's custom page class support. It enables you to make a hook apply only to methods containing arguments of a specific type. For instance, if you had a custom page class "ProductPage" for template "product" and you wanted to capture the "Pages::saved" event for pages of that type (ProductPage) you could do so like this: $wire->addHook('Pages::saved(<ProductPage>)', function($event) { $product = $event->arguments(0); /** @var ProductPage $product */ $event->message("ProductPage '$product->title' has been saved"); }); In addition to supporting class or interface names, you can also specify regular PHP types such as <array>, <string>, <int>, <object>, etc. For more details on this type of hook see the new Conditional hooks that match argument type section of the Hooks documentation. Thanks for reading and have a great weekend!

@Divinorum I don't have the full picture of what you are querying, but my assumption is that you are finding pages that have a "price_list" (Page) field with selectable pages that each contain a "price"(integer) field. The returned pages are going to be those that have a "price_list" field, not pages that have a "price" field. I don't know what's producing the output in your screenshot, so you may have to post the code.

@Divinorum Since you are trying to match a range of prices, it looks to me like you'd want an AND condition for that price_list.price rather than an OR condition? The AND condition in your selector would be: price_list.price>=15000, price_list.price<=20000 Assuming that price_list is a Page field that lets you select multiple pages, a selector like the above says this: at least one page in your price_list field must match price>=15000 and at least one page in your price_list field must match price<=20000. It doesn't say that they have to be the same page in that set matching both of those conditions. If you want to tell it that the same exact page in that set must match both of those conditions (which seems more useful here), then prefix an "@" to both of the conditions (see subfield selectors for more details): @price_list.price>=15000, @price_list.price<=20000 For a single-page selection field, this use of "@" would not apply, as there's only ever 0 or 1 pages in the set of selected pages. Note that there is no such thing as double pipes "||" for an OR condition in selectors (from your example), but there is such thing as using 1 pipe "|" to match one field or another, or one value or another. See the Selectors doc page for more details. Also check out selector OR-groups, which I don't think are useful here, but seems like you might have been thinking of something like it when using those double pipes.

This week, work continued on our next main/master version with 8 issue fixes (see dev branch commit log). In addition, the WireHttp class was updated with new delete(), patch() and put() methods which correspond to http methods of the same name, These might be used by web services in addition to the more common GET and POST methods. In prior versions of WireHttp, you could still use delete, patch and put methods, but had to use WireHttp::send() with the $method argument set to one of them. Now that there are separate class methods for these http methods, it makes them a little simpler to use and more clear in code. It may be that you never need these methods, or it may also be that you use a web service that uses them extensively. The more web services I work with, the more I come across them, and figured it would be good for WireHttp to have more clear support for them. I know things slow down in the summer, but we haven't had many submissions to the sites directory lately. If you have launched any sites using ProcessWire in the last year or so, and haven't submitted them to our sites directory, please submit your websites to the directory when you can. We really enjoy seeing what what people are building in ProcessWire. Thanks and have a great weekend!

@Jim Bailie In addition to the options you mentioned, if you put $myObject = new MyObject(); in your /site/templates/_init.php, then $myObject will also be available to all the page templates and the _main.php file, i.e. echo $myObject->value; As a benefit, it'll be automatically excluded from template files that don't use _init.php, such as the admin.php template file. If it's something that you might need on every page/template, but not necessarily, you may want to use it as a function in /site/ready.php that constructs it on first access, and then returns the same object on any later accesses to the function: function myObject() { static $myObject = null; if($myObject === null) $myObject = new MyObject(); return $myObject; } In this case, you'd use it like as a function with () appended rather than $ prepended, i.e. echo myObject()->value; This also has the benefit of using the same object (rather than creating another) if you happen to be calling $page->render(); on other pages in your template file(s). Another option: The way that ProcessWire does it is to use API variables, and you can add your own if you want. If you go that route, put in your /site/ready.php file: $wire->wire('myObject', new MyObject()); Then $myObject is available in any template files. The downside here is that it'll also be available to template files where you might not need it, such as the admin.php template file. So you may want to create it conditionally: if($page->template->name != 'admin') { $wire->wire('myObject', new MyObject()); }

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.

Before the recent and major core updates to WireCache and Modules, we were on track to get a new main/master version out. I'd like to get back to that, as we are now 10 dev versions ahead of the main/master branch, and with some pretty good and major improvements. That's why I've been focused largely on minor issue fixes the last couple of weeks, getting into more of the fine tuning stuff, and likely will be the next couple of weeks as well. Thank you for opening issue reports as you come across stuff to report. Thanks also to @matjazp who's been helping out in the issues repo, maintaining existing reports and often helping to solve them too. I'm thinking we may have a new main/master version ready soon as July, next month. Most of next week I'll be in New Orleans attending the gymnastics nationals where my 10 year old daughter is competing. Since I'll be out of town, there likely won't be a lot of commits next week. Though there may be enough to bump to the next version, 3.0.221, I'm not sure yet. In any case, have a great weekend and week ahead!