Search by

faithcatholic / custom_events

nketchummjones

Converts date filter to an ajax filter.

Package info

github.com/FaithCatholic/custom_events

Homepage

Issues

Type:drupal-module

pkg:composer/faithcatholic/custom_events

Statistics

Installs: 1 508

Dependents: 0

Suggesters: 0

Stars: 0

v4.0.0 2026-09-10 00:46 UTC

This package is auto-updated.

Last update: 2026-09-11 22:21:04 UTC


README

Glue between an "events" content type that stores its dates in a date range field and the Calendar module, which needs a single date field. On every event node form submit the module copies the start of the configured date range field into the configured single date field, so the node shows up in the calendar view. On the calendar itself, it turns each day cell of the month view into a link and adds JavaScript that, on click, fills the exposed date filter with that day and submits the view through AJAX, so clicking a day filters the event list without a page load.

Requirements

Drupal 10.3+ or 11, plus the Calendar module (which brings in Views and Datetime). The core Node and Field modules are declared as dependencies too.

The module hard-codes several pieces of site configuration and does nothing useful without them:

  • A content type with the machine name events. The submit handler is only attached to node_events_form and node_events_edit_form.
  • Two fields on that content type: a date range field to read from and a single date field to write to. Both are chosen in the settings form; the sync is skipped while either is unset.
  • A view with the machine name events_calendar and a display page_1, using the Calendar month style, with an exposed date filter that has min and max inputs and AJAX enabled. The JavaScript targets the exposed form by its generated id, views-exposed-form-events-calendar-page-1, and the day links by .calendar-calendar .month-view td a[rel].

None of this is shipped with the module. A fresh install enables cleanly but has no visible effect until the content type, fields and view exist.

Installation

Install as usual at /admin/extend, or drush en custom_events. Install works without the site configuration above; the module just stays inert.

Configuration

  • Settings form: /admin/config/system/custom-events, listed under Configuration > System. Requires the administer site configuration permission. There is no module-specific permission.
  • Source date field: the date range field on the events content type.
  • Calendar date field: the single date field the calendar view is built on.
  • Both selects list every field storage defined on nodes, not only date fields; pick the right ones.
  • On each event form submit the start value of the source field is written to the calendar field as Y-m-d and the node is saved again. If the source field is empty, the calendar field is cleared.
  • The sync only runs through the node form. Nodes created or updated programmatically, by migration or through REST are not touched.
  • The month view day links carry a rel attribute with the date, which the JavaScript uses to fill the exposed filter.

Development

The repo carries a DDEV setup that installs a Drupal site around the module, using the ddev-drupal-contrib, ddev-drupal-contrib-extras, ddev-drupal and pimp-my-shell add-ons.

  • ddev start runs the bootstrap: poser builds the Drupal project, and on an empty database it runs drush si, symlinks the module into web/modules/custom/custom_events, enables devel, calendar and custom_events, then prints a drush uli link. Credentials are admin / 1.
  • ddev phpcs and ddev phpcbf run coding standards.
  • ddev phpstan --level=6 -c ../../../../phpstan.neon runs static analysis with the repo config. Plain ddev phpstan ignores that config because the add-on symlinks phpstan.neon with a broken relative path, so it runs at level 0 without the new static ignore.
  • web/ and vendor/ are generated and ignored; only the module files are versioned.

Notes

  • The hooks live in src/Hook/CustomEventsHooks.php using the Drupal 11 hook attributes. The procedural functions in custom_events.module are #[LegacyHook] stubs for Drupal 10 and can be removed once the minimum supported version is 11.1. The form submit handler stays procedural because it is registered by function name in #submit.
  • There are no plugins, so there are no annotations left to convert to attributes.
  • Every event save through the form triggers a second node save from the submit handler, which fires the entity hooks twice.