Guest Views

Developer

A “guest” is any visitor who has not yet logged in. This view context covers the public booking journey: it begins at the homepage (index.blade.php) and continues through the three step guest checkout flow under resources/views/front_end/one_time_order/, driven end to end by GuestOrderController. The whole sequence was redesigned as part of this engagement.

That flow needed something the application’s data model didn’t originally support: a way to place an order without a logged in user. How that was made possible, through a reserved “ghost” user record, is documented in Architecture & Codebase. This page focuses on the views themselves.

The Homepage Is Shared

index.blade.php is the same file for every visitor, logged in or not. Most of the page is identical either way: the hero section, the wash plan cards, the before and after gallery, and the testimonial carousel. A small number of sections are conditional, and a single “Book Now” action branches by auth state:

function startOrder(planName) {
    @auth
        window.location.href = "/order/step1?plan=" + encodeURIComponent(planName);
    @endauth
    @guest
        window.location.href = "/guest/step1?plan=" + encodeURIComponent(planName);
    @endguest
}

The “Make an account to enjoy the following perks” section and the four step “Book a Car Wash” walkthrough (which assumes the visitor doesn’t have the app yet) are aimed at guests; a logged in visitor still sees the same homepage shell, but these sections are less relevant to them and the booking action above sends them down the registered user flow instead. The homepage itself is documented as a single view; what differs by auth state is covered here and in Logged-in Views rather than duplicated across both pages.

The Checkout Flow Is Shared, Not Duplicated

The three step flow under front_end/one_time_order/ is not guest exclusive. Each step is a single Blade template used by both guests and logged in users, with Auth::check() controlling which sections render:

File	Step	What changes for logged in users
car_model.blade.php	1. Vehicle details	The step indicator (<steps-display>) is hidden; everything else is the same form
location_time.blade.php	2. Location and time	A saved vehicle dropdown (Auth::user()->vehicles) replaces nothing, since vehicle entry happens in step 1; the booking info card and an “Add New Vehicle” modal are shown only when logged in
checkout.blade.php	3. Payment	The entire name, email, phone, and OTP column is skipped. A logged in user’s email is already known (Auth::user()->email), so the layout collapses to a single column (guest-checkout-columns--solo)

GuestOrderController serves these views for unauthenticated visitors; the equivalent controller for logged in users is UserOrderController. Both controllers ultimately render some of the same Blade files, which is why the auth check lives inside the templates rather than in two separate copies of each view.

One unrelated file worth noting: front_end/checkout.blade.php (directly under front_end/, not under one_time_order/) is a leftover from an older, generic cart based checkout flow and is not part of this sequence. It belongs with the dead code noted in Architecture & Codebase rather than with the guest flow.

Step 3 in Detail: Checkout

The checkout step is the most involved of the three. For guests specifically, it collects name, email, and phone, then verifies the phone number through Firebase phone authentication (an invisible reCAPTCHA plus an SMS code) before payment is allowed to proceed. A promo-code component lets the guest apply a coupon, which is validated and applied through ValidateCouponService and ApplyCouponService respectively, both described in Architecture & Codebase. An “Engine wash” add-on toggle re-fetches the Stripe checkout session whenever it’s switched, since the total has changed.

Payment itself uses Stripe’s Elements based checkout (stripe.initCheckout), mounted into the page once a checkout session has been created server side. As noted in Architecture & Codebase, the OTP verification has a fixed local-only bypass code for development, which does not exist in the production environment.

Components Used in This Flow

This was also the first part of the codebase to use a reusable component system. V&B introduced both the project’s only Blade component library and its only custom web components, and both are used throughout this flow before being reused again in the logged-in views.

The Blade components live under resources/views/components/:

• card/: wash-card-template.blade.php, service-card.blade.php, testimonial-card.blade.php
• images/: image-with-fallback.blade.php
• ui/: promo-code.blade.php, services-carousel.blade.php, testimonial-carousel.blade.php
• vehicle-form.blade.php

The custom web components live under public/js/, and are used for small, self-contained icons and decorative elements rather than full UI sections:

aedIcon.js, goLeft.js, goRight.js, handWashIcon.js, mapLoader.js, shinyCarIcon.js, stepsProgressBar.js, videoPlayer.js, whatsappFloaty.js

A related helper module, public/js/helpers/applyCouponHelper.js, drives the promo code AJAX interaction used on the checkout step.

No other part of the codebase, before or alongside this engagement, uses a Blade component system or custom web components. Both patterns remain specific to the views documented on this page and on Logged-in Views.