A small PHP + SQLite dashboard for tracking dog‑related activities.
This repository is intended to be a polished, working site and a functional portfolio piece suitable for display on GitHub.
- PHP 8.x (with PDO + SQLite enabled)
- SQLite 3.x
From the repository root, start the built‑in PHP server:
php -S localhost:8000 -t .Ensure doggodashboard.db exists at the repository root and is readable/writable by PHP.
To generate a fresh database, see the db/ folder for schema.sql and data.sql.
index.php,activities.php,appointments.php
UI pages rendered server‑side.assets/utils/dal.php
Data Access Layer (singleton).
UseDAL::instance()for reads andDAL::insert()for writes.assets/utils/datehelper.php
All timezone conversions.
Store timestamps in UTC; useDateHelper::formatSql()for DB writes.assets/utils/helpers.php
Containsh()for escaping,isPost(),redirect(),checkAuthAndRedirect(), and return‑path helpers.assets/actions/*.php
POST endpoints that validate input, call DAL methods, and redirect.
Follow existing patterns (auth enforcement + POST‑only).
- Always escape output using
h(). - Always convert timestamps using
DateHelperbefore writing to the database. - Keep changes minimal and focused — this project is also a portfolio piece.
- Maintain accessibility, consistent UI patterns, and clean code structure.
- Follow existing DAL and action‑handler conventions.
The Doggo Dashboard uses a lightweight, normalized SQLite database designed for clarity, maintainability, and fast read performance. The schema models:
- Users — people who log activities
- Activities — types of events (Potty, Walk, Grooming, etc.)
- Activity Logs — timestamped entries created by users
- Suboptions — structured metadata for logs
- Files — attachments linked to log entries
- Upcoming Events — scheduled future activities
The schema is fully relational, with strict constraints and several denormalized views for efficient UI rendering.
A full ERD and schema documentation are available in db/README.md.
Defines all activity types. Includes icon, color, and whether the activity can be scheduled.
Optional structured flags for each activity (pee/poop, bath/nails, etc.).
Displayed dynamically in the UI and stored as JSON arrays in views.
Every logged event. Stores user, activity, timestamp, and optional notes.
Connects logs to selected suboptions.
Used to generate JSON arrays in denormalized views.
Files uploaded for a specific log entry (vet records, photos).
Stored on disk under /uploads/activities/{activity_id}/.
People who can log activities. Color and button class are used for UI styling.
Scheduled future events such as appointments, reminders, or medication doses.
Activities with an ordered JSON array of suboptions.
Used by the modal to dynamically render checkboxes.
Flattened log entries with user and activity metadata.
Includes JSON arrays of selected suboptions.
Last four logs per activity (excluding the most recent).
Used for hover tooltips and quick summaries.
Most recent log for each activity.
Used on dashboard cards.
Most recent log per user.
Used for user summaries.
Upcoming events with activity metadata.
Used by the scheduler UI.
Indexes optimize:
- Sorting logs by timestamp
- Filtering logs by activity
- Filtering logs by user
This keeps the dashboard responsive even with large datasets.
The project includes realistic seed data for:
- Activities
- Suboptions
- Logs
- Log suboptions
- Upcoming events
- File attachments
Users are intentionally dummy accounts for privacy.
The db/ folder contains:
schema.sql— full database initialization scriptdata.sql— example/demo seed dataerd.uml.txt— ASCII ERDdb_schema.pdf— full schema reference
See db/README.md for details.