Server-rendered, not saved as markup

Blocks can work two ways. They can save their output as HTML into the post content, or they can save only their settings and render fresh each time the page is viewed.

For a calendar, only the second is defensible. Events change; a calendar saved as HTML would show whatever was true on the day you edited the page, and would need re-saving every time the programme changed. It would also break — visibly, in the editor — every time the plugin changed its markup, which is the origin of the “this block contains unexpected content” message people know from other plugins.

A server-rendered block stores your choices and asks the plugin for the current calendar each time. It never goes stale and it never breaks on update.

What it should offer in the sidebar

The view — month grid or list. A category filter. A limit. A date window. Whether to show images and descriptions. And what to display when there is nothing coming up, which matters more on a venue site than any of the others.

What it should not offer is thirty options. A calendar block with a settings panel that scrolls is a block whose defaults are wrong.

Previewing in the editor

The block should show the actual calendar while you are editing, not a grey placeholder saying “Events Calendar”. Placeholders are quicker to build and they push the work of checking onto the person editing, who now has to save and preview to see whether they picked the right category.

Blocks and shortcodes together

Both should exist and both should produce the same output from the same options, because different parts of a site need different mechanisms. The block for pages and posts; the shortcode for widget areas, page builders and templates.

What you should not have to do is learn two different sets of options. If the block's category filter and the shortcode's category filter behave differently, that is a bug, and it is a common one.

Full site editing

In a block theme, the same block should work inside templates — so “upcoming events” can live in a footer template part across the whole site rather than being pasted into each page. That requires the block to behave sensibly when it has no post context, which is worth testing before committing to a theme.