Developer Guide

Extending Learnomy from a theme or a plugin of your own.

Pages in this section#

Where the rest of the developer material lives#

Learnomy's hooks and filters are explained on the page for the feature they belong to; each of these pages ends with a For developers section. The Hooks Reference lists all of them in one place and is regenerated from the code, so it cannot drift from it:

Working with stored dates#

Learnomy's tables declare their timestamp columns datetime NOT NULL DEFAULT '0000-00-00 00:00:00', which is what MySQL stores when a write leaves the column out. That value is awkward to test for: it is not empty, and strtotime() returns a large negative number, which is truthy - so the obvious guard formats it as "November 30, -0001" and a comparison reads it as long past.

If you render a stored date in a template or an extension, use the helper rather than writing your own guard:

echo esc_html( \Learnomy\date_label( $row->created_at ) );          // "August 3, 2026" or "—"
echo esc_html( \Learnomy\date_label( $row->expires_at, 'Never' ) ); // custom fallback
echo esc_html( \Learnomy\date_label( $row->issued_at, '—', 'Y-m-d' ) );

It returns the fallback for all four ways a date can be missing - NULL, an empty string, the zero-date sentinel, and anything that does not parse - so you cannot handle three of them and meet the fourth in production. \Learnomy\is_zero_date( $value ) is the bare predicate when you need to branch rather than render.

Writes are handled for you: Model::insert() and Model::update() fill in created_at and updated_at when you omit them, so new rows never carry the sentinel. A value you pass explicitly is always kept - an importer backdating records keeps its own dates - and created_at is only ever set on insert, so an update cannot rewrite a row's history.