Attendify: a PHP attendance and leave portal built on ag-Grid

What the portal replaces for a teacher

Attendify is an attendance and leave management portal written in PHP with MySQL behind it and ag-Grid in the browser. The README frames the problem in classroom terms: traditional attendance marking is tedious and error-prone, it drains class time, and it leaves students worried about record accuracy and leave approvals while teachers track compliance across several classes. The project's stated goal is automating the database updates behind those records so the marking itself takes less of the lesson.

The interface reflects those priorities. It uses a structured sidebar, real-time statistics cards and a modern data grid, and the dashboard shown in the README displays student lists, attendance percentages and the status of current leave applications. A separate login page handles portal authentication for faculty.

The repository describes itself with a Project Status badge reading Complete, which is worth holding in mind. The README reads as a finished course project rather than a product with a roadmap, and the tree supports that reading: alongside the PHP files sit a written project report in both.docx and.pdf form, a video of the web project demo, and a handwritten entity relationship diagram in the docs folder.

api.php as the single action router

Every request in the architecture goes through one file. The client-side layer is HTML5, CSS3 and ES6 JavaScript, with an AG-Grid engine holding the data grid and an AJAX request manager built on the Fetch API. The server side is an Apache and PHP environment holding api.php, described as an API gateway and action router, and db_connect.php, described as the MySQLi connection manager. The database layer is a MySQL instance named attendance_portal_beenishtasaffar, reached over port 3316.

Routing is by query string, and the README's request lifecycle shows the pattern exactly:

GET api.php?action=getStudents&course_id=CSE101&date=YYYY-MM-DD
POST api.php?action=markAttendance

The first action takes a course identifier and a date, the second carries student identifiers and statuses in its payload. Responses come back as JSON, which the browser parses and renders into ag-Grid rows.

This shape has one clear advantage and one clear cost. The advantage is that there is no framework to learn and no routing layer to configure; a reader can follow a request from the Fetch call to the SQL statement. The cost is that the action names, the parameter names and the response shape are conventions held in the code and in the interface, not in a schema anyone validates, so a mismatch surfaces as a broken screen rather than an error message.

The attendance marking request lifecycle

The sequence diagram in the README walks through one full marking session, and it is the clearest statement of the data model in the project. The teacher selects a course and a date in the browser. The browser then asks api.php for students, and the backend queries the database for students registered in that course while verifying leave status, returning names, registration identifiers and pending leave applications in one response.

Marking follows. The teacher toggles each row between present and absent and presses submit, and the browser posts the student identifiers and their statuses back to api.php. Two database writes happen in sequence: an insert into the attendance table carrying the status, the date and the student registration identifier, then an update to studentregisteredcourses to increment the totals. The API answers with a JSON success confirmation, and the browser updates its state and shows a confirmation notification.

Two details matter for anyone modifying this flow. The insert and the totals update are separate statements rather than one transaction, so an interruption between them would leave the aggregate out of step with the rows. And the percentages shown in the dashboard are derived from those incremented totals, not computed on the fly from the attendance table.

A relational schema built around registrations

The database design is described as modelling real-world university relationships: departments house courses, teachers teach registered courses, students register for courses, and attendance is logged against daily classes with optional references to leave applications. The README carries both a rendered entity relationship diagram and a hand-drawn one, plus a separate database project report written by Beenish Tasaffar.

The schema ships as a SQL dump named attendance_portal_beenishtasaffar.sql at the repository root, next to a database/ directory and a test_db.php file. That dump is the practical entry point for a new installation, and it also tells you something about the state of the project: the schema travels as a file rather than as versioned migrations, so there is no recorded path from an older database shape to the current one.

The leave side of the model is visible in the request lifecycle rather than described in a section of its own. Pending leave applications arrive alongside the student list, which implies the application is checked when attendance is fetched, and the portal files leaveRequests.php, requestsHistory.php and attendanceReport.php alongside the main pages.

The interface and the three front-end directories

The browser side is described as vanilla JavaScript and CSS3, with ag-Grid doing the heavy lifting for the tables. That choice keeps the client dependency-free in the build sense, at the cost of hand-written rendering around the grid: the sidebar, the statistics cards and the leave status panels are all custom work layered on top of the grid rather than components from a framework.

The repository listing is where the project's shape gets interesting. Alongside the classic PHP pages, index.php, login.php, logout.php, dashboard.php, portal.php, sidebar.php, register.php, attendanceReport.php, leaveRequests.php and requestsHistory.php, there are three directories named php-app/, react-app/ and react-server/, plus assets/, css/, images/, docs/ and a .vscode/ directory. The README does not explain what those three directories hold, so a reader cannot tell from the repository whether they are a rewrite in progress, an experiment, or archived variants of the same interface.

That ambiguity is the practical caveat for anyone picking this up. The described system is the PHP and ag-Grid one, and the presence of React directories alongside it means the tree is wider than the documentation.

Limits: no releases, no migration path and a wide tree

Three constraints deserve a decision before you build on Attendify. First, the repository publishes no GitHub releases, and the last push was on 2026-07-04, so there is no version to pin and no changelog to read. Second, the schema is a dump file rather than a migration series, which means a database you created months ago has no documented route to the current shape. Third, the request routing is convention-based, with action names and payload keys spread between api.php and the JavaScript that calls them.

The alternative approach is worth naming, because it is a design decision rather than a defect. A PHP framework approach would give you routing with declared routes, an ORM or query builder, migrations that version the schema, and a templating layer for the pages, all of which this project deliberately does without. In exchange, Attendify has no composer dependencies, no build step and a request you can trace by reading two files.

For a lab or a small department where one person owns the database and the interface, that trade is reasonable. For a product with more than one maintainer, the missing migrations and the undocumented React directories are where the cost lands.

Editorial conclusion

Attendify suits a small department or a student project that wants attendance marking and leave approval in one interface and is content to run it on a local Apache and PHP environment with a MySQL server on port 3316. It is a poor fit for a product team that needs versioned releases, an authentication model with documented roles, or a schema migration story, because the repository publishes no releases and its last push was on 2026-07-04. Before deploying, verify that api.php accepts the action names the interface sends, that db_connect.php points at your own MySQL instance, and that the SQL dump attendance_portal_beenishtasaffar.sql matches the schema your instance already has.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/Attendify on GitHub
2. Issues
3. License: MIT
4. README