bernhard

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

There are many possible solutions and it depends how you implemented these forms and how you submit the data so it would be good to share some more details here ?

Hey @Greg Lumley great to hear that, thx ? There is a latte extension for VSCode. It's not perfect, but it's ok: Also there is no proper intellisense/code completion in latte files which is a pity, but I try to keep my latte files as clean as possible and put all the logic in the custom page class or in my Site.module.php so latte files are really just some simple markup and calling {$obj->method()} which is something that I can manage without typos most of the time ?

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!

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 ?

Thx for your input so far! I'd definitely not thought of many of these points ?

Great to hear that, thx for sharing! I'm quite surprised, but that's a nice example that it makes sense to keep it alive besides findRaw ?

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 ?

Referencing the topic in the PUB here and I invite everybody to give me some input for my next talk about DDEV @ PHP Meetup Vienna ?

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

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

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 ?

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.

I have a question here: I've always been using short tags for echo like <?= $foo ?> and never had a problem. Now on these external projects I had short open tags like <? ... ?> and suddenly things broke. Can anybody explain why short echo worked but short open did not? I thought that's the same thing?

I had two projects in the last 2 weeks making problems due to using short php tags. DDEV has you covered! Just put this short_open_tag = 1 into .ddev/php/my-php.ini and do "ddev restart" ?

And again! Added the ini settings and went instantly from 83MB to 2.7MB ? I've created an issue here, because I think that ryan is simply not aware of that and it should not be too hard to fix I guess/hope: https://github.com/processwire/processwire-issues/issues/1760 Like it if you want to support the request ?

Cool ? Yeah and even if it didn't work it would not break the site but just be a little harder to read ?

Hey @FireWire could you please remove the link - the video is not intended for the public yet as it is a commercial module and I don't have infrastructure in place to sell the module ? Thanks for the kind words @FireWire your feedback means a lot to me especially in the context of this thread and your previous posts ? It can actually do a lot more than that. It could also be used for building a custom newsletter tool or a tool where clients can build their own PDF reports with flexible building blocks. I hope to get everything done soon, but there is still a lot to do ?

Unfortunately I'm quite sure with that. It's the same with external loaded Google Fonts which means that adding youtube iframes with the nocookie options is also not ok. Unfortunately. The problem is that google says they don't store anything but that's (for good reasons) not enough for GDPR. So the only clean solution is to make sure that no personal data goes to whatever external party and yes, the IP address is also considered to be personal data. Whether all that makes sense or not is a different question, because - as Google said itself regarding that topic - that's how the internet works. Saving youtube's preview images on your own server on the other hand might also be problematic because it could violate there terms of use. But personally I consider the risk of google complaining about that much smaller than getting a letter from some crazy lawyer because of not properly including some third party services. Great ?

I hope you already asked @adrian ?

Hey @zx80 congrats again ? I've read the text and while reading I thought: "Maybe it would be nice to have the "hidden" class configurable, so that for example when using uikit for the frontend one could simply use the uk-hidden class so there is no need for an additional stylesheet. Then I thought: Why not just use the "hidden" attribute instead? Did you think of that? Or would that prevent the whole principle from working? I'll likely add a similar feature to RockFrontend one day so feel free to ignore this idea. But I'd still be interested in your opinion about it ?

Great. Thanks for all your input ?

What do you think would be the benefit compared to using curl_multi? It definitely looks awesome and I've been following ReactPHP for quite a long time, but it also feels a lot more complex than just adding a cronjob and boostrapping PW ?

Thx @monollonom makes sense ? Actually I'm also not using that approach any more because I'm using RockPageBuilder which works similar to RepeaterMatrix where clients have several blocks of content and actually this module seems to be a perfect fit for such use cases! I've already built custom solutions for grabbing youtube preview images because I didn't know this module existed or more importantly didn't know how it can be used: https://github.com/baumrock/RockVideoThumbnailGrabber @Neue Rituale what I'd still be interested is how the module caches data? I guess it only caches the json response from eg the youtube video? So if I used that image url in my websites markup it would generate an external request that violates GDPR if I have no prior consent. Does it work like this or is there an option to download the image and store it in a PW image field? I didn't see anything like this in the readme. Wouldn't that be something nice to have? ?

Ok thx for the clarification ? Thx! I've just did a quick test on my VPS and it took 11s to fire 140 requests without any caps in place (no timeout, no max concurrency limit). htop showed one cpu core maxed out at 100% during that request. I thought that might come from the do/while so I've added a usleep() of 100ms into the loop but that made no difference (neither in the overall time needed nor in the cpu usage).