It’s nearly a month later than I’d hoped for, but I’ve just released My Calendar version 3.4.0. As with every major release, there are some significant changes in this update. A lot of the big changes are under the hood. The last release updated the processes of creating and administering events, but this release is more subtle.
This release refactored how settings are saved in the database, added a couple new options for viewing the calendar on the front end, and “end-of-lifed” the ability to edit stylesheets from within the plug-in. That will be removed for good in version 3.5.0.
It also added a lot of infrastructure that will be needed by the next release of My Calendar Pro. My Calendar Pro will ship with the ability to create custom fields without code and support for AJAX form submission. Both of those features depended on making structural changes in My Calendar.
One important change is that I revamped the accessibility of the main calendar navigation. In 3.3.0, I removed support for custom scripting. This allowed me to more aggressively move forward with improvements to how navigation worked, because I no longer needed to worry about those possible dependencies. Now that I’m moving away from supporting custom CSS (Cascading Style Sheets), I’ll also be able to make some design changes when the new templating system ships.
What do you mean I can’t use custom CSS?
Sorry if I was unclear!
So that we’re totally clear: you can 100% use custom CSS and custom scripts with My Calendar. However, there are no longer systems in My Calendar that save or update those. You can select custom styles, you can preview them – but they aren’t saved or managed by My Calendar.
Among other things, this means that sites that are using integrity-checking systems to verify that your plug-in matches the version at WordPress.org will be able to check My Calendar. In the past, those would always fail because of a mismatch in the editable stylesheets.
Get the details
The full changelog is available here: My Calendar v3.4.0 Release.