bernhard

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?

Hey @iank thx for your purchase ? The only thing to know is that $block is the variable for the block page and that $block->something requests the field value and $block->something() requests that field as frontend editable field, which is the same as $block->edit('something'); Does that already help? Other than that did you change the settings of the frontend editing module? I never touch these. Maybe you have a step by step guide to reproduce the issue?

That's a namespace issue. Your IDE should tell you that. Just add this on top of your ready.php file: use RockPageBuilder\Block; use RockPageBuilder\BlockSettingsArray; I've updated the docs ? Thx

Great to see a tutorial about Latte ? And always great to get some promotion of using custom page classes. ?? One thing to add might be that when using RockFrontend you can use __('Some text') translations directly in your Latte files! That's not possible with your approach. Also the next version of RockFrontend will have automatic layout loading for latte, which is really cool and comes from an input of @dotnetic who had this need and sponsored that addition ? And not to forget live reloading ? But of course Latte is great even without RockFrontend ?