bernhard

Sure @flydev If anyone is wondering what this thread is about: https://baumrock.github.io/Consenty/

Well, you get all kind of weird rounding issues if you do that. Of course you could round() all results, but that is tedious and I'm not sure if that's 100% bulletproof:

Hey @Jonathan Lahijani just wanted to thank, because even though I'm sure that was not your intention, you made me remember and try out FieldsetPage. This will not only be very helpful for RockCommerce and for RockSettings, it is also a great way to make things that are under control of RockMigrations extendable by users/developers 😎 It also led to a knew PR that I just submitted: https://github.com/processwire/processwire/pull/306 Like it if you like it 😄

Hey @nurkka great we got it working 🙂 I always try my best to not introduce no breaking changes or remove things that are needed. So I encourage everyone to report what they need or use or just ask if anything is unclear or needs to be changed, like you did. I have changed the description of that feature in v5.9.1 and updated the docs to hopefully make things clear: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/blocks/#sorting-and-grouping-blocks

Thx @Jonathan Lahijani same here. Good summary. It was a very interesting talk indeed! I have lot's of things to think about. Maybe RockRabbit would have been a better name, but now it is too late 😄

Hey @nurkka just had a look and totally forgot that I added a setting for that. The reason is to not break existing installations but set a new default for new installations: Without that setting sorting will have no effect. Did you check that box?

Hey @nurkka I looked into that and I'm not sure what happened. At first I was able to reproduce this, but now I can't any more. I'm not sure, maybe my changes fixed that issue. I have removed RockLoaders as dependency as I think it should only be an enhancement but not a requirement. But as I see now your version likely didn't include RockLoaders as this was only on the dev branch. Whatever. Could you please backup everything and then remove RockForms from your project and then reinstall the newest version v2.0.0 ? https://www.baumrock.com/releases/rockforms/ I'll have to fix an issue with those loading animations provided by RockLoaders, but apart from that the module should work! If you have already created forms in /site/templates/RockForms you can leave them untouched. Just replace everything in /site/modules/RockForms Let me know how it goes!

I've added that to the docs for you some minutes ago 😉

Hey @nurkka glad if you like it 🙂 I've added docs for this question here: https://www.baumrock.com/en/processwire/modules/rockforms/docs/entries/ Does that answer your question? I'll come back to the other question later.

No, I understood that. But I didn't want to mess with the sort order and thought this would be a better and more powerful solution. For example let's say you have blocks "Gallery - Hero - Info" (sorted a-z) But for blog posts, you want editors usually add them in the order "Hero - Info - Gallery" You can now add a preset called "Default Blog Post" (or anything else) and when the user clicks on that preset it will add blocks in the order "Hero - Info - Gallery" You could then also add different presets to that page and this would not be possible with your suggested sort feature. For example you could have two presets "Default Blog Post" and "Event Blog Post" or whatever.

Interesting. I can reproduce in FireFox, but not in Chrome. Update: Ok, now I also get this in Chrome. When testing in my regular chrome window it worked without an issue, but when using an incognito window it shows the json.

Hey @AndZyk I can not reproduce this. Could you share more detailed instructions (step by step)?

Thank you @gebeer I've removed those outdated sections from the docs! Also you are right about the favicon.ico detection. I've fixed that in v3.22.1 😎 The og:image field/feature has been moved to RockSettings module and the favicon has been removed in favour of a favicon generator, because these favicon generators do a lot more (like also making it possible to define different colours for different devices or adjusting border radius etc).

Thank you @Jan Romero for letting me know! I have accidentally created two RockMollie pages 🙂

What is your question? Are you asking about the inner workings of the module? The db storage? How the money library works?

Very nice! Great to see it in action and great to know that it performs well 😍 Thanks for sharing!

Hey @gornycreative thx for your questions 🙂 I think all that is already possible. RockCalendar uses regular PW pages and PW templates, so you can add any fields you want, eg TinyMCE or also Page Reference Fields. Yeah, that would be nice 🙂 I might need this for the project that I built RockCalendar for, but not sure yet and for sure not before 2025. But if anyone needs it earlier just let me know.

Payment Module for RockCommerce that can also be used as standalone module. Download & Docs: baumrock.com/RockMollie

Usage: echo rockmoney() ->parse("1,4") ->minus(0.4) ->format(); // 1,00€ Why? The short answer is, because 0.1 + 0.2 is not 0.3 in computer world: Download & Docs: baumrock.com/RockMoney

This module was driven by the development of RockCommerce and RockForms, but it can be used as a standalone module as well. This is how it can look like in action: Download & Docs: baumrock.com/RockLoaders

Hey @nurkka I have something for you 😎 Please download v5.9.0 https://www.baumrock.com/en/releases/rockpagebuilder/ All you have to do is add a hook like this to /site/ready.php: wire()->addHookAfter( 'RockPageBuilder::getPresets', function (HookEvent $event) { $page = $event->arguments(0); $field = $event->arguments(1); if ($page->template != 'blogitem') return; if ($field->name != 'rockpagebuilder_blocks') return; $event->return = [ 'Demo' => [ 'Alert', 'Features', 'Features', 'Videos', ], ]; });

v1.4.1 is now fully translatable 😎 Every aspect of the module! You can translate day names, month names, set start day of the week, set labels of all buttons, etc.! Docs are also updated: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/translations/

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!

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! 😇

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?