faithcatholic / custom_events
Converts date filter to an ajax filter.
Package info
github.com/FaithCatholic/custom_events
Type:drupal-module
pkg:composer/faithcatholic/custom_events
Requires
None
Requires (Dev)
- drupal/calendar: *
- drupal/devel: *
- drush/drush: *
Suggests
None
Provides
None
Conflicts
None
Replaces
None
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 tonode_events_formandnode_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_calendarand a displaypage_1, using the Calendar month style, with an exposeddatefilter that hasminandmaxinputs 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 configurationpermission. 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-dand 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
relattribute 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 startruns the bootstrap:poserbuilds the Drupal project, and on an empty database it runsdrush si, symlinks the module intoweb/modules/custom/custom_events, enablesdevel,calendarandcustom_events, then prints adrush ulilink. Credentials areadmin/1.ddev phpcsandddev phpcbfrun coding standards.ddev phpstan --level=6 -c ../../../../phpstan.neonruns static analysis with the repo config. Plainddev phpstanignores that config because the add-on symlinksphpstan.neonwith a broken relative path, so it runs at level 0 without thenew staticignore.web/andvendor/are generated and ignored; only the module files are versioned.
Notes
- The hooks live in
src/Hook/CustomEventsHooks.phpusing the Drupal 11 hook attributes. The procedural functions incustom_events.moduleare#[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.