CodeCanyon BRW - WordPress Plugin

How to Set Up CodeCanyon BRW for Rentals and Bookings in WooCommerce

CodeCanyon BRW is best treated not as a simple add-on for a product page, but as a separate booking system running inside WooCommerce. After installation, you need to decide which rental model you will use, how pricing should be calculated, where availability should be stored, what the customer should see in the form, and how orders will be managed in the admin area.

This guide walks through the practical setup path: preparing the site, installation, global settings, creating a rental product, calendar setup, inventory, deposits, extra services, search forms, a test booking, and troubleshooting. It is written for a site owner, store administrator, or developer who already understands the basics of WordPress and WooCommerce but wants to build a reliable rental workflow without unnecessary risk.

This plugin is especially sensitive to small decisions: how a daily rental differs from a nightly stay, how to charge for an extra hour, when to enable manual inventory for specific vehicles, why order status affects the calendar, and how to avoid opening the same date to multiple customers. So what follows is not a sales-style feature recap, but a step-by-step setup guide with result checks along the way.

Where the Plugin Is Useful and What Problem It Solves

BRW adds a booking and rental layer to WooCommerce. In a standard store, a product is sold as a unit with a price and stock quantity. Rentals need more than that: the customer chooses a date range, time, pickup location, return location, service options, guest count, or even a specific item. The system then needs to calculate the price, show availability, create the order, prevent time overlaps, and give the administrator a practical way to manage bookings.

The product's strong point is that it supports multiple business models inside a single plugin. According to the product page and documentation, BRW supports daily rentals, hourly rentals, mixed models, hotel bookings, tours, transportation, taxi logic, and time-slot appointments. That matters because a car rental site and a tour booking site are not separated by form design, but by how pricing and availability are calculated.

For car rentals, what matters is pickup and return dates, pickup location, return location, inventory, and sometimes a specific vehicle ID. For hotels, the key factors are nights, guest count, and occupied dates. For tours, the important parts are guest types, schedules, and capacity. For taxi or transfer services, route, distance, base fare, and maps come into play. If you try to handle all of that with regular WooCommerce variations, you will quickly end up with confusing stock rules, orders, and emails.

BRW is a good fit when bookings need to go through the WooCommerce cart and checkout flow. That gives you familiar payment gateways, coupons, taxes, emails, order statuses, and customer accounts. But that integration also brings responsibility: every rental setting needs to be tested not only on the product page, but also in the cart, the order, the email, and the calendar.

Typical Use Cases

• Car, motorcycle, bicycle, equipment, or tool rentals where the rental period and available quantity must be tracked.
• Bookings for rooms, villas, apartments, and similar properties where the price is calculated per night and check-in/check-out dates matter.
• Tours and event sales where pricing may depend on guest type, schedule, duration, and group capacity.
• Taxi, transfer, and route-based services where pricing depends on distance, a fixed route, and pickup/drop-off points.
• Service bookings by time slot when you need to manage available times and send reminders to customers.

The key check before rollout: write out one real booking flow on paper, from date selection to closing the reservation. If you cannot clearly define pricing, availability, payment, and cancellation rules without the plugin, those settings will be random in the admin area too.

Who BRW Fits and When Another Tool May Be Better

The plugin is a strong choice for a site where rentals are tightly connected to WooCommerce. If you already have a store, payment methods, coupons, tax rules, emails, and customer accounts, BRW lets you avoid building a separate order system. The booking becomes part of the normal WooCommerce order flow, and the administrator manages it from WordPress.

BRW is also useful for projects where different service types live in the same catalog: a daily car rental, a scheduled tour, a route-based transfer, and paid add-ons. In those cases, a simple standalone calendar usually breaks down quickly: it can show open dates, but it cannot properly calculate pricing or connect the booking to the product, payment, stock, and email flow.

The plugin may be more than you need if you only want a simple inquiry form without online pricing and without WooCommerce checkout. For example, a small service business that manually confirms every appointment by phone is often easier to run with a form, a calendar, and a CRM. BRW gives you more control, but it also requires more setup and testing.

Another case that calls for caution is very complex logistics involving external systems, two-way integrations, multiple inventory locations, or a custom mobile app. The documentation includes iCal and Google Calendar scenarios, but any business-critical sync should be validated in a staging environment. Do not treat automatic integration with an external channel as a guaranteed business process until you have seen exactly how it behaves on your site.

User Roles

Most projects involve three roles. The business owner defines the rules: how much the rental costs, when the item is available, whether a deposit is required, and which services cost extra. The site administrator translates those rules into products and monitors the calendar. The developer or technical specialist is responsible for the theme, templates, cache, emails, translations, and safe customizations.

If all three roles are handled by one person, do not try to configure everything in one evening. Build one test product first and go through the full booking flow. Then add search, extra services, manual inventory, reminders, and sync.

What to Check Before Installing It on a Live Site

Preparation is not just a formality. The plugin changes the product page, adds its own settings, interacts with the cart and checkout, and uses calendar data. A mistake at this level can lead not just to an ugly form, but to incorrect pricing or double bookings.

Environment Check

First, make sure the site is running a current combination of WordPress, WooCommerce, and PHP that matches the product requirements. Do not treat specific version numbers as permanent rules in an article because they change. In practice, what matters is opening the product page and documentation, confirming the requirements there, and then checking your server and plugins in the admin area.

• WooCommerce must be installed and active before BRW is enabled.
• The site must already have a working cart and checkout process.
• Payment methods should be tested separately, especially if you plan to use partial payments or a later balance payment.
• Your theme must correctly render product pages, the cart, checkout, and the customer account area.
• Cache and JavaScript optimization must not break the calendar, date selection, AJAX pricing, or search forms.

Staging Environment

The safest rollout path is a site clone or staging subdomain. There you can create several rental products, test different order statuses, enable deposits, change calendar settings, and roll back questionable options without putting customers at risk.

If you do not have a staging environment, at least start with a hidden product or a category visitors cannot see. Publish the product only after you have completed the full path from date selection to a visible booking in the admin area.

Data Worth Preparing in Advance

For a single test scenario, collect a minimal data set: product name, rental type, period, price, date restrictions, available quantity, extra services, pickup and return locations, email text, and cancellation rule. The more precise this information is before installation, the lower the chance that setup turns into random clicking through tabs.

Installation and Initial Verification Without Risking Orders

Installing BRW follows the normal process for a commercial WordPress plugin: inside the product package, find the file ova-brw.zip, upload it through the plugin upload page, and activate it. The documentation also makes it clear that WooCommerce must already be active before installation. That is not a minor detail: BRW relies on WooCommerce product, cart, and order logic.

Setup Steps

1. Open the WordPress admin area and go to Plugins - Add New.
2. Click Upload Plugin and select the ova-brw.zip archive.
3. Install the plugin and activate it through Activate Plugin.
4. Confirm that the BRW section appears in the admin menu and that the Booking & Rental tab appears in WooCommerce settings.
5. Do not start converting your current products into rentals right away. Create a separate test product first.

After activation, open WooCommerce - Settings - Booking & Rental. The documentation describes this area as the place for global settings applied to all products. That means a careless change can affect the entire rental catalog, so start by reviewing the settings rather than enabling every feature at once.

What to Check Immediately After Activation

• A regular WooCommerce product page opens without errors.
• The cart and checkout still work before you create a rental product.
• There are no obvious JavaScript errors in the browser console on the test product page.
• The BRW section opens in the admin area, and the global settings tabs load without blank screens.
• Your caching plugin is not combining calendar scripts in a way that makes the form stop responding to date selection.

Quick takeaway: a successful installation is not just an activated plugin button. The real validation begins when you create a Rental product, select dates on the public page, and see a correct WooCommerce order.

Global Settings After Installation: What to Touch First

BRW global settings live in WooCommerce - Settings - Booking & Rental. The documentation lists tabs for general parameters, archive pages, product detail pages, reCAPTCHA, deposits, guests, search, cancellations, reminders, orders, typography, and colors. You do not need to work through them like a checklist just to say they were reviewed. The right order is this: first enable the settings without which the test product will not work, then convenience features, then protection and automation.

Core Tabs

Start with the general tabs and the product detail page settings. Check which form elements appear on the product page and how dates, time, price, availability, resources, and services are displayed. If the plugin is being installed on an already designed site, resist the urge to start with colors and templates. First make sure pricing and availability work correctly.

The search tab matters if you display a separate rental search form through a shortcode or an Elementor widget. According to the documentation, if a shortcode is used without parameters, it falls back to the global search settings. That makes it important to configure the result template, column count, and field list. Otherwise, the form may show unnecessary filters or ask for data your scenario does not actually need.

Protecting Forms with reCAPTCHA

BRW supports reCAPTCHA for the booking form, the request form, or both. Enable this if your site has a public request form where users can submit information without going straight to checkout. For a normal WooCommerce purchase, protection may already be partly handled elsewhere, but a rental request form often becomes a separate spam entry point.

Before enabling it, create the keys in Google reCAPTCHA, then enter them in WooCommerce - Settings - Booking & Rental - reCAPTCHA. After saving, test the form in a private browser window. If the booking or request submission button stops working, temporarily disable reCAPTCHA and verify the keys, domain, cache, and script optimization settings.

Booking Cancellation and Reminders

If customers should be able to cancel bookings from their account area, configure the Cancellation Policy. The documentation describes limits based on minimum time before cancellation and order amount. This is a business rule, not a technical footnote: a cancellation policy that is too lenient creates empty gaps in the calendar, while one that is too strict increases manual support requests.

Reminders are handled through the Reminder tab: you can enable an automatic email before pickup or check-in and configure repeat sending. For a vehicle or equipment rental business, that is useful because it lets you remind the customer about the time, required documents, address, and return rules. But first verify your core WordPress email delivery. If WooCommerce emails are not being delivered, BRW reminders will not become reliable on their own.

What to Enable Only After Testing

Some features look useful, but are safer to enable only after a successful test order: automatic balance-payment creation, calendar integration, advanced search forms, multiple guest types, separate Elementor templates, and hiding standard product-page elements. Each of these adds a new layer that needs to be checked both on the public site and inside the order flow.

Creating a Rental Product: Rental Type Determines Everything

Product creation starts in the standard Products - Add New area, but after that the important step is selecting Rental in Product data and specifying the rental type. That single choice controls the pricing fields, the calendar, and how BRW calculates the cost. A mistake here often does not show up right away: the form may open normally, but the final amount will be calculated differently from what the business expects.

Do not try to build one universal product that behaves like a car, a hotel room, a tour, and a transfer service at the same time. It is better to create a separate model product for each scenario and test it properly. Once that works, you can scale the structure across the rest of the catalog.

Daily Rentals

For daily rentals, the documentation shows several ways to calculate the period: calendar day, night, and a 24-hour period with rounding for extra time. In practice, this is one of the most important choices. A car rental from Monday to Wednesday and a hotel booking for two nights may sound similar, but they are not priced the same way.

• Calendar day works when each selected date is counted separately, regardless of the exact time.
• Night fits hotels and accommodations where the period between check-in and check-out is counted in nights.
• 24-hour logic fits rentals where additional time after a full period may be rounded into another day.

Before publishing, compare the calculation across several examples. Pick dates that should result in one day, two days, two nights, and a period with one extra hour. If the administrator and the customer interpret the result differently, the setting needs to be fixed before any traffic is sent to the page.

Hourly and Mixed Rentals

Hourly rentals are useful for equipment, venues, services, and short-term rentals. A mixed model works well when the base price is daily, but a late return beyond a set time should add hourly charges or round up. Here the critical settings are minimum and maximum duration, available time windows, and the buffer between bookings.

Do not treat the buffer as a decorative setting. For a car, it is time for cleaning and inspection; for a room, it is cleaning time; for equipment, it covers handoff and return processing. Without a buffer, the calendar may look neat and fully booked, but the staff will not actually have time to prepare the item for the next reservation.

Hotels, Tours, and Guests

The hotel model is built around nights and check-in/check-out dates. The tour model can use guest types such as adults, children, infants, or other groups with different prices. The tour documentation mentions multi-day tours, one-day tours, and date ranges. These are not just different labels: each type comes with its own field set, capacity rules, and pricing logic.

If you are selling a tour, configure guest types and capacity first, then price and schedule. If you start with the form layout, you can easily miss the group limit and end up accepting bookings beyond the available number of seats.

Taxi, Transfers, and Routes

For taxi and transportation scenarios, BRW uses distance or a route model. The documentation describes a Taxi type with per-kilometer pricing, a base fare, a map, extra time, and waiting time. For fixed transfers, it usually makes more sense to use predefined points and route pricing so the customer does not get an unexpected quote because of a map or address variation.

This is where you especially need to verify the Google Maps API, address fields, distance unit, and rounding behavior. If the map fails to load, the customer may abandon the booking and the administrator may receive incomplete data.

Pricing, Deposits, Services, and Inventory: Connecting Settings to a Real Order

Once the rental type is chosen, you move into the most important part of setup: the order economics. In BRW, price can depend on the period, day of the week, time, distance, guest type, service, resource, insurance, deposit, and quantity. If those pieces are not tied together in a clear system, the customer sees one thing, the administrator expects another, and the order ends up showing something else entirely.

Base Price and Special Rules

For a simple starting point, set one clear rate. For example, a daily car rental with a fixed daily price. Run a test: choose start and end dates, then verify the amount on the product page, in the cart, and in the order. Only after that should you add different weekday prices, seasonal periods, long-duration discounts, or special time-based rates.

BRW supports flexible pricing rules, but flexibility should still be readable. If you have a high season, low season, and a long-rental discount, write down the rule priority. What takes precedence: the seasonal rate or the discount by number of days? How does a holiday promotion behave? If that is not documented within the team, the administrator will not be able to explain the price to the customer.

Deposits and Remaining Balance

The BRW documentation describes two deposit models: a fixed amount and a percentage of the total cost. It also covers balance-payment scenarios: the administrator can create the remaining payment manually, or the system can generate it automatically based on rules in the Deposit tab. This is a powerful feature, but it should not be enabled blindly.

Start with the question: should the customer be able to pay in full, or only make a partial payment? If you enable both options, make sure the wording in the form is clear. After a test payment, confirm that the partial-payment status is visible in Manage Bookings and that the remaining order or invoice is created at the expected time.

Resources and Services

Resources and services let you add paid options to a booking: child seat, driver, GPS, cleaning, insurance, guide service, or additional equipment. The documentation emphasizes that a resource may be calculated differently depending on the rental type: per day, per hour, or per order. That is critical to the final price.

If a child seat should be charged once per booking, do not configure it as a daily service. If equipment rental is billed hourly, an "operator" service may need to depend on duration. Test each option separately: select it in the form, change the period, and make sure the total changes exactly the way you intended.

Automatic and Manual Inventory

BRW supports two inventory approaches. Automatic inventory works for identical units, such as three identical bicycles or several identical equipment kits. You specify the quantity, and the plugin tracks how many units are already booked for the selected period.

Manual inventory is needed when the item has a specific ID: a car with a plate number, a piece of equipment with an asset code, a numbered unit, or a specific hall. The documentation describes creating entries in Manage Vehicle, assigning a unique ID, and connecting it to the product. This approach is more complex, but useful when the customer or administrator needs to know exactly which unit is being issued.

Practical rule: if the customer does not care which of several identical items they receive, use automatic inventory. If the business must assign a specific unit and show it in the order, use manual inventory and test availability by ID.

Calendar and Availability: How to Avoid Opening Occupied Dates

The calendar is where configuration mistakes become visible. If a date is occupied, it should be unavailable. If an order is not yet confirmed, the business must decide whether it still blocks the calendar. If there are blackout dates, they should either be hidden or shown as unavailable. In BRW, those decisions are tied to product settings, global options, and WooCommerce order statuses.

Allowed and Blocked Dates

The Rental Availability documentation separates allowed dates from disabled dates. Allowed dates define when booking is possible. Disabled dates prevent users from selecting specific days. For the customer, this should look unambiguous: available dates can be selected, unavailable ones cannot.

In the global product-page settings, you can control whether disabled dates are displayed. If they are shown, the customer more clearly understands that the date is closed rather than simply missing from the calendar. If the form feels overloaded, you can hide closed dates, but in that case it is smart to explain availability in text near the calendar.

Order Statuses and Calendar Blocking

One documented BRW issue involves calendar color and order status. If the payment method moves an order to on-hold, the calendar may not display that date as occupied in the expected way unless the list of counted statuses is configured to match your workflow. The official FAQ points to the brw_list_order_status filter for this.

This is a good example of why a test order needs to go through real statuses. It is not enough to select a date on the product page. You need to verify that after checkout the date is blocked for another customer and shown in the admin calendar the way the business expects.

iCal and Calendar Sync

BRW advertises iCal import and export, as well as sync with Google Calendar and other iCal-compatible platforms. That is convenient for administrators: it lets them view bookings in a familiar calendar or share availability with external channels. But sync should always be tested on a separate product and over a short time range.

Start by configuring the API data and a manual test, then create a test booking, sync it, and confirm that the time, date, product name, and status come through correctly. If automatic sync is enabled, also verify WordPress scheduling and server cron. On weak hosting, automated tasks may run irregularly.

Booking Forms, Search, and Elementor: Bringing the Workflow to the Site

BRW can be used inside the product page, through shortcodes, and through Elementor elements. The documentation lists separate shortcodes for search, AJAX search, hotel forms, taxi forms, product booking forms, request forms, calendars, price tables, features, images, metadata, and other blocks. That gives you flexibility, but it also requires discipline.

When the Product Page Is Enough

If the catalog is small and the customer usually selects a specific item, start with a standard WooCommerce product page. It is easier there to test the date, price, services, cart flow, and order creation. This is a good setup for a handful of cars, pieces of equipment, or individual rooms.

Do not complicate the structure until you have confirmed that the basic product page solves the business problem. Any separate search page, homepage form, or Elementor template should reflect the same business logic, not become a second independent interface.

When You Need Search

A search form is useful when the user starts with parameters rather than a specific product: travel dates, pickup location, category, guest count, departure point, or destination. In the global search settings, you can control the result template, columns, and field set. If the [ovabrw_search /] shortcode is used without parameters, it relies on those settings.

Show only the fields that actually affect the result. For a hotel, check-in, check-out, and guests matter. For a taxi service, pickup and drop-off locations matter. For equipment rental, sometimes date and category are enough. Extra fields make the form feel more complicated and increase abandonment.

Elementor and Product Templates

BRW supports Elementor elements and custom product page templates. The documentation shows the path through Templates, building a template, and selecting it in WooCommerce - Settings - Booking & Rental - Product Detail. Use that route when the standard product page does not fit the design or when you need to arrange the blocks in a specific order.

Before attaching an Elementor template, make sure all critical elements are present: the booking form, calendar, price, unavailable times, features, services, and the button leading to the cart or inquiry flow. After selecting the template, open the product in a private browser window and repeat the test booking. A visually polished template is not truly ready until it creates a correct order.

Practical Example: Car Rental with a Deposit and Manual Inventory

Let’s walk through a concrete scenario that shows both the strengths and the risk points of BRW. Suppose the site rents out three cars of the same model, but the business wants to track the specific vehicles by ID, accept a partial payment, show the pickup location, and block occupied dates.

Goal

You need to create a rental product called "Toyota Vios" where the customer selects pickup and return dates, sees the final price, can choose an additional service, pays a deposit through WooCommerce, and the administrator can see the booking, payment status, and the specific car in Manage Bookings.

Preparation

• WooCommerce and BRW are installed and active.
• The WooCommerce payment method has been tested on a regular product.
• The cart, checkout, and account pages are already created.
• Three unique vehicle IDs have been prepared.
• The pricing rule is known: a fixed daily rate, a percentage-based deposit, and one extra service charged per booking.

Configuration Steps

1. Go to BRW - Manage Vehicle and create three entries with clear unique IDs.
2. Open Products - Add New, then add the title, description, image, category, and vehicle features.
3. In Product data, select Rental, then choose daily rental in Rental Type.
4. Set the base price and the period calculation method. For rentals by calendar day, verify that the return date is counted the way the business expects.
5. In the inventory block, enable manual management and assign the created vehicle IDs to the product.
6. Enable deposits, choose either the percentage or fixed option, and decide whether full payment should also be shown as an alternative.
7. Add a service such as a child seat or additional driver, and specify whether it is charged per booking, per day, or by another rule.
8. Configure allowed or disabled dates if the car is unavailable during certain periods.
9. Publish the product in a test category and open it in a private browser window.

Result Check

Select the rental period and extra service, then go to the cart. Confirm that the amount matches the expected formula. Then place a test order. In the admin area, open BRW - Manage Bookings and make sure the booking is shown with the correct date, product, status, pickup location, and assigned unit.

After that, open the same product as a new customer and try selecting the same period for a quantity that exceeds the available inventory. If BRW still allows a repeat booking beyond what should be available, check the first order status, the inventory settings, the counted-status list, and the availability rules.

A Detail People Often Miss

If the payment method leaves the order in on-hold, the business needs to decide whether that status should block the calendar. This is especially important for bank transfer payments: the customer has not paid yet, but the slot may still need to be reserved. If that status is not accounted for, another customer may be able to book the same item.

Validating Results Before Publishing the Catalog

Before launching a real catalog, do not run just one test. Run a series of them. Rental settings often fail at the edges: a short period, a long period, same-day return, crossing a blocked date, an order with a deposit, an order without full payment, an order with an extra service, a customer cancellation, or a manual booking created by the administrator.

Minimum Test Matrix

Testing Across Different Roles

A WordPress administrator sees more than a customer does. So always test the public path in a private browser window while logged out of the admin area. Then log in as a customer and check the account area. If booking cancellation is enabled, confirm that the cancel button appears only for orders that meet the cancellation policy.

If the site has managers with limited permissions, check whether they can see Manage Bookings, order details, and the calendar. Do not grant extra permissions just for convenience. It is better to define the workflow clearly: who creates manual bookings, who changes statuses, who issues refunds, and who closes completed orders.

Safe Customizations and Output Adjustments Without Editing the Core

BRW supports template customization through the theme or child theme. The documentation recommends creating an ovabrw-templates folder inside the theme or child theme and copying the needed templates from plugins/ova-brw/ovabrw-templates/. That is safer than editing the plugin files directly because updates should not wipe out your changes.

Before making any changes, back up the file, enable a child theme, and edit only the specific template that actually controls the block you need. If the task can be solved with a color setting, text change, or Elementor template, do not start with PHP.

Overriding the Search Template

For example, if you need to adapt the output of the search shortcode, the documentation provides the path for the search_form_full.php file. The logic is simple: copy the template from the plugin into the matching folder in your theme, then edit the copy.

plugins/ova-brw/ovabrw-templates/shortcode/search_form_full.php
to
themes/your-theme/ovabrw-templates/shortcode/search_form_full.php

After copying, open the search page, clear the cache, and test the form. If something goes wrong, delete the copied file from the child theme and WordPress will start loading the template from the plugin again.

Order Statuses That Block the Calendar

The official BRW FAQ shows the brw_list_order_status filter. You can use it if the business wants orders in on-hold status to count as occupied in the calendar. Add the code through a child theme or a snippets plugin, not into WordPress core and not into BRW files.

add_filter( 'brw_list_order_status', function() {
    return array( 'wc-completed', 'wc-processing', 'wc-on-hold' );
} );

The test is straightforward: create a test order with the target status, open the product as a new customer, and confirm that the occupied period cannot be selected. If the business decides that unpaid orders should not block the calendar, remove the snippet or keep only the statuses you actually need.

Hiding the Price in the Calendar

The FAQ also includes a filter for removing the price from the calendar. It can be useful if the price should appear only after the customer selects a period, or if the calendar looks too crowded. But first make sure the problem cannot be solved through a template or design adjustment.

add_filter( 'ovabrw_get_calendar_price_html', function( $price ) {
    return '';
} );

After adding it, open the product and check both the calendar and the final amount. The snippet should change only the visual price output inside the calendar, not the order calculation itself. To roll it back, remove the code and clear the cache.

Limitations You Should Know Up Front

BRW offers a broad feature set, but breadth does not remove the need for testing. The more scenarios one plugin tries to cover, the more important it becomes not to enable unnecessary features and not to copy settings between different rental types without reviewing them.

The first limitation is complexity. For a simple one-service booking site, BRW may be more than you need. You will have to maintain WooCommerce, checkout pages, emails, statuses, the calendar, product templates, and product-level settings. If the business process is very simple, a request form with manual confirmation may be cheaper to maintain.

The second limitation is dependence on WooCommerce and the theme. BRW uses products and checkout logic, so conflicts most often show up on the product page, in the cart, in calendar scripts, in AJAX search, and in emails. After a theme switch, a WooCommerce update, or the activation of a new caching plugin, rerun the test matrix.

The third limitation is external synchronization. iCal and Google Calendar are useful, but delays, statuses, time zones, and third-party platform limits need to be tested separately. Do not promise customers instant two-way sync across all channels unless that behavior has been verified in your actual workflow.

The fourth limitation is catalog performance. According to the product page, BRW uses a separate order-queue table for faster availability checks, but a large catalog with many filters, maps, search features, and a high volume of orders still needs load testing. Product images, cache behavior, search queries, and the number of simultaneous AJAX checks can all affect speed.

Booking Administration: What to Do After the First Order

Once the product is published, the work is not finished. BRW adds its own administrative workflows: booking lists, manual order creation, calendar review, availability checks, deposit handling, calendar sync, and closing completed bookings. If these steps are not defined for the team, even a correctly configured product will be used inconsistently.

Booking List and Filters

In the documentation, Manage Bookings is used to search for and review orders by different criteria: order number, customer name, period, vehicle, pickup location, return location, product, and status. That is more useful than the standard WooCommerce order list because a rental administrator usually thinks less in terms of "which order is new" and more in terms of "what is occupied for this period" and "which item needs to be issued."

Set up a simple daily routine for the manager: in the morning, open the booking list, filter by period, review orders in Processing, Completed, and any statuses the business treats as reserving inventory, then confirm upcoming pickups and returns. If manual inventory is used, also verify the exact unit ID.

Manual Booking Creation

The BRW documentation describes the Add New Booking section for cases where a customer reaches out by phone, messenger, or email. This is an important feature in the rental business: some orders will always come in outside the public form, especially for local rentals and hotel bookings.

When creating an order manually, the administrator selects the status, fills in the customer details, adds the product, and enters the rental fields: pickup location, return location, dates, quantity, guests, insurance, deposit, and cost. Once created, that booking should appear in Manage Bookings. If the customer needs to pay online, the administrator can send a payment link from the WooCommerce order.

Manual booking check: create a test order from the admin area, then open the calendar and the public product page. The period should behave the same way as a booking created by the customer through the site.

Administrator Calendar

Booking Calendar lets you review bookings across all products or for a specific product, switch between views, and check availability. For a manager, this is an operational dashboard, not just a visual report. If disputes come up with a customer, the calendar helps you quickly see whether the date is occupied, which order took it, and which item is attached to the booking.

During rollout, it is useful to agree on a "closed" status or another internal marker for completed rentals. The documentation recommends closing an order after the customer has finished using the product or service. That helps with search and availability checks. Do not change statuses retroactively unless you understand how they affect the calendar.

Operational Checklist for the Team

• Review new bookings and partial payments at the start of each workday.
• Check upcoming pickups and returns against the calendar, not just email notifications.
• Create manual orders through Add New Booking so they appear in the shared calendar.
• Record cancellations and refunds through the WooCommerce order, not only in customer correspondence.
• After the service is completed, move the order to the agreed final status so the booking list does not turn into an unstructured archive.

This may sound like a minor administrative detail, but it is exactly what protects the site from overlaps. The plugin may calculate availability correctly, but if some bookings are tracked outside the system, the calendar stops being the source of truth.

Why Bookings May Behave Incorrectly and How to Diagnose It

Troubleshooting should not revolve around the vague phrase "the plugin does not work." BRW sits between the WooCommerce product, the calendar, the form, the order, the payment, and the emails. That means the real cause of a problem is often not where the customer actually sees the symptom.

The date looks available, but it should be occupied

Symptom: the customer can select a period that has already been booked by someone else. A possible cause is that the order is in a status the calendar does not count, inventory is configured as shared instead of manual, or the booking was not created through the correct WooCommerce flow.

Check the order in WooCommerce - Orders, then open BRW - Manage Bookings. If the order exists but the calendar does not block it, review the list of counted statuses. For on-hold, use the documented filter only after testing it on a site copy.

The final price does not match expectations

Symptom: the selected period results in more or fewer days than the manager expects. The cause is often the calculation method: calendar day, night, and a 24-hour period produce different outcomes. Services, deposits, discounts, weekday rules, and guest types can also affect the price.

Start by disabling extra services and complex discounts on the test product. Verify the clean base formula first. Then turn the layers back on one by one: deposit, resource, daily pricing, discount. That makes it easier to see which layer is changing the total.

Map or taxi addresses do not work

Symptom: route fields do not calculate distance, the map does not load, or the form cannot complete the order. A possible cause is incorrect Google API setup, domain restrictions, scripts blocked by optimization, a theme conflict, or incomplete address fields.

Check the keys, domain restrictions, browser console, and the form behavior without JavaScript bundling. If the map starts working after optimization is disabled, add the map and BRW scripts to the exclusions in your caching plugin.

The deposit works, but the remaining payment is not created

Symptom: the customer paid part of the amount, but the remaining order or email never appeared. The cause may be disabled automation, an incorrect number of days before the pickup date, a broken WordPress scheduler, or mail delivery issues.

Check the Deposit tab in global settings, the original order, the payment status, and the mail log if you use one. For business-critical projects, it is safer to start with manual balance-payment creation and enable automation only after several successful tests.

The search form shows unnecessary fields

Symptom: the search page shows fields that do not apply to your scenario, or the customer is forced to choose unnecessary values. The usual cause is either the global search settings or shortcode parameters.

Open WooCommerce - Settings - Booking & Rental - Search and leave only the fields that truly filter products. After making changes, clear the cache and test the page in a private browser window.

A form element disappeared after a template change

Symptom: the booking form, price, or calendar disappeared after editing the theme or Elementor template. A possible cause is that the template does not include the required widget, the override file is outdated, or it was copied into the wrong folder.

Temporarily disable the template override by renaming the file in the child theme and check the default output. If the default output works, the problem is in the customization. Verify the ovabrw-templates path, update the template copy, and move the changes over in small pieces.

When CodeCanyon BRW Is the Right Choice

CodeCanyon BRW is worth using if you need more than a basic calendar and want a full rental and booking system inside WooCommerce: with products, cart flow, orders, payments, statuses, inventory, availability, deposits, extra services, and booking management. The plugin works especially well when your business involves multiple rental models and the logic needs to match real operational rules.

Before launch, do not stop at installation. Build one test scenario, configure the product, and verify the price, occupied dates, order, email, status, calendar, and repeat-booking behavior. If that path works correctly, you can expand the catalog and then add search, Elementor templates, manual inventory, reminders, and synchronization.

Once your preparation is complete and you understand which rental model your site actually needs, you can get the CodeCanyon BRW file and test the plugin on a staging copy of the site. That approach is much safer than launching bookings directly on the live catalog and fixing mistakes only after the first real orders.