Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/20/2024 in all areas

  1. I just finished integrating this module on a client website (it's not live yet!) . The client has roundabout 85 groups. Each group meets on a specific date - recurring! So I added a RockCalendar field for each group and created the recurring events for each group depending on their meeting times. The group meeting times vary massively and you can think about every possible combination for example: "every second and last tuesday in every second month" and so on... This was no problem with this module! After that you can easily view and modify the events for the specific group: After creating recurring events for all of the 85 groups we now have about 5000+ event pages in the backend. This is huge! As expected from ProcessWire I did not notice any downgrades in the performance. The last thing I did - with the help of @bernhard- was to set up an "overview calendar" in the backend to get a quick look at all occurring events (for all groups): If you know how to do it this is an easy thing. You can hook into the "getEvents" method of the RockCalendar module and return custom - or modified - event data. In my case the overview calendar field is placed on the "group overview" template. This template has no direct event page children, so the overview calendar did not display anything. I used this hook to collect all event pages within the range of a month and return those events as an PageArray to the module as event data (this hook needs to be placed into the init.php!) wire()->addHookAfter('RockCalendar::getEvents', function ($event) { $pageId = $event->arguments(0); $startDate = $event->arguments(1); $endDate = $event->arguments(2); $template = wire('pages')->get($pageId)->template->name; if ($template === 'gruppe-overview') { $events = wire('pages')->find("template=event, rockcalendar_date.inRange='".$startDate." - ".$endDate."'"); $event->return = $events; } }); There you go!
    3 points
  2. Hey @gornycreative thx for your questions ๐Ÿ™‚ I think all that is already possible. RockCalendar uses regular PW pages and PW templates, so you can add any fields you want, eg TinyMCE or also Page Reference Fields. Yeah, that would be nice ๐Ÿ™‚ I might need this for the project that I built RockCalendar for, but not sure yet and for sure not before 2025. But if anyone needs it earlier just let me know.
    1 point
  3. v1.4.1 is now fully translatable ๐Ÿ˜Ž Every aspect of the module! You can translate day names, month names, set start day of the week, set labels of all buttons, etc.! Docs are also updated: https://www.baumrock.com/en/processwire/modules/rockcalendar/docs/translations/
    1 point
  4. hi, looking at your dump, it sounds more like a htmlspecialchars encoding, you may either remove it from the field setting or use htmlspecialchars_decode on the output before json_decode ๐Ÿ™‚ have a nice day
    1 point
  5. I've just released RockCalendar with a hopefully helpful intro video. I want to thank @monollonom and @BrendonKoz for all the input you gave here. If you want a free single site license for testing (and eventually reporting bugs ๐Ÿ˜… ) please write me a PM.
    1 point
  6. i do this sort of thing now a lot, thanks to Ryan's CMS Critic Case Study; this is almost the same as WillyC's code at the above link /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } });
    1 point
ร—
ร—
  • Create New...