Leaderboard

PHP development has quite a momentum the last couple of years with older versions dropping out of the support line sometimes faster than users or hosting companies like. Some CMS/CMF already aligned their release cycle with PHPs cycle. Most hosting companies I know in Germany adapt quite fast to new PHP versions and often do not allow older versions more than one major release less than actual PHP version (8.x actual -> 7.x.latest last supported version). While full support for PW core for latest PHP 8.x will work quite smooth I guess, many of the third party modules are not updated regularly or are already abonded and hence may break. 10 years ago the PHP development speed was quite slow. Nowadays most hosting companies drop older PHP version anyway and you can‘t run PHP 5 on many hosts in Germany today. So I normally test my stuff with latest PHP version available and have latest 7.x for testing. I do not test anything below PHP 7.x latest anyway. So often some stuff I build won‘t run on old PHP versions. Thats why I put PHP>=8.1 in my modules.

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 ?

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

I would not recommend setting ProcessWire's PHP requirements too high. Why would that help? If anyone wants to use PHP 8.1 or higher then that's fine but why should we "punish" those who cannot switch just yet? Why would "unifying" the required minimum PHP version help in any way? You cannot "force" module developers (who share their modules for free) do that. Am I missing the point, perhaps? BTW, I always use ProcessWire two versions behind the up to date major version of PHP because I do not want to deal with deprecated issues. I do not have time for that, and it saves me tons of time not to hurry just because...

try dots $products = $pages->find("price_list.price=20");

Hey, I will try to test it with PW 3.0.220 + and make a PW 3.x namespace version of it, as I think, every PW 2.x installation that is using it, does not need more new WireMail-SMTP updates from now on. (As some or one of you suggested!) I try to do it this week! @ceberlin @Ivan Gretsky @zoeck ...

[See this post as a PUBLIC DRAFT for an upcoming post / aka thought dump] It's just a thought in my (confused) head right now... but shouldn't we, ProcessWire, the Community, and the ProcessWire Module Devs somehow focus/target a master release/version with PHP 8.1 as minimal version in the near future? Not only for ProcessWire itself but all modules. I'm not talking about ProcessWire 4.x but maybe 3.1.x or 3.2.x or something? Just to have a clear cut in some way. Almost everyone I talk to is looking for and talking about PHP 8.1. Right now there are so many fast moving parts in ProcessWire (CKEditor/TinyMCE, JS Updates, Core Modules split and moving to the database, and what not) itself and in terms of PHP 8.1 - either it works or it's somehow having issues, while everyone seems already working with it.

Oops, I'll do it again: I'll present DDEV at the next PHP Meetup Vienna in August! Also I'll record the talk so that everybody here that is not yet using DDEV can watch it on my youtube channel to get a quick impression. The title is already found thx to the help of chatgpt ? Now I ask for your input what you love about DDEV, what problems it solves for you and what you like most about it. And maybe also what you didn't like on other systems that you've used before. Where do you think does it stand out from the crowd? What does it do similar to other available options? What are those options (just to get a birds eye view)? ... I'll let the first words up to you ? Thx for your input and help ? MEMO https://processwire.com/talk/topic/27433-using-ddev-for-local-processwire-development-tips-tricks/?do=findComment&comment=234217 ngrok for mollie webhooks chatgpt poppler-utils aliases endless loop -> ddr custom docroot

Absolutely. Even though I didn't know that page was so... outdated while being up to date. Arguments for my thoughts and feelings. ? I really think the cut must be bigger - see my last post. But YES.

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

@Spinbox. Glad you got it sorted! Things look sanitized correctly. Did you see this topic as well? The docs state that InputfieldPassword::isValidPassword() (https://processwire.com/api/ref/inputfield-password/is-valid-password/: This means that it will use the password requirements set in the backend for ProcessWire users. If that suits your needs, then you could use the method as described in the post I have linked to above. If not, i.e. if you have a different set of requirements, you might have to roll out your own validation. An example is shown in the post I have linked to above. I think you should be fine with matching the requirements sent in the backend (i.e., use InputfieldPassword::isValidPassword() as is). You would need to handle cases where the password is found to be invalid (per your requirements). Hope this helps.

I can confirm the issue in PW 2.0.220. The problem seems to be with Modules::getModuleInfoVerbose(). I opened a GitHub issue here: https://github.com/processwire/processwire-issues/issues/1765

From PHP.net: https://www.php.net/manual/en/language.basic-syntax.phptags.php I read it as follows. While opening short tags can be disabled and are removed in newer versions, the shorthand echo <?= can‘t be configured, isn‘t (yet) deprecated and hence should work fine on older and latest PHP versions.

What users may not like about ddev is the need for WSL2 or Docker on Windows compared to e.g. XAMPP stack. Devs are often using Linux/Mac or Windows/WSL2 anyway, so this shouldn‘t be a big hurdle for devs, while it may be for users wanting to try stuff quickly on Windows.

That's what I experienced, yes. My short echo always works, I'm using that all over and have never every anywhere had to enable short open tags. But I've never been using <? instead of <?php and that's what I needed the settings in php.ini for! So the essence is that <? and <?= are different kind of short tags and the former is bad and the latter is good ? @Stefanowitsch

Most of the menu items are just regular pages in the page tree as well. It's the same as on the frontend, but everything that you see in the backend lives under the /admin page: So if you see the db backups page in the tree but not in the menu, it means that something is wrong with the menu. If you see no page in the tree, than it means that your menu works properly but the page does not exist. If that is the case you can try to uninstall the module, then empty the trash to be sure that nothing is left there and then reinstall the db backups module. That should create the db backups page again.

In the first page of this thread are working examples: like:

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.

Correct - let find an argument then, it was more fun to write, I like chaining things ?