bernhard

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 🤷‍♂️