Leaderboard

For a current project I have the need to show and manage events. First, I thought I'd just show events as a list. The benefits of this approach are that it is very easy to do and it works well on desktop and mobile. Then I had a chat with @gebeer and we concluded that a real calendar interface is far more intuitive for the average user. I've built such a calendar once on an ancient site (https://www.mistelbach-mustangs.at/events/), but it was a lot of work and so I didn't do it again for any other project. Then I thought let's use google calendars for managing events. That would have the benefit that we get a lot for free (the whole gui for managing events, the data storage, recurring events, etc). But it also comes with downsides: First, clients need to create an account for their calendar on a third party. We will hopefully have many clients on that project, so instructing them to create an account somewhere else and then connecting both apps together is a lot of overhead. Second, events handled by google have a totally different data structure than PW pages. What if I wanted to display those events? What if I wanted to add image galleries to those events? What if I wanted to have event descriptions powered by RockPageBuilder? What if I wanted the best performance one can get using the awesome ProCache? These things are very easy to do when we are dealing with PW pages, but they are hard if we talk to a third party api like the one from google. So I decided to build RockCalendar. A module where a FullCalendar shows PW pages and all the tedious things are already built in (like managing events, creating events, resizing events, managing locales, etc). I've made good progress over the last few days and I think I'll have something to share next month, so I thought I'd ask for feedback what the community thinks would make sense for such a module? Have you ever had the need for such a module? If yes, what would be the key features that you'd want to see in such a module? What would be nice to have? What would be questions that come up in your head? I can't promise, but I'll try my best to incorporate the community's feedback and suggestions into the RockCalendar module to make it as useful and versatile as possible.

@Robin S These property/subfield definitions are in files rather than the database, so there are no database-style IDs. Or, you can think of the property names as the IDs. There is already is a to-do note in the module to add support for property aliases, so that you can rename properties without having to convert data. That's not in this v1 beta version, but likely will be in the next one. That will enable you to rename properties when/if the need arises. But you'll still have to update your own code that refers to any of those names, as would be the case with any other field. When it comes to deleting properties, the no-longer-needed data would be cleaned up whenever it is saved. This is like any other Fieldtype that encodes multiple properties/subfields together (Textareas is one example, Combo is another, depending on the chosen storage method). If you regularly need to rename and delete these kinds of things after development of a site, regular old ProcessWire fields (without subfields) are hard to beat. But either way, you still have to consider your own code that's referring to those fields. Thanks, I will correct the typo!

What do you think of something like this? // somewhere let HelloWorld = ProcessWire.hookable( { foo: "foo world!", ___hello: () => { return "hello world!"; }, }, "HelloWorld" ); console.log(HelloWorld.hello()); // output: hello universe! console.log(HelloWorld.foo); // output: foo universe! // somewhere else ProcessWire.addHookAfter("HelloWorld::hello", (e) => { e.return = "hello universe"; }); ProcessWire.addHookAfter("HelloWorld::foo", (e) => { e.return = "foo universe!"; }); I built a proof of concept module here, but it's already outdated and I'll work on a new version shortly. The reason why I'm building this is because I needed a way to modify some parts of my JS frontend setup on my RockCommerce project. So I added two methods RockCommerce.after(...) and RockCommerce.before(...) where we as a developer and user of RockCommerce customise every part of the Frontend (for example adding custom taxes or pricing calculations). Now while working on RockCalendar I wanted something similar. And while working on RockGrid I had the same need. For example adding custom locales or adding custom callbacks. What is easy as cake in PHP is not so easy to do in JS. So I thought, wouldn't it be nice to have hooks in JS as well? I asked Ryan and he seems to like the idea, so I'll work on that over the next few weeks. As you can see here I will most likely change the module soon to work with JS proxy objects. This is what provides the magic of AlpineJS behind the scenes. Now I'm wondering if some basic Alpine magic would make sense here as well, for example watching a property and firing a callback can be extremely helpful on its own! let demo = ProcessWire.magic({ foo: "foo", init() { this.$watch("foo", (newVal, oldVal) => { console.log(`foo property changed from ${oldVal} to ${newVal}`); }); }, }); demo.foo = "bar"; // will log "foo property changed from foo to bar" I've renamed ProcessWire.hookable() to .magic() in this example, as it does more than just adding hook support. Not sure about "magic", maybe you have better ideas? What do you think? Would that be helpful? What would be a good name? ProcessWire.rock(...) would be my favourite I guess 😄 ProcessWire.proxy(...) would also be an option. Not sure if adding basic apline magic to PW would be a good idea of if adding alpinejs itself would be better? Any JS experts here that want to help with that project?

AltTextGpt for ProcessWire This ProcessWire module, AltTextGPT, is an interface for generating alt text for all of the images in your website, using the ChatGPT Open AI API. Using the API requires an account with the Open AI API and costs money, although its pay-what-you-use and the charges are minimal. For example, alt text was generated for 200 images, using 94 cents of Open AI Credits. You can create an account with Open AI, from this link, and then once you have an API key, you can enter it below, or configure it as a permanent setting for this module via Modules->Configure->AltTextGpt. After configuring the API key as described above, you can then use the form below to generate alt text for images in the site. The module will attempt to generate alt txt for every image that currently has no alt text, one at a time. Generating alt text takes a few seconds for each image, so this is not an instantaneous process. For this reason, if you have many images, we suggest generating alt text for the images in batches. You can also set a batch size below, generating alt text for 10 or 20 images at a time, and then repeating the process, until you have generated alt text for all of the images in the site. After each run, the table above should show that there are fewer images without alt text in the site, until eventually the table indicates that there are 0 images in the site without alt text. Note, for alt text to show up for images uploaded in the body of a CKEditor field, this configuration must be set for that field as described in this comment. How to install this module Copy all of the module files to /site/modules/AltTextGpt/. In your admin, go to Modules > Refresh. Click “Install” for the “AltTextGpt” module (on the “Site” tab). The code for the module is tested and working and is currently here: https://github.com/mhfowler/AltTextGpt

PagePaths is part of the core, just not installed. In your ProcessWire backend go to Modules > Core and install "Page Paths" module from the list. @Robin S I guess your module could install Page Paths automatically, no?

@bernhard This is an amazing undertaking and truly appreciated! I started planning a calendar module a few months ago but just couldn't afford the time to implement it. I think the interface you designed is a great direction. I'm 100% willing to be a guinea pig and help test if it helps. This is definitely a tough one. I could see being hesitant to rely on a third party service to pull this information but the complexity of region and tracking dates might make managing it locally a real beast. Third party service eliminates the need to create complex rrules by just updating holidays locally according to up to date information. Maybe using a service to pull data for current year +/- x number of years and on demand or annually beyond that. Free service, queryable by region and year: https://date.nager.at/Api

That's a very slick interface, congrats @Stefanowitsch Unfortunately to support all possible options there are some more options and this is what I came up with so far: This seems to work for almost all use cases that I could think of so far. The interface could even be improved by hiding options that don't make sense (but it's not so easy to define which they are and when). The only case I don't have a solution so far is "every sunday or holiday at 20:00" Anybody knows or has a good idea how to support holidays as recurrence rule? That's obviously a challenge, because holidays are very specific by region... My best idea so far is to add a "clone" feature to the month calendar view where the client could just drag and drop the event (a guided tour through a cave) from sunday to a holiday and click "clone" instead of "move". That way they could quickly add all events for all sundays and then drag them over to all the holidays...

Sounds very promising @bernhard! I a past project I had the need of creating and managing recurring events, too. Back then there was no calendar module available for ProcessWire, so I wrote my own logic using PW repeater fields in combination with the RRULE PHP library. The interface for a event page looks like this. In this example the event occurs every third tuesday in every month from 4pm - 6pm. I handle the updates of the dates that are displayed in the frontend via a cronjob that runs every night. The date field then gets updated, based on the set of rules that are set for the event: What is handy feature for me is to get an overview of upcoming events. Either in a classic "calendar view" or maybe in a small list overview like here. I list all events within the current week:

RockPageBuilder v5.6.0 We now have customizable block stubs! 😍🔥 @FireWire requested that feature in the forum and I thought it was a great idea, so I added support for it. You can now define your very own boilerplate code with custom classes that you need for your specific project. See the docs here. Added the "rocksortable-added" event so that you can attach custom callbacks to the sortable instance. I'm using this to apply some project-specific classes after block order has been changed (to update the text color based on the current background color of multi-colored pages): See the docs here. I shared a little screencast here and think that is a really cool way of adding color sections to any site. Added the field() method to $block objects. Make sure to also update RockFrontend to the latest version! Fixed wrong sorting of blocks with Umlauts.

@adrian Thank you so much, this fixed the issue.

Thank You very much

I can give a quick reply about the Geffen calendar, but most of what there is to know about it is in that article I wrote. How the show performances (events) came to exist wasn't a concern as that was managed with a 3rd party service, obtained via an API and stored as child pages of a show. The main takeaway from that project was that we needed to simply display upcoming shows in a monthly calendar format (large and small) and when I originally developed the site, I leaned on FullCalendar. However that was total overkill and difficult to maintain because FullCalendar is more than just a way to display events in a calendar format, but an interactive component with dragging and dropping like what you'd get in a real calendaring system (Google Calendar, etc.). It's also built with complex JS which I like to avoid. I just needed an easy way to display information with simple AJAX loading between months. To solve those, CSS Grid (ie, "display:grid") and HTMX fit perfectly with some straight-forward PHP code to build it. One extra improvement that can be made to display a large and small calendar in different contexts while using the same HTML is to use container queries, but because browser support for it a couple years ago was still very low, I avoided it.

Hi @bernhard, this is what worked for me: <?php namespace ProcessWire; $wire->addHook('/emit', function ($event) { header('Content-Type: text/event-stream'); header('Cache-Control: no-cache'); $reference = $event->pages->get('/')->page_selector->title; $selector = $event->pages->getRaw("title=$reference, field=id|title|text|image, entities=1"); $result = json_encode($selector); while (true) { echo "event: ping" . PHP_EOL; echo "data: " . $result . PHP_EOL; echo PHP_EOL; ob_end_flush(); flush(); sleep(1); } }); In the frontend then: // Init SSE and listen to php page emitter let source = new EventSource("/sse/emit/"); source.addEventListener("ping", function(event) { getData(event) }); // Retrieve ping data, parse it and pass the result to the resolveData function function getData(event) { return new Promise((resolve, reject) => { if (event.data) { let result = JSON.parse(event.data); resolve(result); } }).then((result) => { resolveData(result) }); } // Resolve data and update alpine data function resolveData(result) { console.log(new Date().getSeconds()); // It logs correctly every 1 sec Object.assign(Alpine.store('sse'), { fragmentShow: true, id: result.id, title: result.title, text: result.text, image: result.image[0].data, imageDescription: result.image[0].description }); }