Leaderboard

I think you have to do this by hand and render each page with the table. Example from the core.

I guess I found the trick: Duplicator offers a setting "Flush ZIP after quantity of MBytes" Tried setting "500" and voila, the backup finished successfully on that all-inkl server. Happy New Year!

I will take a closer look on the weekend.

Ok, I see - There is an additional check if user is guest inside the DeleteRequestPage.php on line 35 // if user is guest -> not allowed to be here -> let's redirect to the homepage $this->redirectToHomepage(true); If you comment this out, it should work. I will add a new setting in the backend config, where you can choose if the page should be public reachable or not. For now, commenting out this code line should help you.

When I encountered the problem, the limitation was execution time, not file size. Their helpful support can certainly tell you more.

The hooks info that Tracy shows is basically a copy of what is shown in PW's Debug Mode Tools (using getHooks()) and AFAIK it's only hooks that are triggered by AddHookAfter/Before calls. From what I can tell what Bernhard is showing is all hooks that are run as PW is booting up - there are lots of entries missing in that list. Not saying that it's not a useful list, but they are very different things. Unfortunately it seems that Tracy isn't available at the point that runHooks() is called, so I couldn't replace your log file approach with a bd() call so at the moment it will need Ryan's input to make it possible to display this list in Tracy.

We’ve been building web site with ProcessWire since 2013. ProcessWire serves to us as a secure, reliable platform, and honestly, I don’t remember any significant issue after 11 years of daily use (for us, PW is also a CRM). The magic of ProcessWire is that it is always growing with our needs and serves any unimaginable demand that our platform has had. All these years, our business has grown around ProcessWire, and as it usually happens, popularity brings the other side of the coin. In our case, it was online fraud and scammers. Our first approach was to use existing fraud prevention systems, but as our business is not pure e-commerce and fraud was indirect, there was no solution that matched our needs, so we started developing our system from scratch. This is where I exactly understood how ProcessWire and the community really hooked me. (-: First of all, taking ProcessWire as an example, we decided not to heavily rely on frameworks. It was a hard decision, because new school engineers like to bring as many dependencies as possible, but I continuously pointed to ProcessWire, and as a result, we created a fraud prevention/user behaviour analytics platform with ~4 PHP dependencies. The second decision that we took, looking at ProcessWire, was even harder than the first. The fraud prevention market, in contrast with CRM, is not widely targeted for open source software, but taking ProcessWire as an example, we decided to open source our system after ~8,000 engineer-hours under the AGPL license. For sure, after being open-sourced for one week, it's premature to give any feedback, and it is highly possible that open sourcing was a mistake. However, it brings me to the understanding that the real measure of software is not downloads or stars, but its influence over other developers, and from them onto other developers, like ripples on the water. From this perspective, I am infinitely grateful to @ryan, @Ivan Gretsky, @Soma, and every person behind the ProcessWire community for all the inspiration through these years. I'm so grateful that 11 years ago I met this community and had the chance to work with some of you. As I'm more reader than writer, I would like to use this rare opportunity to wish the ProcessWire community and your families a Merry Christmas and all the best in the New Year! Best Alex P.S. While this post is not intended to be an advertisement, if someone from community is facing challenges related to online fraud, user spam, or security, please feel free to contact me directly.

This week the dev branch version has been bumped up to 3.0.243. Relative to the previous, this has 30 commits, including a lot of minor issue fixes. The plan is to release the next main/master version of ProcessWire on or before New Years day. We’re down to very few new issues being reported, and even fewer resulting in code changes on the dev branch, which is a good sign the new version is ready, or very close to it. This week while working on a site I realized that the $config->maxUrlSegments setting was not working, and I don’t think it has since the PagesRequest and PagePathFinder classes were introduced into the core. So I fixed that, while also updating some of the logic around it, and adding a new $config->longUrlResponse setting that lets you specify how it should respond when it gets too many URL segments, too long of a URL, too much path depth, etc. Next week I’ll be working on updating materials related to the new version (README file, etc.) and keeping an eye out for any newly other reported issues. Thanks for reading and Merry Christmas / Happy Holidays!

We had a chat a bit with @Ivan Gretsky and understood that probably I need to complete our story with more details. Unlike common images of start-ups, this is not fun at all. As mentioned, we developed this system bootstrapped for 1,000 days with a remote team of 11 (4 female, 7 male) from Ukraine, Georgia, Netherlands, Germany, Switzerland, Poland, and Thailand. My second son was born during this period, and I was literally working on this with a baby in one hand and a laptop in the other. We lost connection with our lead developer, as he was in Kharkiv (Ukraine). We haven’t had a connection with him since July, but I sincerely hope he is safe… If someone had told me that it would take 1,000 days (I had planned for three times less) and several thousand engineer hours, I probably would have never started this development, as it looked so unreal. It took approximately half the time to develop the system itself and another half to debug it to the condition it has now. Of course, during this development, we had to rewrite everything from nearly scratch several times, and it still doesn’t look perfect, but at some point, we understood that it is impossible to develop the code on our own and we need to share it with the community. The code release itself was quite a journey. Especially the last weeks, days, and, most difficult of all, the last hours. Arina (our junior lead developer) and me spent all day in a smoke-filled bar in Belgrade polishing the last version prior to release. And, of course, at the very last moment, we found a very unusual error that was extremely difficult to debug at 1AM. And at 6AM, I had to rush to the airport. There was a 37.5cl bottle of champagne for the three of us: myself, Arina and our director (photo attached), and despite popular images of startups, there was no party at all, only a pretty intensive and really hard time prior to release. So my advise for everyone whom working on large code base are following: - multiply every realistic time estimation for three; - have always backup for lead developer; - be ready to release the code better soon than later, as it will never be accomplished. I write this here now because I wish to learn this before starting this journey. Of-course I expect that there another bunch of rakes around that only waiting for it’s time P.S. If someone could share simple user tracking event module for ProcessWire that we can adopt for use with tirreno, it would be highly appreciated. I was not aware how stars are important for GitHub ranking, so would like kindly ask to put one if you see this software helpful: https://github.com/TirrenoTechnologies/tirreno

For such cases, even more readability: $wire->addHookAfter('Pages::saveReady(template=news)', function($event) { // [...] } This way, the hook doesn't even get called if template isn't news. Also, I think you can even get rid of the second guard clause like this: $wire->addHookAfter('Pages::saveReady(template=news,day!=)', function($event) { // [...] } If the page doesn't have a day field, the selector doesn't match and the hook isn't called. This is untested though 😊