bernhard

That's how FullCalendar renders Events and shows their info. It should be configurable though: https://fullcalendar.io/docs/displayEventTime which should be easy to hook: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/hooks/#getitemarray

Hi @Pavel Radvan these kind of errors are easy to solve by searching the error message in google: https://www.google.com/search?q=class+domdocument+not+found&oq=class+domdocu&gs_lcrp=EgZjaHJvbWUqBwgAEAAYgAQyBwgAEAAYgAQyBggBEEUYOTIICAIQABgWGB4yCAgDEAAYFhgeMggIBBAAGBYYHjIICAUQABgWGB4yCAgGEAAYFhgeMgYIBxBFGDzSAQgzMDg4ajBqN6gCALACAA&sourceid=chrome&ie=UTF-8

Hey @herr rilke please use the new RockDevTools module for handling assets: https://github.com/baumrock/RockDevTools/tree/dev/docs/assets Due to several limitations and issues like you have found asset tools of RockFrontend will be removed in the next major version. Please mark this [solved] if everything works for you.

Could you share the exact code? As far as I understand your screenshots ProcessWire tries to call ->getShowByArtist() but doesn't find it and therefore tries to run Hooks, which is what it does to execute any methods that are attached via hooks and not really added to the class itself. The question is still why it doesn't find the getShowByArtist method when it should be there. In your case I'd search my codebase for "getShowByArtist" and make sure that it only exists at one single location. Then, I'd remove that call and replace it with a bd() call, for example bd($item). Tracy should then dump a "HomePage" object to the debug bar. If it dumps a different object, then it makes sense that it throws an exception that the getShowByArtist method does not exist.

On the template settings of every template you can define whether this template defines access settings or not. If not, it inherits from the parent template. As page id=1 does not have a parent template it is required that the template set for page #1 has access settings enabled.

Agreed. When using Custom Page Classes + MagicPages these kind of things are super easy to do: <?php public function onCreate() { $this->mycheckbox = 1; } But a hook in /site/ready.php would also not be much more work. Just less beautiful in my opinion 🙂 <?php wire()->addHookAfter('Pages::saveReady', function($event) { $p = $event->arguments(0); if($p->id) return; if($p->template != 'whatever') return; $p->mycheckbox = 1; });

Sorry, I don't understand your example. Please show screenshots and explain what you'd expect and what you actually see.

The problem with default yes is that it would not affect already existing items. So if you had 100 pages already, then you add a checkbox with default=1 and you add another 200 pages and then you use a selector "mycheckbox=1" then it would find 100 pages, not 200. Or you'd have to update all 100 pages that already existed before you added the checkbox. Ryan recommended once (if I remember correctly) to use what I'd call the reverse-label-pattern. So instead of showing a checkbox "send email after save" that is default on, you'd add a checkbox that is default off and shows "do NOT send an email after save". Or "no mail after send" or whatever. Or you add a hook on page create that populates the checkbox for you. Or you add a toggle field, that has the option to set default yes/no etc. I think I'd probably use a nice, non-reversed label together with a hook to auto-populate when the page is created.

@Spinbox thx for your report, but it would be nice if you could also try to add helpful information to your report rather than just a short "not working" note. Please try different browsers, etc.; Multi-Language yes/no etc.? Console errors? ...

Nice, looks a lot better no in my opinion 👍 That sounds strange. I think the only explanation is that ->getShowByArtist() is called on a non-HomePage object. When it throws an Exception you should get a backtrace that you can in spect. Go through the list step by step and inspect which call triggered which next step. This list can be quite long, so I first focus on all files that are under my control and skip those from the core. TracyDebugger is usually really helpful here and you can even click on the line in the stack and land directly in your IDE at the right position. Hope that helps 🙂

This should work, see here: https://processwire.com/talk/topic/29593-solved-do-the-reset-password-tricks-work-for-you-they-dont-work-for-me/?do=findComment&comment=239355 It will log you in and redirect to the backend, so you'll also know the admin url then.

Hey @Christophe sorry for that. I totally missed that and after your last message talking about RockCommerce and some other projects on your side my brain dumped everything we talked before. It was quite an easy fix though, so it might have been good to start over with a fresh head, because I can remember I was on another track with solving that issue 2 weeks ago. Please grab v1.5.1 and let me know if it works now! https://www.baumrock.com/en/releases/rockcalendar/ Also @Stefanowitsch could you also please upgrade and see if it breaks anything on your project?

Thx. I've also added a check that should remove 'template_id' from the shown code of repeater fields.

@Christophe I don't have any open issues on my list. If you have one, please open a separate thread, so it's easier to keep track. Please describe everything as good as possible and please check if you have the latest versions of all modules.

@thei you have lots of unnecessary properties in your field definitions. For example "template_id = 0" and "parent_id = 0" This messes things up. Please remove them. I have added a note to hopefully avoid such issues in the future: This is all you need for a repeater: return [ 'label' => 'TEST', 'type' => 'FieldtypeRepeater', 'fields' => [ 'title', 'mytext', ], 'repeaterTitle' => '#n: {title}', 'familyFriendly' => 1, 'repeaterDepth' => 0, 'tags' => 'test', 'repeaterAddLabel' => 'Add New Item', ]; Please mark this topic [solved] thx!

Update if anybody else is following this. I was not able to reproduce this. Tried two different setups and everything installed without any issues. We agreed that @hellerdruck will install DDEV and see if it works there. Then we can investigate further.

Thx! Maybe anybody else can try it also @gebeer @Stefanowitsch ?

Please upgrade to v3.5.2 which updates all dependencies due to security updates: symfony/http-client CVE-2024-50342 Low severity nesbot/carbon CVE-2025-22145 Moderate severity

Hey @Spinbox thx for your good eye! 🙂 I've removed the comments. I think I pushed them by accident. Please grab v5.21.1

Hey @FireWire when working on the new settings syntax & docs I tried this example and it worked as expected: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/settings/#conditionals-showif Is this still an issue for you? I just checked with your example and everything works as expected there as well! /** * (Optional) Settings of this block * * You can access settings of the block via $block->settings() or access * a single setting via $block->settings('foo') or $block->settings('bar') * * If you don't want any settings for your block you can remove this method. */ public function settingsTable(\ProcessWire\RockFieldsField $field) { $settings = $this->getSettings(); $settings->add([ 'name' => 'image_location_horizontal', 'label' => 'Image Location', 'value' => $field->input('image_location_horizontal', 'select', [ '*right' => 'Right', 'left' => 'Left', 'center' => 'Center', ]), ]); $settings->add([ 'name' => 'body_location_vertical', 'label' => 'Body Location', 'value' => $field->input('body_location_vertical', 'select', [ '*above_feature' => 'Above Feature', 'below_feature' => 'Below Feature', ]), 'showIf' => 'image_location_horizontal=center', ]); return $settings; }

First thing to check is if your $pages->get() call works at all. For example in the tracy console. You are using $pages->get() which will return a single Page object (or NullPage), so your ->first is wrong, i guess. Next, I think you can't use { } brackets inside { } brackets when you are outputting a string. This will NOT work: {var $item = $pages->get(2)} <a href="{$pages->get("name={$item->name}")->url}"> {$item->title} </a> This will work: {var $item = $pages->get(2)} {var $url = $pages->get("name={$item->name}")->url} <a href="{$url}"> {$item->title} </a> And this is what I'd recommend you to do: Create a Site.module.php in /site/modules/Site <?php namespace ProcessWire; // expose the site module as global site() function function site(): Site { return wire()->modules->get('Site'); } // module code class Site extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'Site', 'version' => '0.0.1', 'summary' => 'Site Module', 'autoload' => true, 'singular' => true, 'icon' => 'bolt', 'requires' => [ 'RockMigrations>=3.34', ], ]; } } Then add the following method: public function getShowByArtist(Page $item) { return wire()->pages->get('template=concert-visuals|broadcast|music-videos, artist.name={$item->name}'); } Which cleans up your template a lot and will help you to write better (DRY) code, as you have one place to store the logic. If you need the same link url in another place of your website you simple call the same method and not copy paste the selector. If the selector changes over time (for example adding another template to the selector) all your links will still work by only updating one place in your code (and not many). <a href="{site()->getShowByArtist($item)->url}"> {$item->title} </a> Or even better use Custom Page Classes and add the getShowByArtist method directly to your $page object.

Actually there is one detail: When using add/prepend you can provide an array because I implemented those in my settingsarray class. But insertBefore and insertAfter are not implemented, so they will be called directly from the WireArray class, which does not understand adding a plain array. That's why we need the $settings->getItem(...) call before.

That's regular WireArray methods, nothing fancy here 🙂

Thx, oh and I forgot to mention that I changed your example: is now $settings = $this->getSettings(); Because I think the getDefaultSettings is nothing we should promote any more 🙂 This change is part of v5.12.0

Thx @FireWire I have updated the docs and expanded your example of add()/prepend() with insertAfter()/insertBefore() https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/settings/