bernhard

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?

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!

Hey @Juergen writing the docs for RockLanguage I did some research and found this old thread. I guess you were facing the challenge to ship your module with translations? Anybody facing the same problem please have a look at RockLanguage! All you have to do is add language mappings (eg german=DE) and then add a folder /RockLanguage/DE to your module. RockLanguage will then copy all translation .json files from /site/assets/files/.../...json to your module. And not only that. Once you translate a new string via the PW backend, RockLanguage will automatically copy the new json to your module's folder so you can just commit it to github 😎

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 🙂

Yeah but I don't understand what you mean by "same order as they are appearing in the layout". Because clients can rearrange blocks and then there is no unified sort order?!

What do you mean exactly? 🙂

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