ASB Calendar Advance

Changelog

2.18.2

• Changed: the tooltips – event details on the month calendar and the tooltip on a date – are now drawn by the plugin itself. They used to be built on Tippy.js 6.3.7 and Popper 2.11.8. Tippy.js is no longer maintained upstream, so both have left the package, which now holds no third-party code. A page with a calendar loads two scripts and a stylesheet fewer: about 23KB over the wire instead of 37KB, counting the new tooltip code.
• Improved: moving the pointer across the calendar no longer flashes a tooltip at every event it crosses; the first one waits a moment, and once one is open the next opens at once. On a touch screen, scrolling the page leaves an open tooltip where it is, and a tap elsewhere closes it. A tooltip taller than the room around it scrolls inside instead of running off the screen. It fades and lifts in and out, except for visitors whose system asks for reduced motion, the arrow now shares the box’s shadow, and Escape closes it.
• Improved: an open tooltip stays on its event or date when a smooth-scrolling or parallax script keeps moving the page after the scroll itself has ended. Those scripts move the page without telling anyone, so the old tooltip was left hanging over the wrong day.
• Fixed: on a holiday that was also today, the date number lost the holiday colour and turned dark, while the holidays either side stayed red. The “today” badge cleared the date’s own colour so that its number would read well on the badge. The number now takes the date’s colour whenever it reads well on the badge – the default yellow badge with the holiday red does – and keeps the badge’s own text colour on a badge that is itself dark or red. The settings preview follows the same rule.
• Fixed: the holiday name that appears when the pointer rests on a holiday had not appeared since 2.18.0. The small replacement for jQuery did not handle mouseenter / mouseleave listened for on a parent element, which jQuery quietly turns into mouseover / mouseout; it does the same now, and a test compares it with jQuery itself.
• Note for site customisations: the tooltip’s class names changed. .tippy-box is now .asbcala-tip (.asbcala-tip-light for event details, .asbcala-tip-hours for the tooltip on a date) and .tippy-content is now .asbcala-tip-content.

2.18.1

• Fixed: tapping the date or the calendar icon on the “today” widget did not open the full-screen month calendar. Two things introduced in 2.18.0 caused it: showing an element that a stylesheet hides did not put a display back, and a selector containing :visible made the browser reject the whole query, which stopped the rest of that function from running. Both are covered by tests now, including one that actually taps the widget and checks the calendar appears.

2.18.0

• Changed: the calendar no longer loads jQuery. It was the largest single piece of JavaScript a visitor received – 87KB of source, around 30KB over the wire – and on a site that shows the “today” widget the calendar is on every page, so jQuery was too. What the calendar actually used of it was 32 methods and three helpers, so it now uses a small replacement that ships inside its own script. Nothing about the calendar behaviour changes, and one request per page disappears with it.
• Note for site customisations: the events this plugin announces – asbcala_modal_viewed (an event was opened in a modal) and asbcala:monthRendered – are now browser events. A jQuery(document).on(...) listener still hears them. The one difference is the second callback argument: it now travels as e.detail[0], because a browser event cannot carry extra arguments the way jQuery own could. document.addEventListener('asbcala_modal_viewed', function (e) { var postId = e.detail[0].post_id; }) works with or without jQuery.
• Note: the other direction is not supported any more. Firing one of these events with jQuery(document).trigger(...) no longer reaches this plugin own handlers; dispatch a browser event instead.
• Note: if your theme or another plugin uses jQuery without declaring it as a dependency, it was relying on some other plugin to load it. The correct fix is for that code to declare it, but the filter asbcala_keep_jquery (return true) restores the old behaviour immediately while you sort it out.

2.17.2

• Fixed: a page that placed the calendar the way this readme describes got neither the stylesheet nor the script. When deciding whether to load its assets the plugin only looked for the original [asbcala_shortcode] spelling, so a page built with [asbcala_calendar] – the spelling in the installation steps, in the questions below and on the settings screen – or with the calendar block was left with a bare, unstyled table that never filled in its events. All three ways of placing a calendar are recognised now.
• Fixed: this readme still promised an event list view and a category filter for the list. Neither is in this package – both belong to the separate Pro edition, together with the simple date-only view – so the promise has been removed and the Pro section now names those views. The screenshot captions and a few directions in the questions below have been brought into line with the screens this package actually has.
• Changed: the front-end script and the stylesheet no longer carry any part of the Pro edition’s displays. The PHP for them left this package in 2.16.0, but the script and stylesheet were never trimmed to match: they still held the whole event list with its paging and category filter, the simple view, and the Today’s Schedule widget, none of which anything in this package could reach. The script is now about half its former size and the stylesheet about a third. The shortcode also drops the attributes that belonged to those views, including theme, and [asbcala_calendar] draws the month calendar whatever attributes it is given.
• Changed: the two “AJAX Loading” settings are gone from Advanced Settings. They only ever governed the Today’s Schedule widget, so in this package they saved a value that nothing read. The month calendar has always requested its events after the page itself has loaded, so it keeps working behind a page caching plugin without a switch. Values already saved are left untouched.
• Changed: the calendar block no longer declares the view and simple-mode attributes, which belonged to the Pro edition’s displays.

2.17.1

• Fixed: event details could not be shown in a pop-up. The choice between opening the event’s own page and showing the details in a pop-up was there in the settings screen, and the pop-up itself was in the package, but the front end was always told to open the page – so picking the pop-up did nothing at all. The setting is now honoured, and the pop-up works as the screen describes.
• Fixed: the colour rules for particular dates took what arrived from the form without first checking its shape. A submission that sent a list where a single value was expected could raise a fatal error on PHP 8. Each rule and each of its fields is now checked before it is touched, and a rule already stored in an unexpected shape is skipped when the settings screen is drawn instead of stopping the page. The same check was added to the colour labels, the date lists, the event sources and the calendar’s month limits.

2.17.0

• Added: static-site support (ASB Smart Builder’s Static WordPress). When the ASB Static Publisher is active and switched on, the calendar stops using admin-ajax and nonces: month data, the initial data, event details and the ICS feed are served at /asb-calendar/… as plain JSON and text, the front-end script reads those files, and a manifest lists them for the build tool. A daily job asks for a fresh build after midnight. PWA update notices are held until the static site has actually been published. Nothing changes on a site without the publisher.

2.16.4

• Changed: the free package no longer carries any part of the opening-hours editor. Until now the colour-label settings still drew an “Business Hours Override” panel with time fields, even though this build has nothing that shows opening hours on the calendar – so anything typed there simply went nowhere. The panel, and the code behind it, are now only in the separate Pro edition. Hours already saved by a site that used to run Pro are left untouched, so nothing is lost if that site goes back.
• Changed: the shortcode examples in this readme no longer list the simple view, the event list, or their options. Those belong to the separate Pro edition and were never part of this package.
• Changed: removed leftover lines that read Pro-only settings and then did nothing with them, and reworded comments that described this package in terms of what a licence unlocks.
• Fixed: several places took a submitted field straight from the request without first checking it was a single value. Sending a list where a word was expected could raise a fatal error on PHP 8 – in the category colour field, in the event date and colour fields of the post editor, and in the setup wizard’s colour labels. Each of those now checks the shape of what arrived before touching it, and skips anything that is not what the form sends.

2.16.3

• No change to this package. This release fixed parts of the separate Pro edition only.

2.16.2

• No change to this package. This release fixed parts of the separate Pro edition only.

2.16.1

• Fixed: the body of a password-protected event could be read by anyone. The pop-up that shows an event’s details answered with the full text of any published post on the site, chosen by number, without asking for the password and without checking that the post was even a calendar entry. It now answers only for the post types the calendar is set to read, and a protected post is withheld until the password has been entered.
• Fixed: the summary of a password-protected event was also being shown in the hover box and published in the calendar feed. Protected events still appear with their title and dates, as WordPress does elsewhere, but their text no longer travels with them.

2.16.0

• Changed: the event post type and its category taxonomy are now registered as asbcala_event and asbcala_event_category. The old names were “event” and “event_category”, which other calendar plugins register as well. Existing events and categories are moved across automatically on update, and the page addresses do not change.
• Changed: the free version no longer carries the code for the paid features. It used to ship them and switch them off, which is not how the plugin directory works. Nothing the free version offers has been removed.
• Fixed: weekday numbers submitted from the setup wizard are now checked against the seven days rather than merely cast, so a hand-made request cannot write a day that does not exist.

Earlier entries are not listed here: they belong to the shared history of this plugin and its separate Pro edition, and describe releases that were never published in this directory.