gibbonedu/core

1. What this repository is

Gibbon Core is a large PHP school management monolith. It serves the main application, installer, update routines, background jobs, and most shared infrastructure. Feature areas are split into modules, but they all run inside the same codebase and database.

2. Top-level request entry points

The primary web entry points are the root PHP files such as index.php, login.php, logout.php, report.php, preferences.php, installer/install.php, and a set of AJAX/process endpoints like index_notification_ajax.php and index_tt_ajax.php. These act as front controllers or action handlers rather than a single centralized API layer.

3. Core application layer

The src/ tree contains the reusable application framework: authentication, sessions, database access, service providers, view rendering, forms, tables, UI components, and domain gateways. This is the architectural center of the repo and is what modules build on.

4. Data access pattern

Most business logic accesses the database through src/Domain/*Gateway.php classes. The gateways are grouped by business area such as Students, Staff, Timetable, Finance, Reports, etc. This gives the repo a consistent domain-to-database boundary even though the application is not organized as a modern API service.

5. Module system

The modules/ directory is where almost all end-user features live. Each module is a self-contained mini-application with its own page controllers, Process scripts, optional src/ helpers, Twig templates, and module-specific JS/CSS. Examples include Attendance, Finance, Messenger, Planner, Reports, Staff, Students, Timetable, and many admin modules.

6. Page/process split inside modules

A common pattern is “view page” + “process page” + “AJAX endpoint”. For example, many actions have *_add.php, *_edit.php, *_delete.php, and corresponding *Process.php files. This makes the control flow very explicit: render a form or view, then submit to a dedicated action handler that mutates state and redirects or returns JSON.

7. Presentation layer

UI rendering is handled through Twig templates and reusable UI building blocks in resources/templates/, src/View/, src/UI/, src/Tables/, and module-specific templates/ folders. Themes in themes/Default and themes/Legacy provide the visual skin and top-level page templates, while shared CSS/JS live in resources/assets/.

8. Forms, tables, and rich widgets

The app has substantial internal UI tooling: a form builder (src/Forms), table/rendering abstractions (src/Tables), and specialized widgets for charts, timetables, and dashboards (src/UI). This is important architecturally because many modules compose these primitives rather than hand-rolling HTML.

9. Background jobs and scheduled work

The cli/ directory contains cron-style scripts for notifications, summaries, reminders, and system maintenance. These jobs typically read from the database, apply business rules, and send email/SMS or update system state. This is a separate execution path from interactive HTTP requests.

10. Comms and external services

Communication is centralized in src/Comms and related contracts/services. The app supports email, SMS, notifications, and some OAuth-style authentication adapters. Payment integration is abstracted behind service contracts, and third-party settings are managed from admin modules.

11. Installer, updates, and migrations

Installation and upgrades are first-class parts of the architecture. installer/, src/Install, src/Database/Migrations, update.php, and src/Database/Updater.php manage schema evolution and initial setup. This suggests the app is expected to be deployed and maintained over long-lived school installations.

12. Configuration and operational environment

Runtime setup is PHP/MySQL/Apache-oriented, with Docker support in ops/ and a development bootstrap script up.sh. Environment-specific concerns include session handling, caching, file uploads, localization, and system settings stored in the database.

13. Testing and quality gates

The repo includes broad automated tests: unit tests under tests/unit, installer tests, and extensive acceptance tests under tests/acceptance. This indicates that module workflows and UI flows are part of the contract, not just low-level classes.

14. How to diagram it

A good architecture diagram should show: browser or cron job entering the app; shared core services and auth/session; module controllers/processors; domain gateways; the central MySQL database; Twig/theme/UI rendering; and outbound channels like email/SMS/notifications. The key boundary is between shared framework code in src/ and feature-specific logic in modules/.