bernhard

Looking really great 🙂 Really? 😮 @ryan is that a limitation or is that something coming later? I'd also need a field like this for events, eg MyEvent 1.12.2023 19:00 - 2.12.2023 03:00

Hey @iank thx. Unfortunately that was a wrong guess from my side and it's not really helpful. I'll be mostly offline for some days and I'll have to look into it later. If you find time to debug it yourself that would be great, because it's kinda hard to do that without a windows system from my side 🙂 But I'll try my best when I'm back.

Yeah, I'm using the same setup and it's absolutely great. Simple, clean, flexible, powerful. You can also access the $wire instance from every wire derived class, so you could also do $page->wire->foo->bar, eg $page->wire->pages->find(...). Many options 🙂

Can you please add this on top of ___getIcons in RockFrontend.module.php: bd($page); bd($opt); And show me the output of that dump. I'm especially interested in this:

Thx for the report. Does it work if you make this change in RockFrontend.module.php?

Sure. Here's a mini-Tutorial how you can find what you need yourself: Whenever you add a page you view the page /processwire/page/add. That's the page with ID #6 and it lives in your page tree in Admin > Pages > Add Page. If you edit this page you see that this page uses the process "ProcessPageAdd". So you can inspect that file in your IDE by opening wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module There you see the ___execute() method which is the method that renders your page. There you see that at the very end it renders the form and that form is built some lines above by calling buildForm(). If you have a look at that method you see that it is hookable, so you can modify that form by hooking into "ProcessPageAdd::buildForm" <?php // in site/ready.php $wire->addHookAfter("ProcessPageAdd::buildForm", function($event) { $form = $event->return; $form->add([ 'type' => 'markup', 'label' => 'foo', 'value' => 'bar', ]); }); Hope that helps.

You could also just pass the $wire object and from there you can access anything in your templates like $wire->pages->find(...) or $wire->foo->bar...

If you don't need that, don't use it 🙂 I understand your arguments and I'm not going to try to convince you which way is better as both have pro's and con's. Just wanted to mention that idea of RockFrontend is to provide the tools you need and stay quiet in the background if you don't need them. If that's not the case for whatever reason I'd be happy to get a detailed report of the issue so I can fix it and make RockFrontend work in the way it's intended to work. If you do that or not is up to you. Just didn't want to leave that "RockFrontend broke my whole site" uncommented, as I'm putting a lot of work into my modules and I also try to make them as backwards compatible as possible.

BasicPagePage.php class BasicPagePage extends Page { ... } You take whatever template name you have and convert that to camelcase, eg basic-page = BasicPage, foo-bar = FooBar, home = Home and then you add the suffix Page to that name (FooBarPage, HomePage). In case of BasicPagePage it sounds a bit weird and I've myself done that wrong several times when I forgot the suffix and just called it BasicPage.php and wondered why it is not working. But once you get the concept it's easy and makes sense 🙂

Good luck. I always fail at that 😄 And also good luck with the docs. I know how much work that is, so don't let that feel you bad. It's not easy.

Wow @BitPoet that's real bit poetry 🙂 I've taken your example and did some research in the code and found this as an alternative solution: <?php $wire->addHookAfter("PageFinder::getQuery", function (HookEvent $event) { // get the DatabaseQuerySelect object $query = $event->return; // modify the query to only find names with length < 6 $query->where("LENGTH(pages.name)<6"); // remove the hook after first execution $event->removeHook(null); }); // find users with names < 6 chars bd($wire->pages->find("template=user")); It's important to add the hook immediately before the $pages->find() call. And it's important to remove the hook so that it only executes once.

Thx @Atlasfreeman that issue should be fixed in the latest version of RockFrontend 🙂

Can you please try a fresh install? Maybe something was corrupted at your first installation and now things don't work any more as expected. Maybe also try to do a modules refresh two times before installing blocks. Another thing that you can try is to remove all files from /site/templates/RockPageBuilder and then do a modules refresh. This will remove blocks from the database that don't have an associated file. But the best would be to try a fresh install with PHP8.1; I'll try to see if I can reproduce the PHP8.2 issue and provide a fix for it as soon as possible!

I've just uploaded a video about RockPdf to processwire.rocks 🙂 Until 30.11. you can get the module for 49€ @ https://www.baumrock.com/processwire/module/rockpdf/ Here are extensive docs for the module: https://www.baumrock.com/en/processwire/modules/rockpdf/docs/

Hey @Atlasfreeman sorry for the trouble. Which PHP Version are you using? I'm still on 8.1 on almost all of my projects, so if you can switch to PHP8.1 for the time that would be the best bet to make everything work without any issues 🙂 Thank you very much 🙂

Ok thx, I was just curious. I'm not adding phpmyadmin in my setup. I'm always using Adminer that comes with tracy debugger 🙂

Nice 😎 Why are you adding phpmyadmin? Isn't that a ddev default anyhow? And could you please give me some more details if there's something that should be fixed here?

Great to hear that, thx for letting me know 🙂 Did you create an alias? That's really great. Then you can simply type "rockshell" and it will execute "ddev php rock ..."

Or let github update your version number automatically:

I'd write Ryan a PM 🙂

Have you thought about using tracy user switcher for that?

Ok now I understand what you were saying. That meant to me: Du verwendest den folgenden Code in deinem CSS und das funktioniert nicht mit RockFrontend:165 So I thought I was using something in a wrong way. That 62.5% were looking familiar to me, so I thought I was using it somewhere. Turns out that I knew it from the time when I implemented that feature. It was a solution that I did not like and that's why I came up with my own solution. Absolutely. It's no problem to make things configurable, but I need to understand the problem and the solution before I push code to my module. That's why I was asking for examples... I've just pushed an update to the DEV branch to make that setting configurable. Let me know if that works for you:

@Klenkes I don't know a lot about this topic, so it would help if you explain the problem, so that I can understand it and then provide a solution. I don't know why it is 16 but that seems to be some kind of standard? For example https://www.rietsch-design.de/pixel-in-rem-konvertieren-tabelle.html I can't find that code snippet in my codebase. Where is that?

Hey @Klenkes sure, I can make everything configurable that needs to be configurable 🙂 Could you please explain the issue in detail so that I better understand? Could you please provide a step by step example?

Hey @ryan that looks great! Are you also planning to add an API to select pages matching a date range? That would be great, because when working with date ranges the INPUT is only one part of the equation. May I ask you to have a look at this thread? https://processwire.com/talk/topic/23097-previewdiscussion-rockdaterange-fieldtype-inputfield-to-easily-pick-daterange-or-timerange/ It shows what I came up with some time ago. I didn't proceed with the module, but some parts of selecting pages where quite promising: <?php // find events in 2023 (meaning from 2023-01-01 00:00:00 to 2023-12-31 23:59:59) $pages->find("template=event, my_range=2023"); // find events in taking place in 2023-11 (meaning from 2023-11-01 00:00:00 to 2023-11-30 23:59:59) // this would also find an event starting in 2023-10 lasting to 2023-12 $pages->find("template=event, my_range=2023-11"); // find events in taking place in 2023-11-17 (meaning from 2023-11-17 00:00:00 to 2023-11-17 23:59:59) $pages->find("template=event, my_range=2023-11-17"); // find events starting after 2023-11-17 00:00:00 $pages->find("template=event, my_range.starts >= 2023-11-17"); // find events ending before 2023-11-17 00:00:00 $pages->find("template=event, my_range.ends < 2023-11-17"); Not sure how/if that works when dealing with different timezones, but for my use case it was of great help to have this easy human readable API, because when using timestamps it quickly get's complicated and prone to errors (like forgetting to use <= instead of < or such): <?php // find events taking place in 2023-11 $from = strtotime("2023-11-01"); $to = strtotime("2023-12-01"); $pages->find("template=event, my_range.starts >= $from, my_range.ends < $to"); That example is actually not working, because for real world queries you'd need to take more possibilities into account: So if 2023-11 starts at the first black line and ends at the second, then you'd need this query to find events that take place in 2023-11: // find events that either // start within 2023-11 (meaning start after or at 2023-11-01 00:00:00 and start before 2023-12-01 00:00:00) // or end within 2023-11 (meaning end after or at 2023-11-01 00:00:00 and end before 2023-12-01 00:00:00) // or start before 2023-11-01 00:00:00 and end after or at 2023-12-01 00:00:00 That shows that it quickly gets very complicated and you need to be really careful with all the times and comparison operators! IMHO using the other syntax makes code a lot easier to read and maintain. For my use case (showing events in a calendar) it was a lot easier to use this syntax, because you don't have to find the timestamps of the first second of the month and the last second of the month or the first second of the next month etc.; You just use "range=2023-11" and that's it.