bernhard

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.

Well it always depends on the exact use case, so Repeaters might be a good option in one scenario or another. But the thing is that your example is very simplified and not the whole story ? Where would you store results for example? You could add another repeater for that, but then you have 3 levels of nesting and things get a nightmare if you want to retrieve data in an efficient way. When working with repeaters from the API in regular pages it's simple to do this: <?php foreach($page->my_repeater as $answers) { echo $answer->user . " selected score " . $answer->score; } But how would you get all scores by user X and how would you efficiently aggregate that data and build an average for example? These things are extremely efficient when done via SQL and are extremely expensive when done via PHP foreach ... And querying data from repeater pages is a pain. Or at least I don't know how to do it easily ?

I've never used that myself but searching the core for "->renderPager(" returns 3 results, so if you look at one of those you should see how Ryan did it and that should work for you as well ?

The only one that can answer that question is you. It only depends on your skills. ProcessWire can likely handle that challenge easily. What do you expect someone to answer to that question? My only advice for that project is NOT to use repeaters for questions, answers, whatever. Repeaters are tempting because you get some kind of easy UI for your data, but repeaters really don't scale well and they are a pain when it comes to aggregating data, which is likely an important requirement of such a project. It's much better to store everything in pages and create references via page reference fields. Then aggregating data is easy via RockFinder or findRaw(). Listing data is still a problem, but that can be done with a custom process module https://processwire.com/talk/topic/17709-how-to-create-custom-admin-pages-aka-processmodules-yes-its-that-simple/. You can use libraries like https://tabulator.info/ for listing data. It's more effort than using repeaters, but it's for sure better for UI/UX and you have a lot more possibilities to present your data. If you don't want to build the last part on your own you can buy a license of RockGrid - it's not on my website yet but it will be soon and I can send it manually to anybody interested. This is how such a grid / table / lister could look like: Instant sorting and filters. All the columns and buttons are totally up to you and added via JavaScript. Every row is a ProcessWire Page ?

Thx for the kick in my *** ? This has been on my list for quite some time ? I've just pushed v4.7.4 to github and it's ready for you to download on my website ? Blocks will now be deleted whenever a page with a rockpagebuilder field is saved. Let me know if everything works as expected!

Read https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/?do=findComment&comment=147564 and https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/?do=findComment&comment=235967 ?

Great! ? Thx for the report and for pointing me to the right spot for the solution ?

Thx for the report @iank I've just pushed a fix for this in v4.7.3 - could you please check if that works for you? Thx ?

Here you go: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/fields-access/ Accessing Fields All fields of your block will be available to your $block variable just like usual: echo $block->your_field_name; echo $block->edit('your_field_name'); Method Syntax RockPageBuilder comes with a helper to make working with long fieldnames easier and less verbose. The reason for that is that when I create new blocks I always prefix all fields with the block template name. That way I can be sure that when I copy that block to another project the fieldnames don't collide with existing fields. The problem here is that we end up with long fieldnames like this: rockcommerce_invoice_pdf. When using RockPageBuilder you can do this: echo $block->pdf(); This feature is actually a feature of RockMigrations' MagicPages module. You can also pass parameters to request a different state of the field: $block->pdf(); // frontend editable field $block->pdf(1); // using ->getFormatted() $block->pdf(2); // using ->getUnformatted() Note that the method call has to be the last part of the string after the final underscore: // field foo_bar_baz $block->baz() // field foo_something $block->something()

Ah yes sorry for that - I see it's not in the docs and I'll add that asap ?

You can also try changing the name of the field. Maybe that makes a difference? There is a naming convention for this feature! I'm heavily using prefixes and therefore it only takes the last part after the final underscore. So a field my_great_textarea_field would be $block->field() Maybe that's the issue?