bernhard

Ok then it's likely because your PHP does not have the Intl extension installed. Please do that, then it should work!

Please check RockMoney v2.0.4 - does that fix your issue?

Hey @zoeck I thought about your problem and I'm wondering: Does it really make sense - for the user - to split the order into separate carts? Shouldn't it ideally be one cart for the user and one checkout, one order and then, after the order, be split into separate order emails? That way the user does not have to place 3 orders for 3 items in the worst case, he places one order. Then 3 mails are sent to 3 different recipients listing only the products they are responsible for. What you could also do is split the order into 3 orders so that you can track for example a fulfilment status for each order. Or you add 3 different status fields to one order and track, for example, "fulfilmant_status_unitx, fulfilmant_status_unity, fulfilmant_status_unitz" All the mentioned approaches are much easier to achieve than developing custom carts for the frontend 🙂

The cart is just a PW page and cart items are just PW pages as well - so you can do anything during the checkout process! Every cart item just has a reference to the related product, an amount and the variation string: So in your case you could create a form field during checkout to select the category to check out and then calculate a different price. Actually it should even be possible to have different carts on the frontend without changing the logic on the backend. You could implement that logic on the client side with custom code. So instead of showing all cart items you would skip those having a different category!

Very interesting! I think it would be far easier to make the cart show a warning or prevent the order if products from a different group are in the cart than really supporting different carts. Would that be a possible solution? Changing to multiple carts would also mean changing the logic of the cart, both on the frontend and on the backend, which is less than ideal 🙂

3h after launch and we count the first extra wish 😅 Would you mind sharing the exact use case? The cart is at the moment tied to the user's session and there is one global cart for each user. It does not sound too easy to change that behaviour but if you tell me the exact use case we might find a solution.

We are finally ONLINE 😍

Thank you very much @FireWire - it has really been a lot of work and I hope it will be useful! 🙂

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 😉

You can also click on the modified column headline and it will sort by last modification date 🙂

Adding Endpoints to 3rd party modules https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/ajax/#adding-endpoints-to-3rd-party-modules 😉 But of course that means a dependency. Some might prefer that, some might not. Just wanted to mention that the option is there if anybody finds this by coincidence.

Looks like you could also use RockFrontend ajax endpoints: https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/ajax/

Actually the name of this module is totally wrong, because you can not only use it to pick colours, you can also use it for example to pick layout positions - here as an example in a RockPageBuilder block: The code to achieve this: $picker->setColors('site_overlayposition', [ 'top-left' => [ '<svg ...></svg>', 'Oben Links', ], ... ]);

https://github.com/processwire/processwire-issues/issues/2000

Hey @snck thx for the idea. I'm not sure. On the one hand I think it's a nice idea, on the other hand I'm not sure how much it would really help. I'm also having staging + production on the same system and in the rare cases where I have to re-sync staging and production I've always just copied the DB + files over. Given that both are on the same system this is really fast and not an issue. filesOnDemand is built for the case of developing locally where downloading several GB of data might be slow (I have only 30 megabit downloadrate 😉 ) so I only need to download some MB once in a while when I visit a page that did not exist on dev. On the other hand I see room for improvement in synching staging/production, so whoever wants to tackle this, I'm happy to help and add it!

Just use RockMigrations for everything that you add or remove. That's it. Once you push to production RockMigrations will kick in and do everything that you did locally also on the remote system. If you have to add lots of content for whatever reason then just add that on the production site (eg on a new unpublished page) and do a db:pull instead of pushing your local database to the remote.

Not sure what you are trying to say, but that's exactly how the new config traits work. I've added a note about PHP8.2 to the docs: https://github.com/baumrock/RockMigrations/commit/4e776f5185ce19866fd853c87a9acec47f4e7485

I don't know if that could be the reason, but I don't use the host at all any more in my config files. I always use the concept of including different files on my local development and on remote servers. See here: One of the reasons is that the hostname (or in your case the HTTP_HOST variable) might not be available. For example when bootstrapping or calling it from a cronjob. Or the variable might be empty for whatever reason. When including different config-local.php files on local dev and on production/staging you don't have these problems. That would at least be something that you can try.

Hey @FireWire this issue should be fixed in v5.9.2 🙂 Please mark the topic [solved] if it works for you! Thx

Yes I always use underscores. I had problems with hyphens several times. I can't remember any more where exactly, but I remember that avoiding them was the easiest solution. Any sources for that? PW definitely uses camelcase constants like Inputfield::collapsedHidden which I think looks nicer than Inputfield::COLLAPSEDHIDDEN. But I'd be happy to get some links to read.

I'm not sure about this. That should only be the case on regular runtime migrations, but when doing a modules refresh all migrations should fire. I'm using RM Deployments and they perform a backup before each deployment. Is that what you are looking for?

Hey @gebeer thanks for trying out Config Migrations so early 🙂 💪 Same here 😍 The file should not be in /site/modules/Site/RockMigrations/... but should live side by side with Site.module.php! I just had a look into the docs and you are right - the instructions there are like you say. I have to look into what you said tomorrow, but if you have time and read this in the meantime, then I'd appreciate if you could try to create the file /site/modules/Site/RockMigrationsConstants.php and see if that maybe fixes some other of your mentioned issues? Thx a lot! I'll likely do exactly that 🙂 As of 2 days ago we have PHP8.4 released and PHP8.1 gets security fixes only - so I think it would even be fine to have PHP8.2 as a requirement for the module. Any other votes?

I think I don't understand your question, because from how I understand you the answer what I'd do is to just create two commits. v1 / commit: initial version v2 / commit: make it better v3 / commit: make it best But I guess that's not what you where asking for? Or are you talking about release tags? Then have a read here: Or you could also create two or three branches. For example I have some modules that I can't update on some servers, but I had to develop them further for new projects. Then on older projects some issues arise, so what to do? You are on an old commit and the current development state of the module is 17 or whatever commits ahead. "git pull" is not an option, so you can create a new branch for the old version (eg "git checkout -b 'foo.com'" - which would create the branch foo.com) and push your updates there. So you'd have a "main" branch with the module for all current projects and you'd have the "foo.com" branch for the stale project "foo.com"

Glad it was helpful @herr rilke! Yeah that would be possible. Another option would be to solve it with nested elements, so you'd have a "color" container that can hold other blocks (like headline, text, image, etc). Even that would already be possible using RockPageBuilder and @Stefanowitsch did something quite crazy in this regard and hopefully shares it one day with us 😉 But I try to not introduce any kind of multi-level editing for clients. I try to keep things as simple as possible and only add necessary features. But coloured sections is one of them imho.

Hey @FireWire I need the raw Sourcecode not the formatted one from the devtools. In chrome use right click show source rather than inspect element.