bernhard

Then you can do this: $field = $modules->get('InputfieldText'); $field->collapsed = wire()->user->isSuperuser() ? Inputfield::collapsedNo : Inputfield::collapsedHidden; ...

if(wire()->user->isSuperuser()) { // your code } ?

Same here, let's have a meeting!

Hey @FireWire let's have a meeting to look into that issue together?

You could ask an AI to provide additional search terms:

Hey @netcarver very interesting 🙂 I've never worked with them but from the demos these two look like very good candidates: http://fabricjs.com/ https://github.com/bubkoo/html-to-image

Hey @uliverse sorry for the trouble. This cost me some headache today 😞 I can confirm there is an issue and I have to look into that as soon as possible. I really did a lot to make the experience as smooth as possible, but somehow something broke...

Hey @uliverse thx for asking. Please invest 15 minutes to understand what npm is and does: I've added this section to the readme: https://github.com/baumrock/site-rockfrontend Does that help?

Hey @Stefanowitsch I'm not using SCSS in any project so I don't have a quick answer and I'd appreciate if you could debug this on your own and let me know if anything has to be changed in the module to make it work. The SCSS support has been added by a PR: https://github.com/baumrock/RockFrontend/pull/29 Maybe you can ping the author about the problem?

Thx @adrian I don't know why but now it works. Maybe I had a typo, maybe something else, I don't know 🙂

Hey @adrian I'm using ProcessPageList() to render a pagelist in my custom process module. I wondered why I only get bd() calls in the debug bar for ajax requests when collapsing a tree item, but not for the very first one. This is my code: <div id='pageviews'></div> <script> $('#pageviews').ProcessPageList({ rootPageID: 1, showRootPage: true, ajaxParams: {'rockcounter': true}, }); </script> I then tried wrapping that code in setTimeout() with a delay of 1000ms and then I got the bd() calls also for the very first request. Is there any recommended way of dealing with this? I tried to wait for dom ready, but that seems to be too early and tracy didn't catch the first request. On my laptop it works with a delay of 100ms, but in other setups it might be different, so I'm wondering if there is a solid way of waiting for tracy to capture the ajax call?

Does anybody of you guys have some numbers in how much faster PW gets when using nginx instead of apache?

Good point, guess I was just too lazy 😄 Definitely better, thx!

There you can input 1,2,3 for "every 1st monday". Thx for the question, I added this: With that ui really complex rules are possible and imho quite easy to understand:

Very well done! Looks great. What does it show if "every 1 day" is selected? I also thought of hiding those settings based on the frequency dropdown, but I realised that they can be used in a combined way as I showed above. Not sure what to do about this. Sometimes it might be preferable to have more options, sometimes it might be better to have a slicker ui...

Thx @szabesz I've corrected this! Now it is in sync with the resulting rrule text 🙂 @monollonom the interface is nice, but also limited as far as I can see? Would the rule shown in the screenshot above be at all possible in your UI? Or what did you want to say with your post?

I removed the header in simple mode to be even more compact: In advanced mode the header will be shown:

Thx. I changed the default pagination size to 5 instead of 10 which makes the grid almost half the vertical size: If anybody needs to see more events the pagination size can be changed via dropdown. I think completely hiding it is not a good idea, because the live preview is important to double check the result of the rrule that is setup above. For example it's easy to forget to change from "every day" to "every week" and with the live preview one can instantly see that, because days will be mo, tu, we, th, fr... instead of mo, mo, mo, mo...

Cool, thx 🙂 Thx a lot. Always appreciated! Actually it's the other way round. I think I can just remove the warning 😄

Hey @gebeer thx for choosing RockPdf and thx for the great write up 😎 I agree with @gmclelland that the pdfs look very good! 🙂 I'm wondering why you have append = true here? Some background for anybody interested: This flag is intended for multi-language use, where you might want to create multiple versions of one pdf (english, german, etc.). Using this flag you can foreach over all languages and then create the PDF in that language and append it to the file field in question 🙂 Maybe that's why you are using it? Then this background info might be worth to mention 🙂 This is a real gem! For anybody not aware of this see https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/dom/

This is a demo of how to use the new trash feature 😍 And this is a demo of how to create a quite complex custom recurring schedule: I think this should already be quite usable!

Done! Here is the link for everybody to submit a review 🙂 https://www.softaculous.com/review/ProcessWire If you are short on time: https://www.softaculous.com/rate/ProcessWire Both without registration!

Exactly. That's one of the advantages of this concept 🙂 The UI is the tricky part... Yeah a draft is already there 🙂 But there is more to it to cover all options. That's the next part to tackle 🤞

It will be a standalone module, but for the recurring events part you will need the "RockGrid" module. Other than that there will be no dependencies, no RockMigrations, no RockFrontend.

Thx @erikvanberkum! Don't see the need to replace cal.com as it is free and works very well and has lots of options that I'd have to rebuild. RockCalendar will not handle timezones on its own. It will always store UTC dates in the database. If you need to support timezones than you can do so, but you have to implement that on your own. That should not be a big deal, as the part on how you present all dates to public users will be up to you anyhow. So in my case I manage events for a cave. They have a schedule with several dates for guided tours. For example on Saturdays at 14:00 from May to end of October. When testing this use case I realized that after passing the daylight saving change date all following events where @ 15:00 instead of 14:00 (or 13:00 instead of 14:00 I can't remember). To prevent this I let fullcalendar think that all entered dates are actually UTC dates. UTC does not have daylight saving so whenever anyone enters 14:00 it get's displayed as 14:00; That's it and that's how fullcalendar handles timezones itself, as far as I understood: https://fullcalendar.io/docs/timeZone When presenting those dates to users I will ignore that fact that dates are technically UTC dates and just present them as they are. That means that when anybody is browsing through the calendar he/she will see all tours starting @ 14:00 and he/she will expect that to be a local time, which is the case even though the date is technically stored as UTC. If I did that differently the user would see 13:00 as start date for events until October and 14:00 for events after 1st of October (or something like that, don't know when the actual change happens as my smartphone will do the switch for me 😄 ). This works for all websites presenting dates to local customers in one single timezone. 2 things to mention here: If anybody from another timezone was going to edit an event in the backend, he/she would still see 14:00 as time, which might be totally off his/her local time but will be correct for the local timezone of the location the event takes place. If the website presented events to users from different timezones the conversions would have to be done by the developer of the frontend. I think this should be quite easy though. Maybe we'd need to add a setting to the module in which timezone all dates are stored so that the frontend knows how to convert them to local times. Maybe it would need some modifications to the module. We'll see. If anybody knows that already please let me know. The plan is to handle all that by the single DaterangePicker field. So no need to setup any new templates. No need to setup anything else. No need to construct any complicated selectors. Just add the daterange field to your event template and that's it. And to query events it will be "template=event,daterange.inMonth=2024-08" or similar and you'll get all events including all recurrences. I use a hook to only show the daterange field of recurring events and hide everything else as everything else will be inherited from the main event. That means all occurrences are of the same type and have the same fields etc. just only the main event has all the fields populated. I'm working on that. It's not that hard, the only annoying thing is that I need to support both the calendar UI and the use case when someone edits events via the page tree. Both should be possible imho and unfortunately as it means more work. Yes. I thought of adding another grid that lists already created events that are part of the series, but not sure if that's good or not. Actually I have an idea that might also solve the problem mentioned above... I'll have to try this today or tomorrow! Generally speaking I'll add a switch that lets the user choose from edit this event edit this and all following edit all events But it's not so easy unfortunately as that could mean we need to update 1000s of pages and therefore I'll need a gui with a progressbar again... That's why I think it will be necessary to add a second grid to the daterange field. It adds bloat to the UI but the other option would be to save the job in the background and process it via cronjob, but that means a more complicated setup and no instant feedback to the user. I think a second table is the better and more flexible option. Yeah me too, thx 🙂 It's actually really easy. Just a Page::loaded hook protected function inheritFieldValues(HookEvent $event): void { /** @var Page $page */ $page = $event->object; if (!$page->hasField(self::field_date)) return; $date = $page->getFormatted(self::field_date); if (!$date->isRecurring) return; $mainPage = $date->mainPage; if (!$mainPage->id) return; foreach ($mainPage->fields as $f) { if ($f->name == self::field_date) continue; $page->set($f->name, $mainPage->get($f->name)); } } There are some downsides with this again, but that's only an issue for advanced calendars and should be no issue for 99,9% of use cases. Thx for the great use case!! This can quite easily be accomplished with how I developed the module. It would need some modifications but nothing complex I think. My idea would be to have one global description and then have an additional field that is explicitly not inherited. So the main description could show something like this: So every event would show the general info and then merge the individual book info. If the book-info is edited it only affects one event. If the general info is edited it would update all events (as it is inherited). The problem here is scalability. What if a user wants to create 1000 recurring events? Or maybe only 100. How would you do that? One option is to do that in the background. That means a possibly veeeeeery long loading time after save. Or maybe even a timeout. Or maybe the user hitting refresh several times and creating too much events or crashing the server or whatnot. The other option is a background job. Also with downsides as mentioned above. I think the preview table is the most intuitive and flexible solution. But if you have better ideas go ahead 🙂