bernhard

Hi @Yipper thx for the info! I have updated all example blocks like this: public function migrate() { $rm = $this->rockmigrations(); $rm->migrate([ 'fields' => [ self::field_text => [ 'type' => 'textarea', // or textareaLanguage 'inputfieldClass' => 'InputfieldTinyMCE', ... Will be part of the next release!

What about something like this? $start = 0; $chunkSize = 100; $oldYear = false; while ($chunk = $pages->findIDs("sort=created,limit=$chunkSize,start=$start")) { if (count($chunk) < 1) break; $p = $pages->get($chunk[0]); $year = date('Y', $p->created); $y = $oldYear === $year ?: " ($year)"; echo "#$p{$y}<br>"; $start += $chunkSize; $oldYear = $year; } Result: #1 (2023) #1148 #1265 ... #2269 (2024) #2395 #2496 #2598 ...

Glad you like it! 🙂 This was really a long way until I got there and now - finally - it feels really good and solid 🙂 Absolutely! I just built it around mollie because I knew them already and I trust them and when I compared prices they were even a bit cheaper than Stripe. Plus being in the EU that's another bonus for me. But I understand that Stripe (or any other service) might be preferable for others, so I'm super happy to add support for it to RockCommerce! Just write me a PM and let's do a meeting after Christmas?

Awesome! Thank you for all your great work!!

Hey @adrian thx for the great redirect info. I'm using it very often! Would it be hard to link the "file" cell to open up the file in the configured IDE just like all the other links work? Obviously not tremendously important but would be a lot nicer than finding the file and line in the IDE manually 🙂 Thx a lot!

Hey @Frank Vèssia thx for your questions! Thx 🙂 That's already built in (or possible)! I have added this to the docs for you: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/shipping/ Does that help? I've also added docs for this: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/coupons/ I've also added a section about this to the cart docs! Like all the other mentioned puzzle pieces this can mean so many things. One might want to manage users via ProcessWire. One might want to sync users with a 3rd party tool. One might want to show custom dashboards to users on the frontend. One might want to show a dashboard in the PW backend... I'm not sure how to proceed with this to be honest. RockGrid can be a great way to quickly create excel-like lists, which could also be great for managing RockCommerce users. But I'm not sure how much this would really belong to RockCommerce. It might be more related to RockGrid. Then you might want to send out invoices. That could be done with RockPdf. But you might also want to make those invoices editable, and then RockPdf does not help you. Managing invoice items alone can be a pain. A simple solution could be to use repeaters, but you'll quickly realise that the UI is less than ideal. Prices do not update automatically, so you always need to save the page - to just name one problem. I'd much more prefer having something like RockInvoice for that. With my initial version of RockCommerce that I'm using for my clients on my website baumrock.com has invoices built in. But then I wanted to use these invoicing capabilities also for my other clients that did not purchase modules from my store but ordered a website or website maintenance service. So for the customer part the short answer is yes, I think I'll leave that up to the developer. The ProcessWire way... Unless anybody has good reasons and ideas to approach it differently? But what you get out of the box when using RockCommerce is order management. At the moment this is just a list of pages in the page tree, but I plan to expand on this by adding a Dashboard that shows revenue stats and that shows a nice list (RockGrid again) of all the orders with hopefully helpful data (like who ordered, when, etc). Any input or questions are welcome.

As of today we count 951 stars on Github. Would be great to hit 1k by the end of this year! I'll suggest we all invite our PW-friends to star the repo if they haven't done yet! My next newsletter will be in 2025, but I'll add it there as well. Also @teppo you might want to mention this in your newsletter which would have a lot more impact than mine I guess 😄

Have you ever realised that DDEV only works when you are connected to the internet? No? Then all fine 😉 If you did, I have good news for you! DDEV does NOT require a working internet connection! You can, of course, use it for local development without being online - for example on a plane. The only thing you need to know is that if you started the project via "ddev start" while being connected to the internet and then you go offline, then your browser will not find your project any more. All you have to do to solve that is to run a "ddev restart" 🙂 The reason for this is explained here: https://ddev.com/blog/ddev-name-resolution-wildcards/ @gebeer

Hey @FireWire thx for your report! Good news 🙂 This should be fixed in v1.4.3

Does anybody know a software where I can quickly write down estimates of project cost/duration like this: Where I can add features/tasks with an estimate duration and where I can toggle the tree branches on/off and see the totals? How are you doing this? Thx!

I still don't understand, but I probably don't have to. RockCalendar is great when you want to give the users the possibility to enter dates, especially enter recurring dates (you also need RockGrid for that), and have the option to modify single events (add exceptions, move single events out of the series, etc). Building a UI for this is not easy and a lot of work, so RockCalendar should save you a lot of work and hassle. On the frontend you can do whatever you want. All events that RockCalendar creates are just regular PW pages. Showing a list is even easier than showing a calendar, because all you need is a PW selector and a foreach. The only thing necessary for events is that they have a rockcalendar_date field, because only then RockCalendar can know when they take place and where to show them in a calendar on the backend (or how to sort them). I don't know how you "thought of automating it" or what you'd automate, so I'm not sure how RockCalendar would fit here or if at all.

I've been working to improve the deployments feature. As a result I changed a small detail in v6.3.0 that might break your deployment pipeline. If you are seeing this error: You can either update RockMigrations or, if that is not possible, make your workflow use the old version of the deployment:

Don't understand what you mean. Sounds like recurring dates? Have you seen RockCalendar?

Hello and welcome to processwire! The short answer is there is no recommended way. Processwire leaves that completely open to the user. Some like markup regions, I don't. Some use template engines like latte or twig, others don't.

These are great news! Any chance to talk to the strangers that work on improving the admin theme? We have worked on that front as well (https://processwire.com/talk/topic/29828-can-anybody-help-to-improve-the-design-of-adminstylerock/?do=findComment&comment=240194) and it would be great to share what we found out! Especially @Chris-PW had some really good input!

Sorry to hear that! At least your issue should be easy to fix: // site/ready.php // REMOVE THIS AFTER LOGIN!!! // visit yourdomain.com?logmein=somesecretstring if ($input->get('logmein') == 'somesecretstring') { $session->forceLogin($users->get("roles=superuser")); $session->redirect($pages->get(2)->url); } This will log you in as the first superuser it finds and redirect you to the backend. There you can reset users/passwords as you need.

Would be great if you could share how you use it. That's probably easier/faster than creating a module and could also be helpful/interesting 🙂

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/