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!

Finally solved dudes! You almost hit the point. I did all you suggested and nothing worked, but the key was delete all entries of the table "caches" without delete /site/assets/cache. After that, click refresh button until all modules get included on caches table again. Somehow the host provider messed up something during their updates. Thank you all for the help and suggestions. Now I can sleep very well!

In the newly released v0.3.0 you can also quickly toggle the "required" state of fields in a template, Repeater, etc, by clicking the asterisk icon next to the field label.

@BacosThanks for posting your solution. May come in handy for others experiencing similar issues.

Ryan has pushed a fix for this in the latest DEV that seems to solve the problem for me ? @Ivan Gretsky does it also work for you?

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

Excellent. Thanks for your reply on that topic.

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.

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 ?

My wording "required" wasn't good. Looking at competitors I think it should be maybe: Minimum PHP 7.2 or PHP 7.4. Recommended PHP 8. If you still use PHP 5 in 2023 I think you should search help. ? Thank you for making things clear. I understood your first sentence exactly, that you had experienced those issues with PW, which is not my experience at all. I also think that GitHub branches in general should try to target no warning/errors or blank pages. Regarding PW that is already the case in my opinion.

@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.

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

Congrats to your daughter and thanks for letting us participate in that!

@PWaddict Yes, I was looking into this with a non-recaptcha form. I've got probably a dozen or more sites using SimpleContactForm, some probably now updated to 3.0.2xx, so I'd like to solve this! Yesterday, I noticed this error in TracyDebugger: PHP Notice: Undefined offset: 0 in .../modules/SimpleContactForm/SimpleContactForm.module:238 So when I get a chance, I'll try to see what that's all about.

Also worth noting:

Well the table entries are simple enough, so I'm going to just try removing them. I'll report back if my site implodes, but I suspect it will be fine. ?

Hi, May I ask where you are in the publication of this module ? I am very interested, and it would bother me to have to delve into programming such a function on my own if it is about to be released. Thank you in advance.

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 ?.

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.

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

That was just my attempt of being funny. I thought the smiley would make it clear, but of course I don't want to blame or disrespect anybody. ? If you have reasons to use a PHP version, which had its end of life 4 years and 5 month ago, this is fine. Like you said it is your own decision.

I don't like this statement either. ProcessWire is a timeless tool and does care a lot about long time support. That's something great! We should not blame anybody for not being on the latest and greatest versions. But we should make clear, that this is not the recommendation and it's everybody's own decision and risk. Like having some food where the expiry date is over. It's perfectly fine if you are alone and you smell it and decide to eat it. But it's a different story if you sell food to others!

In a perfect life, yes. But is it perfect? :) Jokes aside, as PHP development has been speeding up recently, I do not think it is realistic to expect Ryan and module developers to keep up with that pace. Luckily, I do not have such an experience but I would blame hosting companies for being so rigid. It is not they who have the burden to upgrade PHP websites to be able to run on PHP 8.1 or higher, so why do they force anyone to do that in the first place? I would also blame the PHP core team for not providing security fixes beyond one year: https://www.php.net/supported-versions.php While I agree that new features in PHP are welcome, I do not think they are so essential that I could not live without them for a few years more, if I wanted to. "if it ain't broke, don't fix it"

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. ❤️

Even if you don‘t set/increase PW minimum required PHP version, the PW Github dev branch should be running PHP 7.x up to latest PHP 8.2.x at least without throwing warnings or even worse errors or a white page of death. Modules could than be tested and maybe a compatibility list could be set up for those older modules showing warnings or worse wouldn‘t run on latest PHP versions. Minimum PHP version guaranteed to work without warnings and errors (core) should be latest PHP 8.1.x, as most hosting companies allow at least to choose between the PHP version not having reached EOL yet. For upcoming PHP 8.3 the 2nd alpha is already available.

Ideas what I'd try: create a backup from what you have so that you don't make it worse (files + db) delete /site/assets/cache to make pw force to recreate everything, maybe something is messed up there do a modules refresh and also if tracy is installed do a "clear sessions, cookies and modules refresh" try different endpoints (ingocnito window, logged in vs. guest, frontend vs. backend) if nothing works or helps try to install a fresh version of PW on that host - maybe the installation process will give you some warnings of anything not working You could also copy everything to a local dev environment and see if it works there or if you get any new insights. Don't think that it's something that should prevent you from sleeping ?

New month, new version: https://github.com/baumrock/RockMigrations/releases/tag/v3.26.0 Bug Fixes double linebreaks (bf07c6b) magicpages comparing classnames without namespaces (28b5657) prevent migrating pageclasses twice (b3c9add) remove double slash when using $this->path (aa9502c) wirerandom issue on deployment (29bd145) Features add placeBefore to wrapFields() (906753c) add random salts to config-local suggestion (1e7401c) add rm-hints to field and template gui (27b5b25) add support for parent_id as page path (e45e430) imporve createPage for array syntax (74bd338) improve getTemplate (use ::tpl fallback) (b6f6d14) improve isDDEV() (e4df541) improve setFieldData() method (2830eed) use $this->path instead of DIR #22 (f134e1b) One very nice feature is that RockMigrations now adds uikit tooltips to the field and template editor where you can directly inspect the name of the property to use and also the value of one setting, which is very handy if you need a setting that you don't know by heart. With this update you don't need to find the setting by inspecting the html markup any more and you can instantly see it by hovering over the setting:

Good day @BitPoet! This module doesn't seem to work with latest FormBuilder. Are you planning to maintain it and fix issues? Maybe there is already a newer version, just not in the repo?

Well, you can just send your POST request in such a way that the Json will be available as $input->post['myData'], that is, as FormData or UrlEncoded: fetch('https://example.com', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', 'X-Requested-With': 'XMLHttpRequest' }, body: new URLSearchParams({ 'myData': JSON.stringify(someObject) }) }); or const formData = new FormData(); formData.append('myData', JSON.stringify(someObject)); fetch('https://example.com', { method: 'POST', headers: { 'X-Requested-With': 'XMLHttpRequest' }, body: formData }); If your object is just a simple key-value affair, you may actually want to send it that way and not as Json at all, because you’ll be able to use the sanitizer methods for each value. With the Json you have to parse it and then sanitize the properties, watch out for properties you didn’t want etc.

@guy You could try this: if($this->wire()->process == 'ProcessPageEdit') { // save from page editor } If you want to capture other types of page editors, like ListerPro, User Profile, etc. you could do this: if(wireInstanceOf($this->wire()->process, 'WirePageEditor')) { // save from any page editing process }

It for uikit lightbox component, resizing image and adding lightbox link automatically with overlay effect. If you don't use uikit you can remove these codes from function or you can customize them for your needs. I dind't modify my code, directly shared them with community and you can take it as example and you can modify codes or you can create a function as your needs. // Without lightbox $img = image($page->image->first(), $config->respImgOptions['villa']['list']); // With lightbox, its enought to send "true" or "overlay" class, after set responsive image settings $img = image($page->image->first(), $config->respImgOptions['villa']['list'], true); Lightbox example output : <figure class='uk-overlay uk-overlay-hover'> <picture> <!--[if IE 9]> <video style='display: none;'> <![endif]--> <source srcset='data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==' data-srcset='/site/assets/files/1058/terra-nova-003.344x212.jpg' media='(max-width: 479px)' /> <source srcset='data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==' data-srcset='/site/assets/files/1058/terra-nova-003.309x190.jpg' media='(max-width: 767px)' /> <source srcset='data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==' data-srcset='/site/assets/files/1058/terra-nova-003.265x164.jpg' media='(max-width: 959px)' /> <!--[if IE 9]> </video> <![endif]--> <img src='data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==' data-srcset='/site/assets/files/1058/terra-nova-003.290x180.jpg' alt='terra-nova-003' class="lazyload uk-responsive-width uk-overlay-spin" /> </picture> <div class='uk-overlay-panel uk-overlay-background uk-overlay-fade'></div> <div class='uk-overlay-panel uk-overlay-icon uk-overlay-fade'></div> <a class='uk-position-cover' href='/site/assets/files/1058/terra-nova-003.jpg' title='Terra Nova' data-uk-lightbox="{group:'terra-nova'}"> <span class='uk-hidden'>Terra Nova</span> </a> </figure>