Migrating to custom CSS in My Calendar

January 15, 2023

Topics: Plugins, WordPress.

Since adding the notification in My Calendar 3.4 that editing CSS (Cascading Style Sheets) is going away, a few people have had questions about what’s happening. Users want to know how this change impacts them, and why I’m doing it. So I should talk about that a little. This is a significant change, but don’t think of it as an alarming update.

I’ll first discuss what happens with CSS in the plugin right now and why that’s a problem for me. Then I’ll talk about how CSS management is changing and what future changes I’ll can make in the future because of this.

CSS in My Calendar in version 3.4.0 and earlier

When you install My Calendar, it installs the CSS that’s shipped with the plug-in at the time. No surprise there.

When you update My Calendar, it copies your style directory to a temporary directory, then copies it back to the plugin directory. Copying files enables you to keep your edited files. It also forces you to keep out-of-date files.

The CSS you installed is the CSS you use – forever. There is a feature that allows you to update your CSS to match the current version shipped with the plugin, but it’s optional.

If you installed My Calendar in 2012 and haven’t changed styles since, then your CSS is over 10 years old. It has never been changed. It doesn’t have support for features added over the last 10 years and doesn’t use modern tools for layout in CSS. If it had bugs that were later fixed, you still have the bugs in the earlier CSS.

You’ve been able to use a separate custom CSS file for years, and that isn’t changing. If you copy a CSS file and put it in your theme directory or at plugins/my-calendar-custom/styles you can select it instead.

The problems CSS editing causes me

This has been a major headache for years for a few reasons:

  1. There’s a small chance that the copy and restore can fail, and you lose all your customizations.
  2. I have no idea what the CSS for your calendar might be and have to support broken CSS from 10 years ago.
  3. I have limited ability to change classes or HTML (HyperText Markup Language) in the plugin, because your CSS won’t be updated to match.

I added a base style layer a few years ago, called `reset.css`. That base file lets me use some new styles regardless of your chosen style sheet. It’s not a perfect solution, however.

It’s the 3rd bullet point that’s the big sticking point. My Calendar is intended to be as accessible as possible, but I’ve been hindered in making improvements because I can’t change the HTML structure safely. Making this change means I can make more changes to the fundamentals in My Calendar.

That doesn’t mean that my changes won’t break your custom CSS.

If you make the choice to switch to custom CSS, you should do that because you understand CSS and are prepared to edit it in the future. (You can always switch back.)

What is the actual change in My Calendar for 3.5?

First, I’ll only ship one copy of the CSS files in the plug-in. Right now, it ships a directory called `styles`, the editable version, and `templates`, the stable version. This allows you to run comparisons between your CSS and the current version. That comparison won’t be needed once I remove the editor.

Second, the CSS editor and file comparison tools will go away. There’s no reason for me to maintain this: you can edit CSS in so many other ways. You can edit in the WordPress file editor, add custom CSS in the Customizer, or add custom CSS in your theme or custom plugin folder. These are better, more stable, and more secure ways of handling custom CSS.

Third, I’ll add additional CSS variables you can configure in the plugin, and use those variables in all the core style sheets. These will control font sizes, padding, margins, borders, etc. It won’t be the most complete set of controls in the world, but if you don’t want to be editing code, it’ll do a lot of the job.

What changes will start to happen after 3.5?

Version 3.5 will also introduce a new template system that increases the flexibility of custom templates. They won’t be enabled by default in version 3.5, because the code will be sufficiently different that your custom CSS will probably not work very well. (Actually, the template system is already present, but only enabled via filter. It’s still in very early stages.)

The longer plan is that the new templates will become the standard templates. The new templates will be a much more common model in WordPress: a set of PHP (Hypertext PreProcessing) files in an organized structure that you can copy into your theme to replace just that part of a template in My Calendar.

This is all part of a long-term development plan. It started with eliminating custom JavaScript in version 3.3, enabling me to make some significant updates to the core JavaScript. Everything that was ever customizable can still be customized, but the version shipped with the calendar is fixed, and you need to maintain your customizations in your code base.

Have something to contribute?




« Read my Comment Policy