WebCalendar for WordPress is now live on WordPress.org — looking for testers

[craigk5n]

Hi everyone,

After a lot of work, I've published a new WebCalendar plugin for WordPress to the official WordPress.org plugin directory:

https://wordpress.org/plugins/agenticdaisy-calendar/

A quick note on the URL: I originally submitted it as "webcalendar", but the WordPress.org plugin reviewers rejected that slug as too generic. The plugin is still called WebCalendar in your WordPress admin — only the directory URL uses agenticdaisy-calendar.

This is a from-scratch re-implementation built specifically for WordPress — not a port of the legacy PHP codebase. It keeps the spirit of WebCalendar (events, recurrence, iCal, categories, permissions, remote calendar sync) but is built on a modern stack:

Heads-up for current WebCalendar users: This plugin is completely separate from your existing WebCalendar installation — it has its own database and starts empty. It won't automatically pull in events from your current site. To bring your data over, export it to an .ics file and import it under WebCalendar → Import, or point WebCalendar → Remote Calendars at your existing calendar's iCal feed.

• PHP 8.2+, clean architecture, PSR-4
• React admin UI with month/week/day views (Toast UI Calendar)
• WordPress REST API, Gutenberg blocks, and [webcalendar] shortcode
• Standards-compliant iCalendar (RFC 5545) import/export and remote subscription
• SEO-friendly single event pages with Schema.org JSON-LD, Open Graph, and social sharing
• 36 granular capabilities mapped to WordPress roles
• 1,100+ automated tests, PHPStan Level 9, 85%+ coverage

What I'm looking for:

If you have a WordPress site (or can spin up a test one), I'd really appreciate it if you'd install the plugin and kick the tires. I'm especially interested in:

• Importing your existing WebCalendar .ics exports — does anything break?
• Recurring events — do unusual RRULEs render correctly?
• Remote calendar subscriptions (Google, Outlook, etc.)
• Any rough edges in the UI or unexpected behavior

How to install:

In your WordPress admin, go to Plugins → Add New and search for "WebCalendar", or install directly from:
https://wordpress.org/plugins/agenticdaisy-calendar/

Reporting issues / feedback:

Please use the WordPress.org support forum for bug reports and feedback:
https://wordpress.org/support/plugin/agenticdaisy-calendar/

Or reply right here in this discussion — I'll be watching.

The legacy PHP WebCalendar isn't going anywhere — this is a parallel project for folks who want a WordPress-native experience.

Thanks for any testing and feedback you can offer!

— Craig

[craigk5n]

Quick follow-up — question for long-time WebCalendar users:

For those of you running the legacy PHP WebCalendar (some of you for 10+ years at this point — I see you 👋), I'd really value your input:

What's the one feature you'd absolutely need before you'd consider moving to the WordPress plugin?

I'm trying to prioritize the v1.1 roadmap and the honest answer is I don't yet know which gaps matter most to existing WebCalendar users vs. which I should worry about later. Some examples of what people have already asked about:

• LDAP / external authentication
• Public (non-logged-in) event creation
• Multiple distinct calendars per install (vs. categories/layers)
• Resource booking (rooms, equipment)
• Custom report builder
• Email reminders with specific lead times
• PostgreSQL / SQLite support (the WP plugin is MySQL-only since it rides WordPress)
• Something else entirely

Reply with your "must-have" — or "I'm happy on the PHP version, just curious about the WP one." Both are useful signals.

(And the original ask still stands: if you have a WordPress site and want to kick the tires, install link is at https://wordpress.org/plugins/agenticdaisy-calendar/.)

[AlbaVore]

Hello Craig, Thanks for your work on this. Looks really promising. I have installed the wordpress plugin and installed the [webcalendar] on this page.
https://thegorbals.co.uk/present/the-gorbals-calendar-test/
Its showing what is probably the default calendar without any data and the default them/styleing.
Its not picking up the actual calendar which is here:
https://thegorbals.co.uk/thegorbalscalendar/month.php
It'll probably be something obvious that I am missing here but just thought I'd let you see.

[craigk5n]

Hi Anthony,

Thanks for sending it — but the .ics didn't actually come through on GitHub's end. When you reply by email, GitHub strips file attachments, so the file never reached the discussion (I only see your message text).

Could you email the export directly to me at craig@k5n.us? That's the easiest path. Alternatively, you can drag-and-drop the .ics into a comment box here on the GitHub website (not via email) and it'll upload properly.

Once I have the file I can dig into both the 1-hour time shift and the missing Thursday events.

I'll follow up separately on your styling and "expand the day box to show all activities" questions — good questions, just want to keep this note focused on getting that file.

Thanks again,
Craig

[craigk5n]

Following up on your other two questions, Anthony:

Styling — where it lives in the WordPress plugin

There's no separate calendar CSS file you create, and the plugin doesn't have its own "custom CSS" box. Styling happens in two places:

1. Event colors — these are data-driven, not CSS. Set a color on each Category (and, if you use them, Layers) under the WebCalendar admin menu, and the calendar color-codes events automatically. This is how most people get the look they want without touching CSS.

2. Everything else (fonts, borders, spacing, cell colors) — use WordPress's built-in Appearance → Customize → Additional CSS (or your theme's stylesheet). The calendar markup uses Toast UI's .toastui-calendar-* classes plus the plugin's own .webcal-* wrappers, so you can target those. For example:

   /* tweak the month grid day cells */
   .toastui-calendar-daygrid-cell { background: #fafafa; }
   /* the category legend the plugin renders above the calendar */
   .webcal-category-legend { font-size: 14px; }

   If you tell me the specific element you want to restyle, I'll give you the exact selector.

For comparison, in Classic WebCalendar this was managed under Admin → System Settings (colors/preferences) and the theme CSS — a completely separate system, which is why none of it carries across.

Expanding a day box to show all activities

Good news — this already works, it's just not obvious. In the month view the day cell shows a few events and then a "more" link; click the day's date (or that link) and Toast UI opens a popup listing all activities for that day. So the full list is one click away.

What it doesn't currently do is expand the cell itself to show every event inline (the cell height is fixed, like most month grids). If that inline behavior — or a setting to control how many events show before the "more" link — is what you're after, I can look at adding it as an option in a future release. Let me know which you'd prefer.

[AlbaVore]

Hello again Craig,
Hopefully you got the .ics file via email?

I guess the styling is a big part of the presentation of the calendar especially to give it a relatively seamless integration with the colour scheme of the site pages. So I guess I am trying to get from this:

To this!

Where is the styling for the calendar coming from in the plugin?

There are a lot of activities per day and my preference is for them all to be visible as there are many users who may not think to click on any 'see more' link. Its not a problem the fact that the number of activities per day cause the day boxes to distort the calendar.

Currently I cannot access the Sytem settings in the Admin Tolls panel. I shall open this as a new ticket.

[AlbaVore]

Hello again Craig, I should mention that the Thursdays are loading in the calendar now. Not sure if you have done anything at all. That is no longer an issue.

[craigk5n]

Hi Anthony,

Good news on all fronts — and thank you for the .ics, it was exactly what I needed.

1. Times off by an hour — fixed in v1.0.5.

Your export confirmed the cause. Your events are stored in UTC (each DTSTART ends in Z, e.g. DTSTART:20150420T080000Z), and the importer was saving that raw UTC time without converting it to your calendar's local timezone — so during British Summer Time everything landed an hour off. (Winter/GMT events were fine, which is the tell-tale sign.)

This is fixed in v1.0.5, which is live on WordPress.org now — please update to it.

⚠️ Important about re-importing: the importer skips any event whose unique ID it has already seen, so simply re-importing the same file on 1.0.5 will skip your existing events and leave their (wrong) times in place. To get the corrected times you'll need to remove the previously-imported events first, then import the file again on 1.0.5. If there's no quick way to clear them in your setup, tell me which calendar you imported into and I'll point you at the fastest route.

One thing worth checking while you're there: Settings → General → Timezone in WordPress should be set to a city (e.g. London), not a fixed "UTC+1" offset — that lets the conversion follow GMT/BST automatically.

2. Thursday events — glad that sorted itself. I dug into it with your file and confirmed there's no Thursday-specific bug: recurring Thursday events expand correctly. It was almost certainly the import still settling / a cached view. Nothing further needed there.

3. Styling. Quick recap of where it lives in the plugin:

• Event colors are data-driven — set a color on each Category (and Layer, if you use them) and the calendar color-codes automatically.
• Everything else (fonts, borders, cell backgrounds, spacing) is done in Appearance → Customize → Additional CSS, targeting Toast UI's .toastui-calendar-* classes and the plugin's .webcal-* wrappers.

Looking at your two screenshots (the green-themed classic vs. the plain plugin), most of that gap is background/heading colors and the day-cell borders — all reachable via Additional CSS. If you paste me the specific colors/fonts you want to match from the site, I'll write you the exact CSS block to drop in.

4. Showing all activities in each day box. Understood — you want every activity visible in the cell, not hidden behind a "more" link, and you're fine with the day boxes growing to fit. That's a reasonable default for a busy community calendar where people won't think to click. It's not a setting today (the month grid caps the cell height and shows "more"), but it's a clean enhancement to add — a "show all events in month view" option. I'll log it and aim to include it in an upcoming release. In the meantime, the Week and Day views already show everything for a given day without truncation, if that helps your users in the interim.

Thanks again for the detailed testing — the timezone fix that just shipped is directly thanks to your report. 🙏

Craig

[AlbaVore]

Hullo again Craig, Many thanks for taking the time to respond with such detail. I have attached the full exported .ics file for your perusal. 3. Can you advise where the styling can be done in Wordpress? Is there a need for a separate CSS for the calendar? Where is the styling managed in the Classic setup? 4. Thats fine. I shall open a ticket on the forum to keep the focus on that there. In the wordpress Plugin version is there a way for each day box to expand to show the full list of all activties listed within that day? Is this again a styling thing? You can see what I am seeking to achieve in the Classic version of the calendar. Get back to me when you can and thanks again for you diligence. Best wishes for now

…

On 3 Jun 2026, at 01:08, Craig Knudsen ***@***.***> wrote: Thanks for the detailed report, AlbaVore — this is exactly the kind of feedback that's most useful. Taking your points in turn: 1. Times 1 hour ahead — that's a real bug, not your setup. I traced the import code and the timezone (TZID) of your events is being dropped during the .ics import, so London times get misinterpreted and land an hour off in summer (BST). I've filed it here and it'll be fixed in the calendar core library: craigk5n/webcalendar-core#1 <craigk5n/webcalendar-core#1>. To pin down the exact path, could you send me one VEVENT from your export — specifically the DTSTART line (e.g. DTSTART;TZID=Europe/London:20260604T190000)? That tells me whether your classic install exports with a timezone, in UTC, or as a floating time. 2. No Thursday events imported — this one I can't explain yet, and it's the part I most want to chase. If you can attach the exported .ics file (or even just a couple of the missing Thursday events from it), I can reproduce it directly. A few Thursday entries showing up in the file but not in the plugin would point straight at the cause. 3. Styling from the classic calendar — unfortunately that doesn't carry over. The WordPress plugin is a completely separate system with its own styling (under WebCalendar → Settings, plus your theme's CSS), so there's no import path for the classic themes. You'd style the plugin fresh on the WordPress side. 4. Preferences tabs not working in your classic install — that's a separate issue in the standalone PHP WebCalendar, not the plugin. I notice you're on PHP 8.4.19; the legacy app has some known rough edges on newer PHP. Happy to look, but let's keep it separate from the plugin testing — feel free to open a discussion or issue on the classic WebCalendar repo for it. If you can drop that .ics here (or email it), I'll get #1 <#1> and #2 <#2> sorted. Really appreciate you taking the time on this. — Reply to this email directly, view it on GitHub <#645?email_source=notifications&email_token=AZJ5ACVDCJAMZU5GRC2RPVT455T63A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGU4DKNJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17158553>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZJ5ACRVM7TADQFVAFKQEA3455T63AVCNFSM6AAAAACZV2ALQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMJVHA2TKMY>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AZJ5ACQYW4LSLURZ3JXLHYL455T63A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGU4DKNJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AZJ5ACXLG427TJMXRL6WYS3455T63A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRGU4DKNJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.

[deangky]

Hi,

I installed it on my site as I'm updating the present calendar from 1.3 to 1.9. However when I did, and I used the code feature to show it on a page, the monthly view is not showing correctly at all. The days of the week are completely messed up and nothing is aligned correctly with where they should be. Here is a screen shot, this is the month of August. Not sure if there is a setting someplace, my Wordpress setting starts the week with Monday. I did check that already.

[craigk5n]

Hi @deangky — thanks for reporting this, and for including the screenshot. That was enough to reproduce it straight away, and it turned out to be a genuine bug rather than a setting you'd missed.

What was going wrong

On a site whose week starts on Monday, the month view's column headings were rotated out of step with the grid beneath them. I reproduced exactly what you saw, for August 2026: the headings rendered Wed, Thu, Fri, Sat, Sun, Mon, Tue, while the dates underneath were correctly Monday-first (the first row began 27 July, which is a Monday). So 1 August — a Saturday — appeared under a column labelled "Mon".

Worth saying explicitly: the dates were always correct, and so were the events on them. Only the labels above the columns moved. That's why the whole grid looks scrambled even though nothing is actually in the wrong cell.

The cause

WordPress's wp_localize_script() converts every value it hands to JavaScript into a string, so the "Week Starts On" setting arrived in the calendar as the text "1" rather than the number 1. The calendar library then did its column arithmetic on a string, which silently shifted the heading row while leaving the grid correct. It's fixed by coercing the value to a number.

While tracing it I found a second, related problem: the admin calendar never received that setting at all, so wp-admin always started weeks on Sunday regardless of your WordPress preference. That's fixed too, so the admin and public calendars now agree with each other and with your site setting.

Workaround in the meantime

If you'd rather not wait, setting Settings → General → Week Starts On to Sunday renders correctly on the current release.

Status

Both fixes are committed and will ship in the next release. I've also added regression tests that check the column headings against whatever the site's start-of-week is set to — there were already 121 automated tests running against four WordPress versions and none of them caught this, precisely because only the labels were wrong and every date was in its right place.

Once you've updated, I'd appreciate a quick word on whether August looks right on your site. And thanks again — this was a good catch.