bernhard

You can set the language before the $pages->find() operation:

I'd also love to have a PW based forum software ? Check out this thread:

Yeah, I agree and understand. But if it only happens once it's impossible to debug and fix ?

Hey @Klenkes sorry for the trouble. Never seen this in my 3 years of using the module. I'd unhide the block via API in the tracy console and see if the error occurs a second time on another block at some time. $pages->get(#your-block-id#)->removeStatus('hidden')->save();

Don't think that RockMigrations would help a lot here as the ->deletePage() method is not meant to be used for scalable scenarios. Though RockShell could help, because it's super simple to create new commands (see the docs here: https://www.baumrock.com/en/processwire/modules/rockshell/docs/custom/) and you can then execute this command via CLI whenever you need it, provide custom options if you want etc etc. If it's a one-off task then bootstrapping PW and calling that file manually would be fine as well.

?

PS: Last chance to get RockPageBuilder with huge discounts of up to -30% until today 23:59:59 CET (Vienna) ?

Hey @maddmac thx for your question! Sure! That's the idea and the main benefit of RockPageBuilder compared to RepeaterMatrix where you'd have to build all that on your own! I built the frontend UI in a way that it works with any CSS framework or without any framework at all. The example blocks are UIkit, but you can convert that to any markup you want. I don't understand that part. What exactly do you mean?

I'd suggest that you tell us what you try to achieve so that we can throw in ideas how that could be solved rather then asking how to fix your specific problem. The problem here is that we might be fixing a problem that does not even exist when we go another (better) route anyhow. If you only want to have your translations available via the $terms variable in all your frontend template files, then just add your line of code in /site/templates/_init.php and it should work (assuming that you have $config->prependTemplateFile = '_init.php'; in your /site/config.php).

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!