Leaderboard

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

@bernhard - available in the latest version.

Hello ProcessWire Community! I'm thrilled to announce that RockCommerce has finally arrived! Some years ago, after building a custom shop solution, I swore I would never create another ecommerce system again. 😅 Yet here we are! After months of hard work and completely rethinking my approach, I'm confident RockCommerce will be a game-changer for ProcessWire ecommerce. I can't wait to see what you'll create with it! 🚀 This video guides you through the Quickstart Tutorial, which was written by @Sanyaissues (THANK YOU SO MUCH!!!) He rose his hand when I asked for beta-testers 💪😎 He had never done E-Commerce before and wanted to understand how it works - so I sent him a copy of RockCommerce and let him play and this is what he came up with!!! Absolutely remarkable! Hat off to him! Docs & Download: https://www.baumrock.com/rockcommerce P.S.: To celebrate the RockCommerce release, I've applied discounts to all module licenses in my shop! If you've had a successful year, this is a great opportunity to invest in yourself and potentially reduce your taxes 😉

Makes sense to me and I can see why. Those in-EU processing fees are really really good. I probably would have chosen them too if I was in your shoes haha. True, one of the things that I would anticipate is that someone/organization may already have a platform like Stripe or Square already set up with their banking and other services they use. Sometimes it might be a client expectation that is out of my/our hands 🤷‍♂️ Going to have to make it after New Years, doing some traveling. I always feel like I'm just along for the ride during the holidays (haha). Thanks again and hope you have some great holidays.

Hi all, Just a general update regarding this issues. It seems to be related to a change in a ProcessWire version (thanks @Klenkesfor confirming). I'll continue investigating after the festive season break (early January). Thanks.

Yes, good point, I don't need two different child templates. Thanks.

Glad you like it! 🙂 This was really a long way until I got there and now - finally - it feels really good and solid 🙂 Absolutely! I just built it around mollie because I knew them already and I trust them and when I compared prices they were even a bit cheaper than Stripe. Plus being in the EU that's another bonus for me. But I understand that Stripe (or any other service) might be preferable for others, so I'm super happy to add support for it to RockCommerce! Just write me a PM and let's do a meeting after Christmas?

Awesome! Thank you for all your great work!!

@bernhard Had a chance to tinker with the module today and am really enjoying it. Outstanding work on the fast and easy front end cart system! I have a question about payment providers. I see Mollie has some hard coded items in the RC module, how would I go about writing a module for a payment provider that RC would work with? Since there are so many provider options out there the ability to create modules for payment providers without you needed to do extra work on your side would be great. In my case a popular pick for payments is Stripe. I just found out that a client uses it in the billing for a platform they run, and I use it in my invoicing software as well (unrelated to PW/RC, but example of wide use). It's also difficult to adopt Mollie here with the higher fees due to being outside of the EU economic area. In my case, one year I paid Stripe ~$939+ in fees, if I was using Mollie that would cost ~$1,134+ 😵‍ luckily I don't always need to take all payments via CC but it would be even more for a real online store. Is this something that would best be handled with hooks? If the module concept is worth exploring, perhaps RC can provide an interface and some standard objects that guarantee RC gets the data it requires. Implementing new payment platforms could be super easy. <?php interface RcPaymentProcessor { /** * Submit a new payment transaction to the payment processor */ public function createPayment(RcOrder $order): RcPayment; /** * Retrieves the current state of a payment by it's processor ID */ public function getPayment(string|int $id): RcPayment; /** * Parses webhook payload, returns standardized data object */ public function parseWebhookData(string $json): RcPaymentStatus; } Then: <?php use RockCommerce\Interfaces\RcPaymentProcessor; class RcStripeProcessor extends Process implements Module, ConfigurableModule, RcPaymentProcessor { // Handles implementing required RC methods, API key/authentication, HTTP requests, libraries, etc. } Super rough sketch, but it would let RC offload webhook parsing and payment IO entirely. Long story short, it would be great to have a way for other people adapt payment providers without you having to type another line of code 😎

Hey @adrian thx for the great redirect info. I'm using it very often! Would it be hard to link the "file" cell to open up the file in the configured IDE just like all the other links work? Obviously not tremendously important but would be a lot nicer than finding the file and line in the IDE manually 🙂 Thx a lot!

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

Hey @FireWire thx for your report! Good news 🙂 This should be fixed in v1.4.3

Yes, you can do it by changing the parent page template sorting option. The child template doesn't change, only the sort option on parent page template. /blog/ sorts children: most recent first /events/ sorts children: date order ascending

The book is easy to read, kinda silly but fun. When I started reading I had zero experience with OOP, so it was funny to jump to understand "design patterns" without having an idea of the basics... BUT, it did help me to make the switch. I'm more confident now working with Custom Classes. I'm totally going to read it again from the start to interiorize the patterns (hopefully haha).