bernhard

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 🙂

Hey @Robin S this is working great so far 🙂 I have one issue when using RockMigration's filesOnDemand feature. That feature hooks into Pagefile::url and Pagefile::filename and if the image does not exist it tries to grab it from the remote server. This is extremely handy when using "rockshell db:pull", because then you have a copy of the remote database on your local dev environment which could have several references to images in the database that do not exist on the filesystem. RockMigrations then downloads those images from the remote server as soon as you visit a page with images that do not exist. This feature can be enabled at runtime by setting $config->filesOnDemand = false; Do you think you can add this to your module to make it work with RockMigrations? Or do you see another way to make it work out of the box? Maybe I can check if the item is in the queue before trying to download it from the remote. See the code here https://github.com/baumrock/RockMigrations/blob/9d9609904647e7b2cfc14a81b2da411edfdca814/RockMigrations.module.php#L2536-L2583 Thx for your thoughts!

This is brilliant @Robin S - very clever solution 🚀💪 Should be merged into the core imho once it is more tested!

Yeah the same technique applies to custom page classes as well. Just add methods there with a talking name and your code will get a lot cleaner and better. Think for example of a situation where you are using $pages->find("template=something") in your template files in several spots and you realise that you forgot to change the sort order to random. When using $pages->find() in your template files you need to find all instances and change the code there. When using $page->findRandomSomething() you simply change the logic in your custom page classes method and everywhere it will be changed immediately. Check out my videos on youtube for that topic: 1) https://www.youtube.com/watch?v=7CoIj--u4ps&t=2124s 2) https://www.youtube.com/watch?v=D651-w95M0A

For everybody else reading: This was actually a small bug in RockFrontend that is fixed now on the dev branch 🙂 Thx for finding and helping me debug it @Klenkes

Can you send me a zip + db dump of that project maybe?

Great! 🙂 Thx for the hint about the version number. I've fixed that and pushed everything to main, so we have a new version v4.7.2 to download 🙂

Got a support request from @dotnetic today and thought I'd share it with you 🙂 Imagine you have all speakers saved under /speakers with template "speaker", eg /speakers/someone and /speakers/anotherperson Now you want to show/list those persons in the RockPageBuilder block called "Speakers". That's very straightforward 🙂 In Speakers.php you add a helper method: <?php ... class Speakers extends Block { ... public function allSpeakers() { return $this->wire->pages->find("template=person"); } } And in the view file Speakers.view.php: <ul> <?php foreach($block->allSpeakers() as $speaker): ?> <li><?= $speaker->title ?></li> <?php endforeach; ?> </ul> Or when using LATTE in Speakers.latte: <ul> <li n:foreach="$block->allSpeakers() as $speaker"> {$speaker->title} </li> </ul>

@Klenkes thx for the report. Seems you are trying out things that all of us have never been using over the last 3 years 😄 Could you please try changing line 81 from $nullpage to $block: $f = $field->getInputfield($block); Edit: Sent you the new version as PM, please check 🙂

I don't understand. It should be the same as with every other page. I just tried with an options field and $block->opt gives me this And $block->opt->title gives me "foo"

@Klenkes thx, I already found the source of the problem. Repeater fields have to be renamed because we can have many fields "foo" on one page, so they are named "foo_repeater123" and "foo_repeater456" and such. This conflicts with the showif condition, which would still be "foo=something". I'm wondering though why it does not work on the frontend when using ALFRED. Are you sure? For me it works in two senarios: 1) If I edit one block in a separate window: 2) In an ALFRED modal opened from the frontend It does not work on the backend view: Because in that last case we have fieldnames with the _repeaterXXX suffix. In the first 2 cases we open only the single page, so we don't have these suffixes. Can you confirm that it is the same for you?

Hi @Klenkes that's a bummer, I can confirm that bug. Seems I have never had that need in three years 😄 I'll have a look into that as soon as possible! Thx for your purchase and I hope you like it nevertheless 🙂

Yes. If you scroll down on mobile with your fingers and you hit a spot between two rows, then the row is resized instead of scrolling the page. Which is less than ideal 😉 https://tabulator.info/docs/5.5/layout#resize-row The default should be false. Seems you have enabled it?