bernhard

I totally agree. Those details matter a lot. I knew it 🙂 That's a totally different story now and the solution is different, obviously. Actually with just a small change you can make it work well I think without any issues. We just need to add another page reference field to the "courses" template and adjust our hook to also populate that field! The idea is to use everything what I wrote in this post, but then, additionally populate a page reference field on the courses table so that the system remembers all statuses that have been used for that group. An example: Let's say we have three course groups: GroupA, GroupB, GroupC Then we add a new course to GroupA, let's call it CourseAX. We use the custom <input> to add the status "open" this will create a new status page for us, /course-status/open NEW: We add this status to the page reference field of GroupA, which means that field has status "open" at the moment. Now we change the status of CourseAX from "open" to "closed" and do the same as above: create a new status /course-status/closed NEW: Add status "closed" to the GroupA page reference field --> now GroupA has both "open" and "closed" in the page reference field even though we only have one event with one status. But we can use this page reference field to show the filter on the frontend. The new hook to add this logic would be something like this: <?php // hook processInput to create new status wire()->addHookAfter( 'ProcessPageEdit::processInput', function (HookEvent $event) { // sanitize received status, adjust to your needs $status = trim(wire()->input->post('newstatus', 'string')); // no new status, no todos if (!$status) return; // try to find existing status page $statusPage = wire()->pages->get([ 'parent' => 123, 'title' => $status, ]); // create new status page if it does not exist yet if (!$statusPage->id) { $statusPage = new Page(); $statusPage->template = 'status'; $statusPage->parent = 123; $statusPage->title = $status; $statusPage->save(); } // set new statuspage as selected status $page = $event->object->getPage(); $page->setAndSave('your_page_ref_field', $statusPage); // NEW: Also add status to parent page ref field $statuses = $page->parent->getUnformatted('your_statuses_field'); $statuses->add($statusPage); $page->parent->setAndSave('your_statuses_field', $statuses); } ); I think this should work 🙂

I don't think so. This would still have the issue that if no course has the status "open" then the frontend would not know about that status and therefore would not show it. Please read my previous message. I think it would be the best to save statuses to each group and then try to improve the workflow for the editor (whatever that means - you have to explain what you are missing) rather than changing fields so that they are easy to fill in but have the problem that they can't work on the frontend.

From what you wrote I think that would be the way to go. 🙂 How else could the system know to show the "open" status if no courses have that state at the moment? I think you should not try to find another setup, I think you should try to fix the issues that you have with your workflow. But you didn't say what you don't like with your current workflow. Maybe there is a solution for that and then you have solved all problems without creating new ones 😉

Hey @verdeandrea thx, I understood that. My question was why you only want to show "open / closed" to "courses" and "in prep / registration open" to "masters" and at the same time make it possible to add new statuses. Because that means anybody could just add "open" or "closed" which are only available under "courses" to any page under "masters" as well - which makes hiding them obsolete from a logical perspective. And if you didn't hide them, you would not have the problem that you observe. My guess would be that you want to keep the list of available statuses smaller as the global list of statuses might grow large over time? I'd probably add a custom <input> to that page reference field and hook into processInput to create the status page on my own, but only if it does not yet exist: <?php // append <input> to the page ref field wire()->addHookAfter( 'InputfieldPage::render', function (HookEvent $event) { $f = $event->object; // execute this hook only for the field in question if ($f->name !== 'your_page_ref_field') return; // append custom <input> $f->appendMarkup('<div class="uk-margin-top"> ...or create a new status:<br> <input type="text" name="newstatus"> </div>'); } ); // hook processInput to create new status wire()->addHookAfter( 'ProcessPageEdit::processInput', function (HookEvent $event) { // sanitize received status, adjust to your needs $status = trim(wire()->input->post('newstatus', 'string')); // no new status, no todos if (!$status) return; // try to find existing status page $statusPage = wire()->pages->get([ 'parent' => 123, 'title' => $status, ]); // create new status page if it does not exist yet if (!$statusPage->id) { $statusPage = new Page(); $statusPage->template = 'status'; $statusPage->parent = 123; $statusPage->title = $status; $statusPage->save(); } // set new statuspage as selected status $page = $event->object->getPage(); $page->setAndSave('your_page_ref_field', $statusPage); } );

I'm wondering... Why does the status field only show statuses of one group and at the same time it is possible to create new statuses? Doesn't that make the filter obsolete and you could just skip it, which would also eliminate the problem that you are seeing?

You just need to call wire()->modules->get('LazyCron') somewhere in your module, then LazyCron will automatically be installed.

Hey @gebeer thx for that very cool tutorial! I migrated migrations for RockCommerce manually one by one 😅 Not to forget that config migrations make sure that you don't get circular reference issues as they create empty fields/templates on the first run and then do the actual migrations on the second. I also love them and I have no idea why it took so long to come up with that concept 🤷‍♂️

Hi @FireWire good find! I've just pushed a fix for this 🙂 Please download v1.3.1 https://www.baumrock.com/releases/rockicons/

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