bernhard

Yes and no. I have had several situations with auto-formatters where the output was not what I'd like to have, but it kept reformatting to its own wish. There was no way to change that other than turning off auto-formatting. Latte has so many great features. I agree that it is a little pain to not have proper auto-formatting and intellisense, but I think the pro's outweigh the con's by far. But please report it to the folks of nette. You have my support and @Yipper had similar issues recently. And I think there are many others as well. Maybe we can initiate something 🙂

I also have no auto-formatter for latte + vscode, which is a shame. But I try to see that positive and take it as a reminder to keep my template files as simple as possible. Anything more complicated than $page->title is handed over to PHP where I have auto code formatting + intellisense.

Ok great, please change the name of this thread to "[solved] ..."

If $this->prefix is empty you set the type of the "title" field to "text", which would explain your issue!

I'd not say it's strange. It makes sense. I just tried to confirm that the log you posted is not related to the issue you are seeing. What I'd do: Confirm that your change is coming from RockMigrations To do so check "Disable all migrations" in RockMigrations module settings. Then set your title field back to "textLanguage" Do a modules refresh, or even better run php site/modules/RockMigrations/migrate.php from the command line (you get more logs) Is your title field still "textLanguage"? yes --> seems like RockMigrations is the issue To confirm remove the tick on "Disable all migrations" Do a modules refresh (or run migrate.php) Is the title field now "text"? Yes --> confirmed that RockMigrations is the issue No --> should not be possible IMHO no --> something else is changing the field type. maybe another module? or maybe some of your own code? If you can confirm that RockMigrations is the issue you should have something like this somewhere in your codebase: 'type' => 'text', "type" => "text", The problem is that it might exist in any variation, like "type" => 'text', with or without comma, etc.; Let me know if you find something.

Hey @Yipper thx for the report! This comes from the "fields-" (fields minus) key in Logos.php which tells RockMigrations to remove all fields that are not listed in the array. I'm not sure why that would cause the title field to change from textLanguage to text, though. Can you try removing the minus and let me know how/if that changes behaviour?

Well... it has Pro's and Con's I guess. For example if you wanted those fields to be textarea (single Language), but then you install language support later that would mean RockMigrations will change the field's type, which might not be intended. But I guess you are right in this case that it's the more likely situation that those fields should be multilang when languages are enabled. I have updated the blocks to use the dynamic version.

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 🙂