bernhard

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?

Just tried this list on mobile. Rows seem to be resizable which conflicts with touch scrolling. I'm quite sure there is a setting to disable that.

Or add RockFrontend as a dependency and do $rockfrontend->styles()->add(...) ? ?

A Fieldtype module is not an autoload module. Fieldtype/Inputfield modules are only loaded if needed and that's not the case on the frontend. Just create a master module that is autoload that adds those hooks and installs the fieldtype/inputfield modules for you.

Sure. Either install RockMigrations and use the "PageListShowTemplate" tweak. Or have a look what it does and add a hook yourself: https://github.com/baumrock/RockMigrations/blob/main/tweaks/PageListShowTemplate.php Or use custom page classes and use the getPageListLabel method. Also super easy!

Sure, everything is possible in PW. Have a look at RockFrontend: https://github.com/baumrock/RockFrontend/blob/607fadd11bf1314458504f743ca8223e5847e71d/RockFrontend.module.php#L214-L236 The only thing you need is an autoload module so that the hook is fired on every request.

@adrian thx. Actually I'm not sure if that is still an issue. First they have pushed something to vscode and closed the issue: https://github.com/microsoft/vscode/issues/197319 And second it seems to work on my end again. No idea what's going on...

Ok great, that's fine, thx ?

Could you please create a new topic if you need further help, thx ?

Thx @Jon just pushed release v4.7.1 with the fix ready for everybody to download ? Hm. Maybe a permission issue? Check if your user has the rockfrontend-alfred permission on the home template

@Jon does it fix your issue? Then I'll push this fix to the main branch ? Let me know if you find any other issues with subfolders - but I hope there are none of course ?

I'm not seeing this. Neither with 8.1 nor with 8.2..

Hey @Jon sorry for the issue - didn't think of subfolder installations! Can you try to change this in InputfieldRockPageBuilder.js:351 // from this $.get("/rpb-create-block/?field=" + field + "&name=" + name) // to that $.get(RockFrontend.rootUrl + "rpb-create-block/?field=" + field + "&name=" + name)

I fear I don't have any idea for you, but have you considered using DDEV? I think it would be worth trying, because it is such a great and hassle free dev environment and maybe your issue will be solved as well!