mahfujul-01726/tourandtraveltouch

1. Overall shape: This is a small monolithic travel-booking application built with PHP 8+, MySQL/MariaDB, vanilla JavaScript, and Bootstrap 5. The browser serves a mostly static frontend, while PHP scripts in backend/ act as request handlers for auth, booking, search, and admin functions.

2. Frontend shell: index.html is the main public landing page. pages/login.html and pages/signup.html are separate auth screens. The UI is styled and themed through assets/css/theme-orange.css and assets/css/theme-red.css, with images and branding assets under assets/images/.

3. Client-side behavior: assets/js/config.js is the main browser-side integration point; it points frontend calls to the backend base URL. JavaScript also drives the interactive presentation layer described in the README: theme switching, animations, parallax, particles, scroll reveal, and flash/toast display.

4. Backend configuration boundary: backend/config/app.php and backend/config/database.php centralize environment settings and database connectivity. app.php governs session and frontend-origin related behavior, while database.php establishes the MySQL connection used by all handlers.

5. Shared backend utilities: backend/helpers.php provides cross-cutting server-side utilities used across handlers and admin pages. This is where common concerns like sanitization, token/session helpers, or response formatting are likely consolidated.

6. Request handlers: backend/handlers/ is the application’s functional API layer. Each file is a focused endpoint:

- register.php, login.php, logout.php handle user authentication

- auth-status.php reports whether a session is authenticated

- csrf-token.php issues CSRF tokens to the client

- booking.php persists travel bookings

- search.php performs booking/destination searches

- flash.php exposes session-backed status messages

7. Data model and persistence: database/schema.sql defines the core relational schema. The main entities are users, information (booking records), and admins. The information table links bookings back to users, so the primary data flow is user account creation → authenticated session → booking insertion → later admin review.

8. Admin subsystem: backend/admin/login.php, logout.php, and dashboard.php form a separate admin realm from the public user flow. The admin panel is not just another page; it is a distinct authenticated boundary for reviewing and managing booking/user data.

9. Security and trust boundaries: The repository emphasizes server-side protection at every state-changing boundary. Public forms submit to PHP handlers protected by CSRF tokens, credentials are stored with bcrypt, database access uses prepared statements, and output is sanitized to reduce XSS risk. Session-based auth is the main trust mechanism between browser and backend.

10. Operational/deployment flow: .github/workflows/deploy.yml automates deployment by pushing the repository contents to an InfinityFree host over FTP on every push to main. That means the architecture has a simple CI/CD path: GitHub repository → Actions runner → FTP upload → shared hosting runtime.

11. Runtime profile: The app is deployed as a classic PHP site rather than a containerized service or SPA. The browser talks directly to PHP endpoints over HTTP, and PHP talks directly to MySQL. There is no separate application server layer, queue, or external API dependency visible in the repository.

12. What to draw in a diagram: The important diagram boundaries are: browser/frontend assets, PHP backend handlers/config, admin area, MySQL database, and FTP-based deployment pipeline. The main data flow is user interaction in the browser → PHP request handlers → MySQL → response/flash/session back to the browser.