Leaderboard

Great to hear that! I'm also very motivated as this has been an issue for me (and I guess many of us) for a long time. Things are really going well so far. I had some troubles today with timezone issues (events starting at 10:00 suddenly started at 11:00 from one month to another etc.) and also with the performance of creating recurring events. Turned out I set a generic pagename and PW had to append a unique suffix for every created page and that got slower and slower as pages under that parent grew in count. I've just quick-fixed that by setting a random name via uniqid() and the performance is quite impressive imho (real world speed on my macbook air with ddev): How cool is the live progress bar??? 😎 It works with realtime feedback from the server using SSE. No polling. No sending hundreds of requests to the server 🚀 I also wanted to update the grid above the progress bar, but that also turned out to slow things down a lot, so I turned that off for now. I have to look into that tomorrow. I think it should be an easy fix. But that's it for today 🙂

Thx for sharing! Yeah that's basically the way I have been building things as well for a long time. But adding all the fields and getting every single detail done correctly is so much work, so I decided to finally do it better in a reusable way that has a good and compact ui for clients and does not rely on a multitude of fields. What do you mean by hiding past occurrences? In my case I'm creating events via rrule.js and the start date is always the first event page's date. So recurring events will always be in the future (relative to the first event). This is the UI for creating events and that table shows the items to be created once the user clicks on "create events". That view is really nice as it updates instantly, so anyone should get a very quick understanding of what all the settings do: The idea is to get all the necessary tools for handling events with as minimum effort as possible. So I've already built the RockDaterangePicker field last month. The next step was to add a calendar view. I first added that to the frontend, but then I realised how much effort it is to setup all necessary ajax endpoints and handling all clicks and all that, so I decided to move that into the backend. If anybody needs to show these events on the frontend, this will be as easy as a foreach + page selector or just adding a simple fullcalendar, which is also easy as long as you don't have to deal with managing events (edit, move, change etc). And then I realised that when having all that ready in the backend it might be the right moment to also tackle recurring events. So at the moment the concept is that you add a calendar field to one parent page. There you define which pages to show as events (which will likely be the children of the parent page, but could be any other selector or hook as well). Then for the events all you have to do is to add the daterange field which will be created during installation of the module. This field will tell the calendar where to show events (on which day and time) and it will also save all the info whether the event is part of a series etc...

Here is the interesting part aka links to that project: https://github.com/saoudrizwan/claude-dev https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev That YT channel just sells courses of some kind. And in addition to this: Claude Dev is similar to Aider and AIDEV. You can look them up on YouTube and elsewhere.

How cool? REALLY COOL. My next project needs a calendar and this is going to save the day. I'd like to buy you a beer, or six. Hell, you can have an entire keg 🍻

@bernhard I can't tell you how unreasonably excited I am for this module.

Absolutely true, thx! I think you are right and I'll not add this. Instead I'll try to make the editing interface via FullCalendar as smooth as possible. I think that's the best common ground that every installation will have. Once they have added their holidays to ther calendar they will see them in the month view and then they can move/clone events to the desired dates by drag&drop. That's already possible by just clicking on the trash icon before creating recurring events 😎 Yep, and I've made good progress so far 🙂 What you mention will be supported. That's how it will work (or as mentioned one can exclude items before creation) 🙂

Something like this: $i = 1; foreach($page->my_repeater_field as $item) { echo "<div id='slider-layer-$i'>Layer $i</div>"; $i++; }

I don't think it's good to automatically install modules that aren't bundled as part of the module repository. I believe PagePaths does impact some core functionality when installed (PageFinder results and possibly the $page->path/$page->url properties?) and the fact that it includes a feature to manually rebuild the paths table makes me think that it can potentially get out of sync with the page structure. So I think users need to consciously decide to install it if they want to use the Verify Links module. I've updated the readme to mention the required modules and that they are core modules.

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?

There is always the option to only accept parts of the code Cursor created/generated. From the chat it's easier to see than from composer - still having only the small composer window and looking at the files, you can select the changes you want to apply.

Been trying to get my buddy to field test all of these suggestions you all have been making so I can just wait until a clear winner surfaces after a decent amount of time. 🤣 His feedback after I mentioned Sourcegraph Cody was that Cursor makes it ridiculous easy for the AI to auto-generate, and auto-modify multiple files for him. He's saving to Git far more often due to the lack of a single-action, multi-file undo, but otherwise that's the "gotcha" between all of the other suggestions made after Cursor. The assistants are really coming along blazingly fast.

Ding Ding, a new competitor has entered the ring (for VSCode):

Another thing got me curious: In your gif it looks like you have a calendar in a page, would the idea be that you could have a calendar in a template and then (maybe) show events that could be child pages or pages that match a selector with a page reference field (e.g. for event categories)? This has a lot of potential I think.

What I’m finding particularly useful is your date Inputfield on steroids allowing you to cover almost all cases. On a recent project I went with a FieldtypeCombo + FieldtypeTable to achieve something similar: If the event is happening indefinitely, I create the first 1000 occurences and have a button to create a 1000 more, like in your screencast (though not live). The one thing missing in my contraption is hiding past occurrences (but keep them just in case). In your example, does clicking on the trash icon delete the occurrence or just deactivate it? Having a calendar UI would of a course be a really nice thing to have as well for clients 🙂

Using a service to determine holidays is one option, but then which holiday(s) do you want to support? Governmentally observed holidays, or perhaps even the silly ones, too? Things can get tricky when assumptions start to be made. A (potentially) simpler approach would be to have two other option areas: Dates to Include Dates to Exclude Since you're attempting to tackle recurrence: it may be desirable to have events occur within a range, but then a business will be closed due to an observable organizational holiday (like an owner's birthday), or alternatively a date exception is made where an additional entry would want to be added, and it's known ahead of time. Alternatively, it's just as easy to delete some after creation, or similarly clone. 🙂

I haven't tried that before, but I just tried it now and it does work. For "Default value" you have to enter the value of the dynamic option rather than the label, and the field has to be "Required" as per the default value note. P.S. I just released v0.1.8 which fixes a minor config fields bug, so you might like to upgrade.

Hi @Robin S! Does setting the default value in the field setting help you to set the default selection option? (I am specifically using Radios input) Thanks for this great module!

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?

Thanks! Yeah I've been there several times but never really managed to get something solid. Great!! I'll send you a copy as soon as I have something usable. Wow, that will be very helpful for my project! Thank you. The company behind is even Austrian 😍 I can think of adding "holiday" as an option to the rrule interface. There one could select "Austria" and then I could add a callback that loops over all rrule dates (eg "every day until 1.1.2025") and filters out non-holiday days, which would result in only holiday dates in the events grid of to-be-created events.

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:

RockMigrations v5.2.0 Added a snippet for the RockIcons module/fields. Added a deprecation note for Magic Field Methods. This feature has been moved to RockFrontend, because the way I implemented it to RockMigrations was not ideal. It added a hook for every existing field, which was something I wanted to change for a long time. But as I didn't see any noticable performance penalties it didn't happen until recently 😎 If you have been using magic field methods be sure to update RockFrontend to the latest version and refactor your code until you don't get any deprecation notices in your logs! Logs will be shown in the "magic-pages" log and will even have a notice how to fix it:

@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!

Don't tell anyone but 90% of my ProcessWire code consists only of if/else/foreach/echo statements - nothing more. You don't need more. That's all. My opinion. Ok, nowadays there is a bit more twig involved, and some hooks, and modules... yet not that necessary. Everything beyond that is some kind of voodoo-magic for me. On the other hand: this forum has almost all answers (for starters) already. If not, this community is the best and will help. So... We still have more options: exclusive (on Discord, in the newsletter, ...) short time only starter-price (+$50 every 100 sales) 30-day-money-back-guarantee

Client quote: We just want a simple event calendar. Simple, right? We just add a DateTime field! Not really... One DateTime field is not enough, as we might have a date range, like summer holidays. Ok, so we add a second DateTime field? Ok, but what if we want a single full-day event, like one single holiday? And how would we easily query all events that are "active" in one month? The module is a commercial module and can be downloaded here: https://www.baumrock.com/releases/rockdaterangepicker/ Docs: https://www.baumrock.com/en/processwire/modules/rockdaterangepicker/docs/ Note: There's also a Pro Module by Ryan, which you find here: https://processwire.com/blog/posts/date-range-fields/ - For my use case this module was unfortunately not usable, because the daterange picker that Ryan chose does not support time inputs. As this was a no-go for me and I found the library www.daterangepicker.com which does exactly what I need, I went ahead and built that module. PS: When using AdminStyleRock it automatically applies the primary colour to match your admin style 😎

This thread should get you going: https://processwire.com/talk/topic/4437-delete-orphaned-filesimages-from-siteassetsfiles/ Also, once you have everything cleaned up, TracyDebugger (http://modules.processwire.com/modules/tracy-debugger/) has a Page Files panel that will help you keep track of orphaned files/images going forward.

Hi seedle, Firstly, 2.5 is the current stable version so you should grab that instead. As for page/pages: http://processwire.com/api/variables/page/ http://processwire.com/api/variables/pages/ I am not really sure what information you need, but to clarify, wire('page') is effectively the same as $page, but due to PHP variable scope $page is not available inside your own functions, inside PW modules, or on a script that is bootstrapped to PW. That is when you need to use wire('page'). Same goes for all the PW variables: wire('input'), wire('sanitizer'), wire('user') etc. If you are wondering what $page and $pages are actually for. Basically, $page gives you access to all the fields on the currently viewed page on your site, eg: $page->body $pages gives you access to all pages on your site - you can query the pages you want using selectors, which are Processwire's version of database queries. It sounds like you might benefit from reading through some of the new tutorials: http://processwire.com/docs/tutorials/ and of course the cheatsheet: http://cheatsheet.processwire.com/ Hope that helps!