TravelEase is a full-stack travel booking, itinerary, and support platform built around curated England-focused travel experiences.
The application separates its workflows across three user roles:
- Traveler — discover trips, make bookings, complete demonstration payments, manage itineraries, receive notifications, and contact support.
- Agent — create and manage travel offers and assist with traveler support.
- Administrator — monitor users, bookings, payment records, and support activity.
The project combines PHP, MySQL, PDO, Bootstrap, JavaScript, PHPMailer, session-based authentication, role authorization, transactional database operations, and responsive interfaces in a traditional server-rendered web architecture.
flowchart LR
A["Discover Trips"] --> B["View Journey"]
B --> C["Create Booking"]
C --> D["Mock Payment"]
D --> E["Booking Confirmed"]
E --> F["Plan Itinerary"]
F --> G["Notifications"]
G --> H["Support"]
I["Travel Agent"] --> A
I --> H
J["Administrator"] --> C
J --> D
J --> H
TravelEase retrieves active travel packages from MySQL and presents them as responsive destination cards.
Each trip can include:
- Title
- Destination
- Category
- Description
- Duration
- Price
- Available seats
- Availability status
The trip-detail experience also adapts its visual treatment to destinations such as:
London · Cotswolds · Lake District · Bath · York · Cornwall
Authenticated travelers can create bookings for active trips.
The backend validates:
- Trip existence
- Trip status
- Traveler count
- Available seats
- Travel date
- Booking ownership
The total booking amount is calculated on the server using the stored trip price.
Selected Trip
↓
Travel Date + Traveler Count
↓
Server Validation
↓
Pending Booking
↓
Payment Step
TravelEase includes a project demonstration payment workflow.
No real money is charged. This is not connected to a production payment gateway.
Supported demonstration methods include:
- Credit Card
- Debit Card
- Bank Transfer
- Digital Wallet
After successful validation, the backend:
Validates booking ownership
↓
Checks existing payment
↓
Creates transaction reference
↓
Begins database transaction
↓
Stores payment status
↓
Confirms booking
↓
Creates notification
↓
Commits transaction
↓
Sends confirmation email
Transaction references are generated using cryptographically secure random bytes.
Confirmed bookings unlock an itinerary-planning workspace.
Travelers can organize trip information around:
- Itinerary title
- General notes
- Day number
- Activity title
- Location
- Activity time
- Activity notes
Itinerary access is scoped to the authenticated traveler and their own booking.
Travelers can submit support tickets containing:
- Subject
- Priority
- Message
Priorities include:
Low · Medium · High
Travelers can then review:
- Ticket status
- Staff response
- Creation time
- Latest update
Agents and administrators have dedicated support-management areas for reviewing and updating traveler issues.
The application supports both database-backed notifications and SMTP email communication.
Email workflows include:
- Traveler registration confirmation
- New traveler notification for administrators
- Password reset
- Booking confirmation
- Booking cancellation
- Relevant staff notifications
PHPMailer handles SMTP delivery with STARTTLS support.
Explore Trips
│
├── View Trip Details
├── Create Booking
├── Complete Mock Payment
├── Review My Bookings
├── Cancel Booking
├── Build Itinerary
├── View Notifications
└── Submit Support Tickets
The Traveler dashboard brings booking, payment, planning, support, and notification workflows together in one area.
Agent Dashboard
│
├── View Trip Statistics
├── View Trips
├── Add Travel Offers
├── Manage Created Trips
├── Review Bookings on Own Trips
└── Manage Support Tickets
Agent dashboards display information such as:
- Total trips
- Agent-created trips
- Bookings associated with the agent's trips
Admin Dashboard
│
├── Monitor Total Users
├── Monitor Total Trips
├── Monitor Total Bookings
├── Monitor Paid Payments
├── View Registered Users
├── Review Booking Records
└── Manage Support Tickets
The booking overview combines traveler, trip, payment, amount, booking status, and transaction-reference information.
TravelEase uses PHP sessions and server-side role checks.
flowchart TD
A["Login Form"] --> B["Find User by Username / Email / Phone"]
B --> C{"Password Valid?"}
C -- No --> D["Generic Login Error"]
C -- Yes --> E{"Account Active?"}
E -- No --> F["Reject Login"]
E -- Yes --> G["Regenerate Session ID"]
G --> H["Store Authenticated Session"]
H --> I{"User Role"}
I --> J["Traveler Dashboard"]
I --> K["Agent Dashboard"]
I --> L["Admin Dashboard"]
A user may sign in with:
- Username
- Email address
- Full phone number
Passwords are stored using PHP's native:
password_hash($password, PASSWORD_DEFAULT);and verified using:
password_verify($password, $storedHash);After a successful login:
session_regenerate_id(true);is called before authenticated user data is stored in the session.
Protected pages call role guards such as:
requireRole(['traveler']);requireRole(['agent']);requireRole(['admin']);Unauthorized users are redirected rather than relying only on hidden navigation links.
TravelEase includes an email-based password-reset workflow.
flowchart LR
A["Reset Request"] --> B["Find User"]
B --> C["Generate Random Token"]
C --> D["Store SHA-256 Token Hash"]
D --> E["Set 1-Hour Expiration"]
E --> F["Email Reset Link"]
F --> G["Validate Token"]
G --> H["Update Password Hash"]
H --> I["Mark Token Used"]
The implementation uses:
bin2hex(random_bytes(32))for token generation.
Only the SHA-256 hash of the token is stored in the database.
Reset links expire after one hour, and used reset records cannot be reused.
TravelEase follows a traditional server-rendered PHP structure with reusable configuration, authentication, layout, and mail modules.
flowchart TB
Browser["Browser"]
subgraph Public["Public Area"]
Home["Homepage"]
Trips["Trip Catalogue"]
Details["Trip Details"]
AuthUI["Login / Registration"]
end
subgraph Roles["Protected Role Areas"]
Traveler["Traveler"]
Agent["Agent"]
Admin["Admin"]
end
subgraph Services["Application Services"]
Auth["Auth / Role Guards"]
Mail["PHPMailer"]
Session["Sessions / Flash Messages"]
end
subgraph Data["Data Layer"]
PDO["PDO"]
DB[("MySQL")]
end
Browser --> Public
Browser --> Roles
Public --> Auth
Roles --> Auth
Public --> PDO
Roles --> PDO
Auth --> Session
Roles --> Mail
PDO --> DB
The codebase works with several related application areas.
USERS & ACCESS
├── users
├── roles
└── password_resets
TRAVEL
├── trips
└── bookings
PAYMENT
└── payments
PLANNING
├── itineraries
└── itinerary_items
COMMUNICATION
├── notifications
└── support_tickets
TRIP AVAILABLE
│
▼
BOOKING CREATED
│
▼
PENDING
│
├──────────────► CANCELLED
│
▼
MOCK PAYMENT COMPLETED
│
▼
CONFIRMED
│
▼
ITINERARY AVAILABLE
Database access uses PDO with exception mode and prepared statements.
Example pattern:
$stmt = $pdo->prepare("
SELECT *
FROM bookings
WHERE booking_id = :booking_id
AND user_id = :user_id
");
$stmt->execute([
'booking_id' => $bookingId,
'user_id' => $userId
]);This also allows ownership constraints to be included directly in queries for traveler-specific data.
The demonstration-payment flow uses a database transaction because several records must change together.
BEGIN TRANSACTION
│
├── Create / Update Payment
├── Confirm Booking
└── Create Notification
│
▼
COMMIT
If processing fails after the transaction begins, the transaction is rolled back.
SMTP settings are loaded from either:
config/secrets.php
or server environment variables.
Supported variables include:
MAIL_FROM_ADDRESS=
MAIL_FROM_NAME=TravelEase
MAIL_SMTP_HOST=smtp.gmail.com
MAIL_SMTP_PORT=587
MAIL_SMTP_USERNAME=
MAIL_SMTP_PASSWORD=Keep SMTP passwords out of version control.
For Gmail SMTP, use an appropriate application-specific credential rather than exposing an account password.
Database configuration can also come from an untracked secrets file or environment variables.
DB_HOST=localhost
DB_PORT=3306
DB_NAME=travelease_db
DB_USER=root
DB_PASS=The PDO connection uses:
utf8mb4
for the database character set.
travelease-webApp/
│
├── admin/
│ ├── dashboard.php
│ ├── manage-bookings.php
│ ├── manage-support.php
│ ├── manage-users.php
│ └── update-ticket.php
│
├── agent/
│ ├── dashboard.php
│ ├── add-trip.php
│ ├── manage-trips.php
│ ├── manage-support.php
│ ├── save-trip.php
│ └── update-ticket.php
│
├── traveler/
│ ├── dashboard.php
│ ├── book-trip.php
│ ├── create-booking.php
│ ├── my-bookings.php
│ ├── cancel-booking.php
│ ├── payment.php
│ ├── process-payment.php
│ ├── itinerary.php
│ ├── save-itinerary.php
│ ├── add-itinerary-item.php
│ ├── notifications.php
│ ├── support.php
│ └── save-ticket.php
│
├── auth/
│ ├── login-handler.php
│ ├── register-handler.php
│ ├── forgot-password-handler.php
│ └── reset-password-handler.php
│
├── config/
│ ├── config.php
│ ├── db.php
│ └── mail.php
│
├── includes/
│ ├── auth.php
│ ├── mailer.php
│ ├── header.php
│ ├── navbar.php
│ └── footer.php
│
├── lib/
│ └── PHPMailer/
│
├── assets/
│ ├── css/
│ ├── images/
│ └── js/
│
├── index.php
├── trips.php
├── trip-details.php
├── login.php
├── register.php
├── forgot-password.php
├── reset-password.php
├── contact.php
├── about.php
│
├── Dockerfile
├── SETUP_GUIDE.md
└── README.md
For the existing local-development workflow:
- XAMPP
- Apache
- MySQL
- PHP
- phpMyAdmin
git clone https://github.com/abarman079/travelease-webApp.gitFor the current BASE_URL configuration, place or rename the project directory as:
C:\xampp\htdocs\travelease
Open XAMPP and start:
Apache
MySQL
Open:
http://localhost/phpmyadmin
Create:
travelease_db
Then import the TravelEase database schema/data dump used by your local copy of the project.
The repository's setup documentation expects the TravelEase SQL schema to be imported before the application is started.
Default local values are:
Host: localhost
Port: 3306
Database: travelease_db
Username: root
Password: empty
You can also configure these through environment variables.
http://localhost/travelease/
The repository also includes a PHP/Apache Docker image.
The Dockerfile uses:
PHP 8.3 + Apache
PDO
PDO MySQL
mod_rewrite
Build the web image with:
docker build -t travelease .Run it with an environment that provides access to an appropriate MySQL database.
The current repository contains the application Dockerfile; MySQL orchestration should be configured separately for a complete containerized environment.
TravelEase includes several useful backend practices.
password_hash()
password_verify()
Session IDs are regenerated after successful authentication.
Protected route access is checked server-side.
User-specific and write operations use PDO prepared statements.
Reset tokens are:
- Randomly generated
- Hashed before database storage
- Time limited
- Marked as used after reset
Database exceptions are not directly printed to public users in normal application workflows.
Database and SMTP credentials can be read from server environment variables rather than being embedded directly in application code.
TravelEase does not process real financial transactions.
The payment page exists to demonstrate:
- Payment-form workflow
- Validation
- Booking/payment relationships
- Transaction references
- Transactional database updates
- Payment status
- Booking confirmation
- Notification generation
- Confirmation email workflow
Real card data should never be submitted to this demonstration implementation.
A production version should use a PCI-compliant payment provider such as Stripe, PayPal, Adyen, or another appropriate gateway rather than processing card details directly.
- Public homepage
- Trip catalogue
- Trip-detail pages
- Traveler registration
- Login using username/email/phone
- Session-based authentication
- Traveler / Agent / Admin authorization
- Password reset
- SMTP email support
- Traveler booking creation
- Demonstration payment workflow
- Booking confirmation
- Booking cancellation
- Notifications
- Itinerary planning
- Support tickets
- Agent trip creation/management
- Agent support management
- Admin user overview
- Admin booking/payment overview
- Admin support management
- Responsive Bootstrap-based UI
- PDO/MySQL data layer
- PHP/Apache Docker image
- Search and filter trips
- Richer trip imagery
- Destination weather integration
- More itinerary tools
- Agent-specific booking operations
- Improved notification controls
- CSRF protection for state-changing forms
- Automated PHP tests
- Static analysis
- GitHub Actions CI
- Complete Docker Compose environment
- Environment template
- Database migrations
- Centralized validation helpers
- Structured application logging
- Integrate a real payment provider
- Stronger session-cookie configuration
- Rate limiting
- Production mail provider
- Deployment documentation
- Monitoring and error reporting
TravelEase uses a soft editorial travel aesthetic rather than a generic administrative template.
The UI combines:
Warm neutral surfaces
Deep navy typography
Muted blue-green accents
Soft gold travel accents
Rounded content panels
Responsive Bootstrap layouts
Destination-led imagery
Role-specific dashboards
The public side emphasizes the travel experience, while authenticated areas prioritize clarity around bookings, payments, planning, and support.
TravelEase connects several workflows that are often built separately in smaller student projects:
Authentication
+
Role Authorization
+
Trip Management
+
Booking Logic
+
Payment State
+
Database Transactions
+
Email Communication
+
Notifications
+
Itinerary Planning
+
Support Operations
That makes the project useful as an example of a multi-role, database-backed business application, rather than only a collection of isolated PHP pages.
