satishsurani/mybus-bus-booking-site

1. Purpose and Runtime

A server-rendered PHP/MySQL bus-ticket booking system. Browser pages use JavaScript/AJAX for dynamic operations; PHP endpoints own authentication, inventory/booking mutations, and payment handling. It is intended for an Apache/PHP local stack such as XAMPP/WAMP, with schema/bootstrap data in mybus.sql.

2. Public Application Entry Points

The customer-facing flow begins at index.php, with bus discovery/detail interaction through bus.php and ajax/bus.php. Account and trip history are exposed through bookings.php; logout is handled by logout.php. Shared page chrome and likely session-aware navigation are centralized in inc/header.php, inc/footer.php, and inc/links.php.

3. Authentication Boundary

Customer login and registration are API-style PHP mutations in ajax/login.php and ajax/register.php. These endpoints form the identity boundary for booking operations; authenticated user state is then consumed by customer pages such as bookings.php and booking confirmation paths. Administrative authentication is separately entered through admin/index.php and terminated by admin/logout.php.

4. Search, Availability, and Seat Selection

Bus search/filtering and real-time availability are driven by the public bus endpoint ajax/bus.php, rendered in the customer bus UI at bus.php. The system’s key inventory boundary is the booking action: a selected seat must transition from available to reserved without conflicting with concurrent requests. The schema in mybus.sql is the authoritative persistence model for buses, routes/schedules, users, and bookings.

5. Booking and Payment Lifecycle

Booking confirmation is coordinated by confirm_booking.php and client logic in scripts/confirm_booking.js. State-changing operations are split into endpoints: ajax/confirm_booking.php confirms a reservation, ajax/cancel_booking.php cancels it, and ajax/submitpayment.php records/submits payment processing. User-visible terminal states are represented by payment-success.php and payment-failed.php. Razorpay is the stated external payment gateway; payment callbacks/result handling should be treated as a trust boundary rather than relying on browser-provided success state.

6. Administration Plane

The admin site is a distinct PHP surface rooted at admin/index.php, with operational screens in admin/dashboard.php, admin/bus.php, and admin/bookings.php. Admin AJAX endpoints—admin/ajax/dashboard.php, admin/ajax/bus.php, and admin/ajax/bookings.php—support management/reporting without full page reloads. Shared admin database and authorization foundations are concentrated in admin/inc/db_config.php and admin/inc/essentials.php.

7. Reporting and External Integrations

Booking output can be generated as a PDF through generate_pdf.php, with bookings_report.pdf indicating a report artifact/output. Dependency management is present via composer.json and composer.lock, likely supporting PHP integrations such as PHPMailer. Email confirmations are expected to use PHPMailer/SMTP, creating a separate outbound delivery boundary after successful booking/payment persistence.