bernhard

RockMigrations has a checkbox to prevent guest access. What you state hear sounds interesting. What do you think of adding that to RockMigrations?

Hey @Atlasfreeman there's really no difference in using block settings in latte or php files. Only the syntax is a little different of course. In latte you write {$block->settings('foo')} which would be <?= $block->settings('foo') ?> in PHP. Yeah, that might be a good use case for sticking with the good old approach of dedicated templates. You can still use the RockPageBuilder blocks field on that template, so you will save a lot of time nevertheless ? What do you mean by lock block? A block that is only editable by userusers?

Hey @Atlasfreeman thank you for that question! That's totally up to you ? RockPageBuilder gives you the freedom to define different types of content elements that the end user can place on the page in any order. I'm not sure I understand? Do you mean a listing of child pages? Like on a blog overview page that lists all children (aka blog posts) and shows a preview image for every post? If that is what you are asking then there are two possible solutions: 1) Create and use a block to list children This approach is more flexible but might need some training for the client to understand the concept. The benefit is that you can add content on top of that page listing or below. You have a lot of freedom. You could even add block settings, for example a setting of how many blog posts should be shown. For the blog overview page you might choose 12. One benefit of this approach is that you can reuse this blog on other pages. For example you could add the same block on the frontpage but only show 3 blog posts. You could then add another setting (checkbox) to show pagination or not. For the frontpage you'd hide pagination, for the blog overview page you'd show pagination. 2) Create and use a dedicated template That approach is less flexible but easier for the end user as it has less options and less freedom. ---- I tend to go with option 1. It's really not hard to do and it's also easy to understand for most of my clients. Does that help?

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: