Today marks the release of ICS Calendar version 12.1.0 and ICS Calendar Pro 6.2.0!
These versions include one significant and frequently requested change: ICS Calendar’s static asset files (JavaScript and CSS) now only load on front end pages that actually contain a calendar. This was a feature that did exist in an earlier version of the plugin, but had to be removed due to inconsistent behavior with some themes.
The new method required making some changes to when these script files are registered, along with some extra conditional logic to detect when Pro views that require additional JavaScript files (Full and Masonry) are present on the page.
These changes have been tested against the 40 most popular themes in the WordPress repository and found to successfully load the calendar in all cases, while not loading these assets unnecessarily on pages that don’t contain a calendar.
In addition to this significant change for both the free and Pro versions, Pro includes a couple of other significant improvements:
Block Editor: There was a bug in the previous version of the ICS Calendar block (introduced in version 6.0.0) that would cause the block to refresh unnecessarily on just about any browser interaction (scrolling, changing block focus, etc.), which would result in the contents of the page jumping around. This has been resolved (see below for a note on the existential crisis this triggered for me as an old-school developer).
Full view: Some issues with selecting the correct date range when printing have been fixed, along with a couple of other minor bugs. I’ve identified another issue that I have not yet been able to resolve, involving loading the calendar with an initial date set to the past (e.g. when trying to print a past month, or when the calendar’s entire date range is in the past). This version includes a workaround for printing: only the present date range or future dates can be printed. If you attempt to print a past month/week/year, etc., the print view will jump to the present. Not ideal, but better than a browser hang. There is currently no workaround for date ranges fully in the past, other than to use a different view. Work is ongoing.
That note about my existential crisis
If you’re someone who pays attention to what I do outside of ICS Calendar, such as my personal blog or my YouTube channel, you may know that I am wary of A.I.
I’m not 100% opposed to it, and I try not to be a luddite. But I have grave concerns about its environmental impact, and as an artist, I find its use troubling for anything beyond throwaway jokes. As a developer, I am also wary of it, for reasons I have written about in the past.
I am proud to say that the code in ICS Calendar/ICS Calendar Pro is 100% human-written, by me (except for the vendor libraries I include). Well, that was true, until yesterday.
I was struggling to figure out the ICS Calendar block’s glitchy behavior in the Block Editor. I spent five hours trying to solve the problem. The official developer documentation for the Block Editor is incomplete, inconsistent, and disorganized. Tutorials and guides on other developers’ blogs are too specific to their situations and rarely applicable to my own context. I eventually resorted to whatever I could find in discussion threads on GitHub and StackOverflow, but all of those were several years old.
Finally, in desperation, I turned to DuckDuckGo’s Duck.ai, which is powered by ChatGPT.
Fortunately, those hours I spent had allowed me to home in fairly closely on the exact issue I was having, although I still didn’t know what was causing it. I managed to explain my problem in a single, concise sentence, and I fed that to the chat along with the relevant JavaScript function from my code.
Almost instantly, ChatGPT replied with a cogent, single paragraph explanation of why my code wasn’t working, and a minimally-modified version of my function. (It still even retained some of my code formatting quirks!)
(In case you’re wondering what the problem was, it was that I was inadvertently re-polling the server to update the list of saved calendars for the dropdown that appears in the sidebar. That re-polling got triggered any time the Block Editor interface updated, which includes scrolling or any change of block focus. The new version only retrieves the list on the initial insertion of the block. That’s it.)
Now here’s the important part: I thoroughly reviewed the modified function, so I understood what had been changed. Then I tested it and, much to my delight, it worked perfectly.
After that success, I decided to throw a few of my other “back burner” issues at it. Sadly, it was not able to help with either of those, and I once again spent a few hours going in circles on those, before deciding to just set them aside. (One was the aforementioned problem with past dates in Full view. The other was something so trivial that it doesn’t really need to be fixed anyway.)
I did also have ChatGPT help me to refactor a couple of small JavaScript functions — I’m personally much stronger with PHP than with JavaScript — on the Full view template, and again I carefully reviewed the output before adding it to the plugin.
The lesson here is: A.I. can be a helpful tool for debugging, but it can’t solve every problem, and what it produces still needs a human review before it should be used in production.
Oh, and uh… no, I did not have it help me write this blog post. I’m one of those humans who actually uses em dashes.
—Scott