Leaderboard

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.

Season's greetings ProcessWirers. My gift to you is a new module called PipeEmailToPage which you can get from GitHub here: https://github.com/MetaTunes/PipeEmailToPage/tree/main. Fairly 'alpha' at the moment, but I have been using it successfully on a live site for a week or so. I'll test it some more before releasing it to the modules library. I designed this as a replacement for ProcessEmailToPage, which relies on the flourish library which is no longer maintained. It also has a fundamentally different method of operation in that it is 'push' rather than 'pull'. The email addresses are created 'virtually' in the sense that they are not necessarily real email addresses but are held in pages whose templates are linked in the module config. The module works when emails are piped to a script (emailpipe.php) on the server which processes the email and creates the page. The pipe needs to be defined in your hosting service's cPanel or similar. If you define the pipe in the 'Default address' in cPanel, all emails sent to the domain will be processed unless they are specified separately. The 'to' addresses will be matched against the email addresses defined in 'parent' pages holding the virtual addresses. If you define the pipe for a specific email address, only emails sent to that address will be processed (but you can define the same pipe for multiple addresses). A major advantage of the module is that the email addresses can be defined entirely within PW. This means that they can be maintained by someone with no access to cPanel once the developer has set up the pipe. Further details are in the readme. I suggest you test thoroughly before using (and take careful note of the 'points to note' in the readme). Turn on some of the logging statements if you wish. Also, check your mail delivery in cPanel to look for errors there. If you report errors to me, I will do my best to hunt them, but please include as much info as possible. I will also be grateful for any suggested code improvements and/or PRs. 🎄

This week I got wrapped up in unexpected client work, but it did lead to development of a new Inputfield module, which I think I’ll be using a lot, and hoping some others might find it useful too. It’s called Small Select Multiple, and the purpose of it is to provide a multi-selection input that is as simple as a single-selection input, and that didn't introduce new UI elements, sticking just to native browser controls. It came about because a client has a large front-end form that has a lot of multi-selection inputs, which we handled with checkboxes. It started to become too much for users, so we tried changing to AsmSelect. That helped a lot, but it still became overwhelming once a lot of options were selected. We needed something that looked simple from the start, and stayed simple even after a lot of selections had been made. The Small Select Multiple input seems to do the trick. You can use this input type with Options fields or Page fields, or anywhere else you might us ProcessWire’s SelectMultiple, Checkboxes, or AsmSelect input types. Like the other Inputfield types, it’s not always going to be the right fit, and has it’s own unique set of benefits and drawbacks, but for the times where it suits the need, I hope you find it useful. Rather than writing more about it, I’ll link you to the module page for it. There’s more details and screenshots there. While you are in the modules directory, see the 3 other new modules posted this week too, they look great. Core updates coming next week. Thanks for reading and have a great weekend.

Hey @Jan Romero that's true, but it shows it in a totally different way. I wanted to have a list of all methods that I can hook into, in the order of execution! I don't know how tracy sorts the list of added hooks, but it's definitely not execution order. On the other hand tracy debugger adds nice links to the hooks and shows some more information, like for RockFrontend: after RockFrontend::addAlfredStyles() AdminStyleRock::addAlfredStyles() class method 100.0 And that line does not show up in my hooks log: cat hooks.txt | grep RockFrontend ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::render ProcessWire\RockFrontend::loadLatte ProcessWire\RockFrontend::addLiveReload RockFrontend\StylesArray::renderAssets RockFrontend\ScriptsArray::renderAssets Oh... that actually makes sense, because I have not had an ALFRED call on that page yet, so obviously the hookable method does not get called! 😄 I added it and boom, there it is: cat hooks.txt | grep RockFrontend ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::render ProcessWire\RockFrontend::loadLatte ProcessWire\RockFrontend::getIcons ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::addAlfredStyles RockFrontend\StylesArray::renderAssets RockFrontend\StylesArray::renderAssets RockFrontend\ScriptsArray::renderAssets RockFrontend\ScriptsArray::renderAssets Another one. I saved a page from the backend and the grep for "::save" looks like this: cat hooks.txt | grep ::save ProcessWire\Pages::save ProcessWire\Pages::saveReady ProcessWire\Pages::savePageOrFieldReady ProcessWire\Pages::saved ProcessWire\Pages::savedPageOrField I think this is really neat! Maybe @adrian has an idea how we could integrate this into Tracydebugger and maybe get the best of both worlds (tracy current implementation + my hacky one)? I think it would need a modification in the core, but that should not be a big deal for @ryan.

@Ivan GretskyWe cannot use proprietary code in our work. In our case, we only need the ability to catch logged-in user events (hooks?) and send them via cURL to the Tirreno endpoint. As I understood the best start point is http://modules.pw from @Nico Knoll Happy New Year for you and your team, Ivan!

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

There have been a few small bug fixes made to the core this week on the dev branch. I think we’re really close on the new version and hope to have that ready around the upcoming holidays. The module I mentioned last week (InputfieldSmallSelectMultiple) also got a new version this week with support for optgroups, support for “1 of 3 selected” type labels (Adrian’s suggestion) and a couple small fixes. Some fun news: The ProcessWire site is currently going through a redesign. This time there are a couple of professional designers and long time ProcessWire users collaborating on the design. I won’t mention who’s working on this just yet, as I’ve not asked them if I could, so want to respect their privacy. But I’ve been able to see some of the work in progress, and it’s really fantastic, a major upgrade for the look of the site. Along with this will be some visual improvements to the admin theme as well, which will accompany or come after the site redesign. There’s no launch date for the site redesign just yet, I wanted to let you know it was in progress and looking great, something to look forward to for sure. Thanks and have a great weekend!

@bernhardIn this test, I didn't want to install benchmark tools, so I just used PHP (code below) with the following results: test 1) Elapsed Processwire Boot time Apache/2.4.62: 0.1405s Page load time: 6.53 ms Database query time: 0.5 ms Memory used: 325.21 KB Elapsed Processwire Boot time nginx/1.26.1: 0.1175s Page load time: 4.68 ms Database query time: 0.65 ms Memory used: 256.13 KB test 2) Elapsed Processwire Boot time Apache/2.4.62: 0.2145s Page load time: 6.42 ms Database query time: 0.45 ms Memory used: 325.21 KB Elapsed Processwire Boot time nginx/1.26.1: 0.1512s Page load time: 4.86 ms Database query time: 0.64 ms Memory used: 256.13 KB test 3) Elapsed Processwire Boot time Apache/2.4.62: 0.1809s Page load time: 48.97 ms Database query time: 0.7 ms Memory used: 325.21 KB Elapsed Processwire Boot time nginx/1.26.1: 0.0909s Page load time: 4.65 ms Database query time: 0.64 ms Memory used: 256.13 KB <?php $home = $pages->get('/'); /** @var HomePage $home */ $start_time = microtime(true); $start_memory = memory_get_usage(); $start_query_time = microtime(true); $pages = $pages->find("template=basic-page"); $query_time = microtime(true) - $start_query_time; ?> ?><!DOCTYPE html> <!-- STANDARD >main.php body--> <?php $end_time = microtime(true); $page_load_time = $end_time - $start_time; $end_memory = memory_get_usage(); $memory_used = $end_memory - $start_memory; $elapsed = Debug::stopTimer($timer, 's'); // Debug::startTimer in index.php ?> <div> <p>Elapsed Processwire Boot time <?php echo $_SERVER['SERVER_SOFTWARE'] . ': ' . $elapsed ?><br> Page load time: <?php echo round($page_load_time * 1000, 2); ?> ms<br> Database query time: <?php echo round($query_time * 1000, 2); ?> ms<br> Memory used: <?php echo round($memory_used / 1024, 2); ?> KB</p> </div> </body> </html> Breakdown of results: Elapsed ProcessWire Boot Time: NGINX consistently shows lower boot times, indicating it may handle PHP requests more efficiently than Apache in this test case. Page Load Time: The page load time in the third test for Apache (48.97 ms) is an anomaly I can't explain. Caching? Network latency? Database Query Time: Apache and NGINX have similar query times Memory Used: Memory usage is relatively low, and the difference between the two servers is not substantial.