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!

That's very helpful - thanks!

Yes, certain system pages are forced to the bottom of the list. See ProcessPageListRenderJSON.php

1 means that $mail sent 1 message. So, we know that that succeeded. Hmm. I am at a loss about this one. Given that the hook is called an an email is sent, I have no reason to suspect that the hook is perhaps being called late. Do you know if the customer is getting the email being sent by Padloper for this same order? Secondly, just for testing could you please test with Hooking before? Are you able to please test the exact same Hook function but by hooking to another method, e.g. ___saveOrder()? Thanks.

Ok, more digging and I think I've got it. The InputfieldForm.module made at least 2 changes that effected the no-longer-supported-but-heavily-used SimpleContactForm (by me anyway): 1) it appends a hidden field at the end of your form ('$landmark', line 178). I don't know it's purpose, but I'll now see if I can subtract it from the field count in the Spam Protection of SimpleContactForm. 2) $form->getErrors() doesn't work the way it did previously. Thanks to a post by @da² that I came across, I've been able to use $form->getErrorInputfields() instead on lines 203 and 245 in the SCF.module. For now, I'll just edit the module, but maybe there's a more elegant way to do it.

Regarding the "include version in admin footer from package.json if it exists" feature - I'm a little confused about what this is for. The code points to the package.json in the site root, not the module root. https://github.com/baumrock/RockMigrations/blob/d957caeb5e4607d0b0afbb00ef18cdcb52895d83/RockMigrations.module.php#L923 But I don't think Ryan stores the processwire version there - which version number is this supposed to show? RockMigrations? My site root package.json looks like: { "dependencies": { "htmx.org": "^1.8.6", "jquery-typeahead": "^2.11.1" } } I started looking into this because I was getting a stdClass::$version warning.

@Nishant happy to hear you have your site up and running again. Out of interest, and to help try and track this down... what version of the SessionDBHandler module were you running (if you happen to know?) are you using the MyISAM or InnoDB engine in your MySQL/MariaDB installation?

Yes, I have uninstalled that module and the site seems to be working fine now. Will test for couple of more days and see if that was the primary cause.

It might be that module as it uses GET_LOCK. Is it feasable to switch this site back to using file-based sessions?

Are you running the SessionDB Handler module?

Correctamundo. This resolves this matter thank you sir

Hey @gornycreative thx for the question ? I've setup automatic version numbers (https://processwire.com/talk/topic/28235-how-to-get-fully-automated-releases-tags-changelog-and-version-numbers-for-your-module-or-processwire-project/) not only for all my modules but also for all my projects. Also I have a staging and production system for many of them and there it is nice to know with version of the project is currently deployed. Maybe staging is at 1.2.3 whereas live is still at 1.2.0 Does that make sense? Should I add an explanation somewhere or change wording to make it clearer?

Hi @netcarver, When ModuleReleaseNotes is installed the main admin headline gets removed in the config screen for ProFields InputfieldCombo and this makes the form layout a bit off too (FieldtypeCombo is similarly affected). Without ModuleReleaseNotes: With ModuleReleaseNotes: I had a quick look and traced it back to the module's hook after ProcessModule::executeEdit but nothing in there leaps out at me as the cause of the problem. Do you have ProFields so you can try and replicate? Cheers, Robin.

Hey @alexm, the value of that would have to be 'custom'. All non-payment addons must be of type 'custom'. Yes. Sorry about that. I need to state that in the docs. Does this mean your question above about 'getType()' is now sorted? Thanks.

Hey @alexm, Please clarify this. Does it mean the hook is not getting called or does it mean it is returning early (e.g. no $orderPage->id) or email not getting sent or email not getting received ?. If you did $sent = $mail->send(); and dumped $sent, what do you get back?

Also worth noting:

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 } });

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!