FH-SchoolAn Algerian school management portal with PHP and SQLite

The problem & workflow

Student signs into an academic-year record → teacher opens a permitted subject/class → grades or attendance are saved → administrator publishes announcements and manages accounts.

Key features

• Student dashboards and academic streams/classes
• Teacher subject/class permissions
• Grade entry, notes and absence records
• Announcements and attachments
• Teacher/student administration and charts

Architecture & decisions

• Databases are distributed by year, branch and stream, with separate teachers and posts stores. The design simplifies small local datasets but complicates cross-stream reporting and migrations.
• The historical username:password field is retained for synthetic local accounts and documented accurately. It must not be used for real student credentials.
• Teacher AJAX endpoints now check authentication and the requested class/subject before execution. Public database downloads are blocked by the demo router and Apache configuration.
• Original sample state is retained as a fixture snapshot; restoring it overwrites only demo databases through an explicit reset tool.

Inside the source

• student.php
• teacher.php
• management.php
• student_management.php

A working school workflow in a legacy PHP application

I built FH-School with PHP and SQLite for student, teacher and school administration workflows.

FH-School connects student viewing, teacher grade and absence entry, class and stream organization, announcements and administration. I use synthetic school records for the demo. Database snapshots make it easy to restore the sample state after editing.

The application uses distributed SQLite databases rather than a central database service. That keeps the local runtime compact, but creates operational responsibilities: required files must exist, directories must be writable, and a reset must restore the related databases together. The directory guide explains these responsibilities instead of treating the data layout as incidental.

Checking writes, not only dashboard rendering

I added CSRF protection and examined the teacher's permitted class, subject and student boundaries. A dashboard screenshot alone cannot establish that an edit was saved. The acceptance script verifies stored grade changes, rejects an out-of-range grade, checks absence increments and restores its modified fields.

The original synthetic password-storage behavior remains a documented legacy limitation for local demonstration. A real deployment would need a deliberate account/password migration and a wider administration review. Keeping the design and architecture makes the project's evolution explainable without disguising it as a newer framework application.

Project status

An earlier school portal I built with PHP and SQLite. The included school records are synthetic.

Enable SQLite3 and PDO SQLite. The included synthetic teacher is ahmed / teacher2025. Choose first secondary, scientific stream, class 2 and mathematics for populated fixtures. Set DEMO_ADMIN_PASSWORD in the PHP environment before using demo-admin administration. Stop the server before fixture reset. Passwords in the original synthetic teacher/student fixtures remain legacy plaintext.