ICS Calendar 10.6 and ICS Calendar Pro 4.3 released

Wrapping up our big late December-early January development push, ICS Calendar version 10.6 and ICS Calendar Pro version 4.3 are now available!

These versions include a wide ranging number of “under-the-hood” changes as well as some improvements you’ll notice on the page. Some of these were detailed in “teaser” blog posts earlier this week. The most significant changes are:

Updated parameter defaults in ICS Calendar 10.6
New “Masonry” view in ICS Calendar Pro 4.3

Here’s a quick overview of a few of the other changes:

ICS Calendar 10.6

Improvements to AJAX loading.
Added admin page option to turn on/off the new parameter defaults.
Moved all CSS and JS loading to footer with conditional loading. This is significant in that it means the ICS Calendar CSS and JS files are only loaded on pages that actually contain a calendar, instead of on every page of the site.
Various improvements/streamlining to debugger output.
Various other bug fixes and CSS improvements.

ICS Calendar Pro 4.3

Numerous improvements to Full view.
Layout refinements in Calendar Builder.
Various other bug fixes and CSS improvements.

These two version updates include the largest number of code changes in some time. Given the number of changes, we have tested these updates extensively over the past few days. However, it is possible, as always, that new bugs have appeared but gone unnoticed because we can’t test every possible theme/plugin configuration. If you notice any issues with the free version, please submit a ticket on the WordPress Support Forums. And if you spot issues with the Pro version, please use our Pro Support Forums.

I’ve also added a note to the ICS Calendar changelog that I will copy here verbatim. This pertains to code validation. It is always my intention that all the code I produce, whether it’s custom work on client sites or code output by this plugin, should be 100% valid. But historically, it has not been valid to include <style> tags inside the <body>. But is that still the case? read on:

Note regarding the validity of <style> tags in the <body>: ICS Calendar has long included <style> tags in the <body>, specifically for feed color coding. While this has technically violated earlier HTML specifications, and still causes validation errors, there is no practical way around it, as these styles are only defined when the shortcode runs, which is after the wp_head hook has already run. Meanwhile, there is another conflicting consideration, which is the unnecessary loading of ICS Calendar’s CSS and JS files on every page of the site, regardless of whether or not a given page contains a calendar.

This version of ICS Calendar (technically) exacerbates the first issue while resolving the second: we have now moved all enqueuing of ICS Calendar’s CSS and JS to the wp_footer action, rather than the wp_enqueue_scripts action. This allows them to be inserted by the shortcode function to ensure that they only get loaded on pages that actually contain a calendar.

While this technically exacerbates the problem of <style> (and <link>) tags in the <body>, the latest HTML spec (5.3) does allow <style> and <link> tags for CSS in the <body>, addressing the practical reality of CMS-type systems that need to be able to insert this code after the <head> has been generated, and consistent with the fact that all major browsers have always allowed this without issue. These pages may not validate, but that is because the validator is using an outdated version of the spec. A “vanilla” installation of Gutenberg-era WordPress itself already inserts <style> tags near the closing </body> tag, so ICS Calendar’s inclusion of these tags does not directly impact whether or not a page validates.

Thanks as always for your continued use and support of ICS Calendar!

—Scott