Leaderboard

Yes, that's one of the reasons I chose them over Stripe 🙂 But for developers outside of the EU I think adding other providers should be simple enough, but that's just guessing at the moment. Maybe @Jonathan Lahijani can tell me more when we meet. Puh... that's a little tough question 😄 The short answer is: I think RockCommerce should be great for any kind of shop. The longer answer: RockCommerce is built in a way that it provides all the tools that you need to cover all the necessary steps that you need for e-commerce: Product pages Product pages add to cart button a cart a checkout BUT: These pages have to be built by the developer. So there will not be any predefined cart page, no predefined checkout, no predefined product layout. Nothing (on the frontend, of course!). Just the tools to make building that very easy and enjoyable. I think this is what @Sanyaissues and @gebeer meant when they said "the processwire way to do e-commerce" (what I nice statement, thank you!!!) So RockCommerce will get everything in place on the backend so that we as a developer can build the shop on the frontend the way we want. Using Bootstrap, using UIkit, using TailwindCSS, whatever. Easy Example: This is all you need to display items that are in the cart: <template x-for='item in items'> <div><!-- x-for must have one root element! --> <h3 x-text='item.title'></h3> <div>Amount: <span x-text='item.amount'></span></div> <div>Variation: <span x-text='item.variation'></span></div> </div> </template> And this is all you need to add a product to the cart: <a @click.prevent="addToCart">Add To Cart</a> Want to show the cart count anywhere on your page? <div rc-cart-count>0</div> And you can customize that 100% to your needs - just keep the AlpineJS attributes like "x-text" or @click and you'll be fine 😎 So why is that related to your question? It's still some work and that work has to be done and that work has to be paid, after all. So there might be a "break even" in terms of project size or budget. But from a technical point of view I don't think that there are shops that are too small for RockCommerce or that are too big. RockCommerce should scale with your needs just like ProcessWire does. But the number of products? Should not really matter, if you know how to deal with that number on the frontend. Sales volume per year? Well... Your work to implement it and the RockCommerce one-time license fee has to be covered, that's it. There will be limitations in terms of features, of course. For example coupon codes are not implemented yet (but it's built to support them) and there is no inventory management at the moment (though you could add a textfield to every product that shows something like "available within 1-3 days / 1 week / sold-out "). I think for smaller shops this can be a great opportunity, because you can create extremely light weight and efficient, well integrated processes. No bloated shop interface with 100 distracting informations or popups or slowly loading pages. You only add what you really need. The ProcessWire way 🙂 At least that's what I try! 😇

A combustion engine does not need to be overly complicated either. It is not a ProcessWire, but it used to do its job as well (and if needed, my father could fix it on his own while on the road). https://www.trabant-szene-fuerth.de/Fahrzeuge/Trabant/trabantmotor.htm https://www.bhlingual.com/east-germanys-trabant-peoples-car-a-reprieve-blog

Just wrapped up an epic RockCommerce meeting! 🤓💻 We dove so deep into nerd talk, I think I saw binary code floating by at one point. Pretty sure we accidentally invented three new programming languages and a quantum computer while we were at it. Big thanks to everyone for their feedback and help! 🙂 Stay tuned, fellow wire-processors! This community rocks! 🎸 😎

I got great input from @BrendonKoz and @monollonom (and others) in the thread about RockCalendar development, so I thought I'd start a thread for RockCommerce too, as this module is finally taking shape 🚀 Today I implemented automatic image changing when a color option of the product is changed. This is so great, I had to share that!!! 😍 Now what is so great about this? The implementation! It will work with ANY frontend. Really. No matter if you are using Tailwind, UIkit, Bootstrap, whatever. All you have to do is to add a simple hook: // set image according to selected option ProcessWire.addHookAfter("RcVariationOption::enable", (event) => { // get the RcVariationOption instance const option = event.object; // get the image number from client input that is stored in rc-image attribute const image = parseInt(option.$rcattr("rc-image")); if (isNaN(image)) return; // find the thumbnail link and click it const index = image - 1; const link = document.querySelector( ".shop-gallery [uk-slideshow-item='" + index + "'] a" ); if (link) link.click(); }); Isn't that JavaScript code, you might ask? YES! 😎 I have totally refactored the JS implementation over the last week so that RockCommerce now uses the powerful concepts of Hooks that we know from PHP but in the JS world!! (See Let's bring hooks to JavaScript) I am in contact with Ryan to add this to the core once it is tested more. But so far it is really a pleasure to work with on both sides: First, when developing RockCommerce all I had to do to make the above shown hook possible is to make the enable() method of the RcVariationOption hookable by simply renaming it to ___enable() Second, it's also great for anybody using this module, as you can not only LISTEN to those events but you can also totally change the return value or even completely replace it's implementation. For example this is what I use to show custom prices based on the taxrate of the user visiting the website: ProcessWire.addHookAfter("RcProduct::priceTotal", (event) => { // get the money object // it's not a float, because 0.1 + 0.2 !== 0.3 in binary world! const money = event.return; // return the initial price plus the added tax event.return = money.times(1 + RockCommerce.getTaxrate() / 100); }); I've only been working with this new concept for a few days, but I already love it and can't believe I haven't implemented before! The next part to tackle is the cart 🤯😅 I'll keep you posted! PS: Anybody having an e-commerce project coming up or anybody interested in beta testing? Let's get in touch!

Hey all! I've been creating new block/widget buttons for the current project I'm working on and wanted to share them in case they may be useful to others. They're SVGs intended to complement the style of buttons that come with RockPageBuilder. This post has been updated with a link to a Github repository containing all of the buttons currently available. New buttons have been added. Existing buttons have have been tweaked for quality and consistency. Download from or fork the Builder Buttons Github repository Rather than keep this post up to date with every button that is added, visit the Github repo to see the most current example and download/clone buttons for use in your projects. Buttons include: Accordion Announcement Articles Audio Bios Call To Action Card Over Image Code/Embed Events Image Image Carousel Image Mosaic Image Roll List Lists Products Reviews Video Weather Preview (not in order of list) If you find them useful, let me know what you think!

That's great. Stripe Seamless Integration Stripe Payment Element PayPal Seamless Integration PayPal Standard Checkout PayPal Advanced Checkout

Better than what? It's already built that way... And the first module is RockMollie, but as I said this doesn't need to be the only one and others should be easy to add. It would be great if you can explain how that works!

That's a great outlook and scope for this module I can wrap my head around. The ProcessWire way of doing things is great, yet the heavy lifting is done by the module already - see mollie and parts for cart and checkout pages. I will have to look into this again for sure.

@bernhard Mollie is supported ONLY on 32 countries and half of them are required to have a minimum sales volume. You will instantly exclude potential customers from many countries including USA. More info here. Stripe is supported on 50 countries and PayPal on more than 200. I think it will be better if you create a system with external payment modules where the RockCommerce clients will be able to use your ready-made payment modules for Mollie, Stripe, PayPal or they can create their own for any other payment provider. I don't know if Mollie supports it but PayPal and Stripe supports seamless integration too. The user completes the payment without leaving the client's website which is by far the best solution. I'm still a Padloper 1 user and created my own modules to do that for PayPal and Stripe (I haven't released it yet).

Ok, this already answers all my questions. And yes, that makes sense. Using mollie already seems to be everything necessary - as they provide access to/through all major credit cards, Apple and Google Pay, and PayPal as well. Big plus: they are from the Netherlands, therefore EU. I was worried I had to connect PayPal, Stripe, and/or similar on my own. But with mollie... 👍🏻 Just another question: At what point would you consider RockCommerce be useful for a project, at which amount of products or what sales volume per year? Asking for clients like small barber shops and similar, or a fitness coach with sport courses?

Hey @wbmnfktr thx you for your question. The first version will work with mollie.com, as this is the service I'm using. After checkout RockCommerce will contact mollie and create a payment link. Then RockCommerce will send the customer to the payment page, which looks like this: https://www.mollie.com/checkout/select-method/6FCyMPgi83 After payment Mollie will redirect back to RockCommerce and RockCommerce will change the payment status of the order. Everything else is up to the developer and can be done via hooks (eg create an invoice or send an email or send data to a CRM system etc.) So RockCommerce will support any payment method that mollie supports and the client can just select the payment methods he wants on their dashboard: I think the process should be the same with stripe or others, but I'm not sure and @Sanyaissues will look into this. Or if you have experience with that let's connect! Not sure what you mean? The customer will have to create an account at mollie.com (or stripe or whatever is requested in the future) Does that make sense?

I just watched a video about e-mobility and comparison of different energy sources like petrol, e-fules and batteries. Don't want to start a discussion here as it would also violate forum rules, but seeing this picture I thought this look so much like the comparison between a typical WordPress site compared to a typical ProcessWire site 😄

Hey @Stefanowitsch another update 😍 RockCalendar v1.2.0 is now translated to German (and Finnish, if AI did a good job 😄 ) https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/translations/ If you find anything that is not translated yet please let me know!

Just pushed v1.1.1 which fixes an interesting bug that @Stefanowitsch sent me via video that showed up when multiple checkboxes have been checked (eg on weekdays mo+tu+we...). Interestingly it only happened when MO was selected together with other days. The reason was that my reactive GUI unintentionally updated the "value" attribute of the first checkbox whenever other checkboxes have been checked. So the value of the first checkbox was not "mo" but "mo,tu" or "mo,tu,we" etc. 😄 That's now fixed and the value of the "mo" checkbox stays "mo" whatever other checkboxes are selected or not 😎

Ah! Now I get it 🙂 That makes a lot of sense. I'll try to come up with something useful as soon as possible, thx 🙂

Sorry! I meant it would be easier for editor users, if the blocks in the page editor could have the same order as they have initially regarding to the given layout of the page. For example let's say every page always starts with a HeroImage, but the corresponding block would be the fifth in the list of available blocks. So the editors will have to search through the blocks to find the right one to start with, and so on. Of course, they can move the blocks around. But in my experience, they won't do that. They will always follow the same order of blocks. Therefore, I thought they would benefit from pre-sorted blocks, as they can go through them from left to right. Or am I misunderstanding something? I meant the sort order of the "create new block of type XY" icons. 🙂

Thank you very much @FireWire I've added them to the repo and they will be part of the next release ❤️

Thank you for joining. I agree, RockCommerce looks promising and gives developers lots of freedom on how to implement things. Just the way PW devs love it :-)

Thanks and nice to meet you both @gebeer and @bernhard! RockCommerce looks so promising, it really feels like the procceswire way to do e-commerce.

@Stefanowitsch is already implementing the module in the mentioned Project: Now the question arose how one could add an event schedule like "Every last Friday of the Month" With the current settings this was not possible: Version 1.1.0 adds some more options to the dropdown 😎 https://www.baumrock.com/releases/rockcalendar/

Thanks for a great explanation (as always). I guessed almost everything) I also place the source scss/js in templates/static. Before that I used to put the sources in site/static-src and put the generated files in templates/static. I guess, resources could be a better name for the sources. At least it is a standard place to have them as I use Wireframe (and love it).

I wrote this a while back for my company's internal documentation and just realized it might be a benefit to others on the forum, so here it is! Checking whether a field was changed To check whether a specific field was changed you can do $page->isChanged(‘field’). This can only be done before Pages::save, since the save clears change tracking by default. Getting the values of a page before they were changed, from within a hook before Pages::save Method 1: The hacky way $clone = clone($page); $e->wire('pages')->uncache($clone); $oldP = $e->wire('pages')->get($clone->id); $oldP then represents the page and all its values as they were before any changes were made. Again, this will only work for hooks that run prior to Pages::save. Method 2: Using change tracking to get the old values If change tracking is set to track values, then the above is not necessary. In this case, calling $page->getChanges(true) will return an associative array of fields that changed and each field's prior value. Note that the value itself is also an array, since it is designed to be able to track multiple changes over the course of a single request/response cycle. Tracking of values is turned off by default (for efficiency sake), and there is no global switch to turn it on and off. To enable tracking of values, you must call $page->setTrackChanges(Wire::trackChangesOn | Wire::trackChangesValues) before any changes are made to the page that you want to track. Here is an example of how you can enable value tracking in ProcessWire's page editor: $this->addHookBefore("ProcessPageEdit::execute", null, function($e) { $p = $e->pages->get((int)$e->input->get('id')); if($p->template == 'event-registration') { $p->setTrackChanges(Wire::trackChangesOn | Wire::trackChangesValues); } }); Running hooks on both page saves and field saves Please note that using the following hooks is preferable if you want the hook to run both when individual fields are saved as well as the whole page: Pages::savePageOrFieldReady https://processwire.com/api/ref/pages/save-page-or-field-ready/ (for before a save) Pages::savedPageOrField https://processwire.com/api/ref/pages/saved-page-or-field/ (for after a save) Getting changes in a hook after Pages::save Note the $changes parameter passed to Pages::saved and Pages::savedPageOrField allows you to check which fields were changed during the save, even though the save is already completed. Using this is sometimes preferable to using a Pages::saveReady or Pages::savePageOrFieldReady hook since you don’t have to worry about the page cache or something else in your code preventing the original save from completing. A $values array is also provided, which is populated only if change tracking is set to track values (see above) Page cache issues when hooking before Pages::save Page cache issues may occur when you try to save another page inside of a before save hook (Pages::saveReady or Pages::save). A page save normally clears the entire page cache, which means any page fields on the page you were originally trying to save will have their values reset. So if you have to save another page inside of a before save hook, just use $page->save([‘uncacheAll’ => false]) to prevent the cache from being cleared. Preventing hooks from running on a particular save To prevent any hooks from running on a particular page save, you can use $pages->save($page, [‘noHooks’ => true])

https://www.youtube.com/@TheSegi86

?

A module for generating and serving AVIF files:

Sure – where I work at we did exactly that, and haven't looked back since. First of all, it's important to understand that at it's core ProcessWire is a (web) application framework. We prefer to call it a content management framework, but that's not very far from what most web applications do: they store, process, and output content. The way I see it, the main difference to so-called traditional frameworks is that modelling and handling data is a built-in feature, not something you have to reinvent on a case-by-case basis. I have rebuilt a couple of old projects from the scratch using ProcessWire, and in all of those cases this has saved me a lot of time and made most of the model layer obsolete. Before we started using ProcessWire we were doing sites with another CMS and custom applications with Zend Framework. At the beginning I had this idea that we would use ZF for "apps" and ProcessWire for "sites", but in just a few short months we realised that there just wasn't anything we could achieve with ZF that couldn't be done, usually with less work, with ProcessWire. Sure, sometimes we pull other libraries into the mix, but that's not a shortcoming; in my opinion it's just good design Regarding some of the things that have been mentioned here: One thing I was originally missing from Zend Framework was a clearly defined structure. Built-in "one file per template" concept is great for simple sites, but that's just about it. This is why I built the original version of my MVC project. It's not perfect, but it has served us well for years. To get most out of ProcessWire you really should be using it's data modelling abilities. Sure, you can still mock up your own data structures and write SQL to fetch content from the database etc. but that's kind of missing the point: ProcessWire makes data modelling a breeze and the selector engine is both flexible and secure. Some users prefer to build custom management panels, but in my opinion that's another thing you should try to avoid. ProcessWire's admin GUI is flexible and extendable (see Process modules), and again: in most moderately sized projects it can easily save you days of work. For routing you can use page URLs, but I'd also suggest looking into URL segments. For me, coming from the world of Zend Framework, templates are a lot like controllers and URL segments make it easy to implement the concept of actions Try not to invent your own access management system. ProcessWire has a very good implementation of RBAC already in place, and if you need more flexibility, I'd suggest looking into modules such as Dynamic Roles and/or User Groups. Rolling out your own solution is risky, tends to cost a lot, and just generally speaking is a very bad idea. Form validation has been mentioned twice here already. I don't have much insight into this, except that in the beginning we used to build forms using Zend Form, which has it's own validation built-in. That was always a bit tricky (not because of ProcessWire), and these days we use Form Builder for pretty much every form-related need. Sure, it's a commercial module, but it has saved us so much time that the price is absolutely not an issue. In my opinion the answer to your original question is yes and no: ProcessWire can't substitute an application framework because it is an application framework