How ekeshwar247/evento- works
1. Overall shape
This is a classic PHP/MySQL monolith for event operations. The codebase is split into a public-facing visitor site and a protected admin/staff portal, both backed by the same MySQL database and sharing some common layout/assets.
2. Runtime and persistence
The application runs on a local PHP web server stack such as XAMPP. The schema and seed data live in database/event_db.sql, which is the central persistence boundary for events, venues, users, registrations, and booking inquiries.
3. Public visitor subsystem
The root-level pages (index.php, home.php, venue.php, about.php, view_event.php, view_art.php, registration.php, booking.php) form the visitor-facing side. This area exposes upcoming events, venue listings, about content, event detail pages, audience registration, and venue booking inquiries.
4. Admin/staff subsystem
Everything under admin/ is the management portal. Key screens include events.php, venue.php, booking.php, audience.php, users.php, site_settings.php, plus reporting pages like audience_report.php and venue_report.php. These pages are used to create, edit, review, and publish operational data.
5. Authentication and access boundary
admin/login.php and the related admin session flow define the security boundary between public access and management access. The readme indicates multiple admin/staff accounts, so the portal supports role-based operational access even if the roles are implemented simply.
6. Core domain entities
The architecture centers on a few primary records: events, venues, users/admins, audience registrations, and venue booking requests. The reports reinforce these relationships: audience is grouped by event, and venue usage is grouped by venue and month.
7. Business logic layer
admin/admin_class.php appears to be the main server-side service layer for CRUD and workflow operations. It likely encapsulates database operations for events, venues, users, registrations, bookings, settings, and report generation, while admin/ajax.php handles asynchronous admin actions.
8. Shared presentation layer
The repository uses shared PHP includes like head.php, header.php, and footer.php for the public site, and admin/header.php, admin/navbar.php, and admin/topbar.php for the back office. This indicates a templated page composition model rather than a framework with a formal MVC structure.
9. Media and file storage
Uploaded images are stored on disk under admin/assets/uploads/, separated by entity type such as event_* and venue_*. That means the system has two stateful stores: the database for metadata and the filesystem for banners/photos/documents.
10. Client-side behavior
The UI depends on bundled static libraries in admin/assets/, especially DataTables for searchable/sortable admin lists and Font Awesome for icons. The root js/scripts.js and admin JS assets likely provide form interactions, table behavior, and AJAX-driven updates.
11. Operational flow
The main data flow is: staff/admin enters or edits venues and events in the admin portal, the public site reads and displays approved/published content, visitors submit registrations or booking inquiries, and staff then reviews those submissions in the admin queues. Reports are derived from the same stored records for printing and operational review.
12. Architectural boundary summary
In diagram terms, the important boundaries are: public visitor UI, authenticated admin UI, shared PHP include/layout layer, PHP business logic layer, MySQL database, and filesystem-based uploads. There are no signs of external APIs or background workers; the system is self-contained around server-rendered pages and database-backed CRUD.
Main entry points: admin/header.php Admin layout · admin_class.php Admin logic · event_db.sql MySQL schema · header.php Shared layout
Components 21
Public site
Visitor-facing pages and shared presentation for event discovery and submissions
- Landing · Entry point for the visitor site
index.php - Home · Main public listing and navigation page
home.php - Venues · Public venue browsing page
venue.php - Event detail · Public event and art detail views
view_event.php - Registration · Audience sign-up flow
registration.php - Booking · Venue booking inquiry flow
booking.php - Shared layout · Common public header, head, and footer composition
header.php
Admin portal
Authenticated management screens and back-office workflows
- Admin login · Authentication boundary for staff access
admin/login.php - Dashboard · Back-office landing and summary screen
admin/home.php - Events · Create, edit, and publish events
admin/events.php - Venues · Manage venue records and details
admin/venue.php - Bookings · Review and manage booking requests
admin/booking.php - Audience · Review registrations and attendance records
admin/audience.php - Users · Manage staff and admin accounts
admin/users.php - Reports · Audience and venue reporting views
admin/audience_report.php - Settings · Site configuration and operational settings
admin/site_settings.php - Admin logic · Shared CRUD, workflow, and AJAX handling for the portal
admin/admin_class.php - Admin layout · Common admin header, navbar, and topbar composition
admin/header.php
State
Database and filesystem storage used by the application
- MySQL schema · Central persistence for events, venues, users, registrations, bookings, and settings
database/event_db.sql - Uploads · Stored event and venue media on disk
admin/assets/uploads
Assets
Static client-side libraries and UI resources
- UI assets · Client-side libraries, styles, and scripts such as DataTables, Font Awesome, and site JS
js/scripts.js
Connections 35
- Landing → Shared layout: uses · Composes shared public chrome
- Home → Shared layout: uses · Uses shared site layout
- Venues → Shared layout: uses · Uses shared site layout
- Event detail → Shared layout: uses · Uses shared site layout
- Registration → Shared layout: uses · Uses shared site layout
- Booking → Shared layout: uses · Uses shared site layout
- Admin login → Admin layout: uses · Uses admin chrome after auth
- Dashboard → Admin layout: uses · Uses admin chrome
- Events → Admin layout: uses · Uses admin chrome
- Venues → Admin layout: uses · Uses admin chrome
- Bookings → Admin layout: uses · Uses admin chrome
- Audience → Admin layout: uses · Uses admin chrome
- Users → Admin layout: uses · Uses admin chrome
- Reports → Admin layout: uses · Uses admin chrome
- Settings → Admin layout: uses · Uses admin chrome
- Dashboard → Admin logic: calls · Dashboard reads operational data through shared service layer
- Events → Admin logic: calls · Event CRUD goes through shared business logic
- Venues → Admin logic: calls · Venue CRUD goes through shared business logic
- Bookings → Admin logic: calls · Booking workflows go through shared business logic
- Audience → Admin logic: calls · Registration workflows go through shared business logic
- Users → Admin logic: calls · User management goes through shared business logic
- Reports → Admin logic: calls · Reports are assembled from shared data access
- Settings → Admin logic: calls · Settings are read and updated through shared logic
- Admin login → MySQL schema: auth · Validates credentials against persisted user records
- Shared layout → UI assets: loads · Loads shared CSS and JavaScript
- Admin layout → UI assets: loads · Loads admin CSS, DataTables, icons, and scripts
- Admin logic → MySQL schema: reads/writes · Central database access for CRUD and reports
- Events → Uploads: stores media · Event images are uploaded to disk
- Venues → Uploads: stores media · Venue images are uploaded to disk
- Home → MySQL schema: reads · Public content is rendered from database records
- Venues → MySQL schema: reads · Venue listings are read from the database
- Event detail → MySQL schema: reads · Event detail pages are read from the database
- Registration → MySQL schema: writes · Visitor registrations are stored in the database
- Booking → MySQL schema: writes · Booking inquiries are stored in the database
- Reports → MySQL schema: reads · Report pages aggregate persisted operational data