Hi, @hermit

Thank you for the update.

We have noted that the backend is working correctly. For the frontend image issue, please clear the Bagisto cache and regenerate the images, then check the storefront again.

If the issue still occurs after these steps, please share the error details or a screenshot of the frontend so we can investigate it further.

Best regards,
Aviral
Bagisto

Dear @B4ALLB4U ,

Thank you for contacting us, and we apologize for the inconvenience.

If your storefront appears blank after changing the URL from localhost to your domain, the issue may be related to the channel domain configuration, .env settings, theme assets, or cache. Please follow the steps below in order.

1. Check the Channel URL

Go to Admin → Settings → Channels and open the channel you are using.

Make sure the Host Name matches your domain. Enter the domain without http:// or https://.

For example:

✅ www.yourstore.com ❌ https://www.yourstore.com

The value should match the domain you use to access the storefront in your browser.

2. Update the .env File

Open the .env file in your Bagisto root directory and update the application URL:

APP_URL=https://www.yourstore.com APP_ENV=production

Use https:// only if your domain has an active SSL certificate. Make sure the protocol matches the URL you use in your browser.

3. Check Your Domain Document Root

Make sure your domain points to the Bagisto public directory.

For example:

/path-to-bagisto/public

Also, make sure the .htaccess file exists inside the public directory and that Apache's mod_rewrite is enabled.

4. Clear the Bagisto Cache

If you have SSH access, run the following commands from your Bagisto root directory:

php artisan optimize:clear php artisan config:clear php artisan storage:link

Then reload the storefront.

5. Check the Theme Assets

Make sure the required theme assets exist in the following location:

public/themes/shop/default

If the directory or required files are missing, reinstall or regenerate the Bagisto theme assets.

6. Check File Permissions

Make sure the web server has permission to read the application files and write to the required directories, especially:

storage/ bootstrap/cache/ If the Storefront Is Still Blank

Please share the following details with us so we can investigate further:

The latest entries from storage/logs/laravel.log A screenshot of the Console tab from your browser's Developer Tools Your PHP version Your Bagisto version The domain URL you are using

You can temporarily set the following in your .env file to display the actual error:

APP_DEBUG=true

After identifying the issue, please set it back to:

APP_DEBUG=false

Once we have the above details, we can investigate the issue further.

Best regards,
Aviral
Bagisto

If you're looking at a Laravel-based approach, I’d first check whether the solution has proper API support for Bagisto rather than relying on direct database syncing. Product and category updates should ideally flow through APIs so the app stays consistent with the store.

For the mobile side, it’s also worth checking how the solution handles authentication, push notifications, caching, and offline states. A well-structured mobile app integration should make synchronization reliable without putting unnecessary load on the Bagisto backend.

Hello, @gkdev

Greetings!

As you confirmed, you were previously working on the master branch, which contains the newer Bagisto 2.5 version, and then switched to the 2.4 branch.

Please note that once Bagisto has been installed, you cannot move back to an older version simply by switching branches. If you need to use the older branch/code, you will need to reinstall Bagisto using the required version.

If your project contains any production data, we strongly recommend that you do not downgrade or switch to an older version, as the database structure of a newer Bagisto version may not be compatible with an older version.

If you do not have any production data and want to start with a fresh Bagisto 2.4 installation, you can clone the Bagisto 2.4 branch and install it using:

composer install php artisan bagisto:install

Note: If you have any important data, customizations, or changes, please make sure to take a complete backup before reinstalling.

Also, please note that the database of a newer Bagisto version cannot simply be used with an older Bagisto version, as the database structure and migrations may differ between versions.

Regarding the 403 Forbidden Error
The 403 Forbidden error is generally related to server configuration or file permissions. Please ensure that the web-server user has the required read/write permissions for the Bagisto application directories.

For a standard Linux server using www-data as the web-server user, you can use the following commands from the Bagisto project directory:

sudo chown -R www-data:www-data storage bootstrap/cache sudo chmod -R 775 storage bootstrap/cache

If your web server uses a different user, such as nginx or nobody, replace www-data with the appropriate web-server user.

You can check the web-server user based on your server configuration/processes before applying the ownership command.

If the issue persists, you can also ensure that the Bagisto project directories are accessible by the web server:

sudo chmod -R 755 /path/to/bagisto sudo chmod -R 775 /path/to/bagisto/storage sudo chmod -R 775 /path/to/bagisto/bootstrap/cache

Please replace /path/to/bagisto with your actual Bagisto project path.

After updating the permissions, clear the application cache:

php artisan optimize:clear

Important: We recommend avoiding chmod -R 777 on the Bagisto project, as it provides unnecessarily broad permissions and is not recommended for a production server.

Thank you.
Aviral
Team Bagisto

@rahil This type of functionality can be customized, but as of now, Bagisto does not automatically add a free product to the cart based on the purchase of another product.

For example, if the customer purchases Product X, we can customize the system so that Product Y is automatically added to the cart as a free product.

This would require custom development to implement the required promotion logic.

Thanks

Hello @barnaddy06

The best approach is to implement this as a custom shipping carrier.

You should not read the destination country directly from the request or session. Get the current cart and retrieve the country from the cart's shipping address:

use Webkul\Checkout\Facades\Cart; $cart = Cart::getCart(); $country = $cart->shipping_address?->country ?? $cart->billing_address?->country;

The country value will be the ISO country code, for example:

US GB NL AU

For weight, if you are using Bagisto's native weight attribute, you should use the cart item total_weight instead of recalculating the product weight manually:

$totalWeight = 0; foreach ($cart->items as $item) { if (! $item->getTypeInstance()->isStockable()) { continue; } $totalWeight += (float) $item->total_weight; }

Using $cart->items is important because all_items may include child items and can result in double-counting for configurable or bundle products.

Then create a custom carrier extending AbstractShipping and perform the country + weight calculation inside the calculate() method:

class InternationalRate extends AbstractShipping { protected $code = 'international'; public function calculate() { if (! $this->isAvailable()) { return false; } $cart = Cart::getCart(); if (! $cart || ! $cart->haveStockableItems()) { return false; } $country = $cart->shipping_address?->country ?? $cart->billing_address?->country; $weight = 0; foreach ($cart->items as $item) { if (! $item->getTypeInstance()->isStockable()) { continue; } $weight += (float) $item->total_weight; } $rates = [ 'US' => ['handling' => 8, 'per_kg' => 2.5], 'GB' => ['handling' => 6, 'per_kg' => 2], 'NL' => ['handling' => 6.5, 'per_kg' => 2.2], 'AU' => ['handling' => 12, 'per_kg' => 4], ]; if (! isset($rates[$country])) { return false; } $basePrice = $rates[$country]['handling'] + ($weight * $rates[$country]['per_kg']); return $this->getRate($basePrice); } }

The main point is:

Cart → Shipping Address Country + Cart Item Weight → Custom Carrier → Calculated Shipping Rate

Also, make sure to set both base_price and price on the CartShippingRate. The base price should be calculated in the store's base currency, while price should be converted using:

$rate->base_price = $basePrice; $rate->price = core()->convertPrice($basePrice);

If the shipping rules become more complex, such as multiple weight slabs per country, I would recommend storing the rules in a database table rather than hardcoding them.

One important note: if your product weight is stored in a completely custom attribute instead of Bagisto's native weight attribute, total_weight may not be populated. In that case, either map your value to Bagisto's native weight field or calculate it from your custom attribute manually.

For this requirement, a custom shipping carrier is the cleanest and most maintainable Bagisto solution.

Best regards,
Shivendra Gupta
Team Bagisto

I'd recommend checking whether the payment module is fully compatible with your current version and ensuring it was installed correctly; if the issue persists, it may be a bug that requires a module update or a small code fix.

Hi

Thank you for your feedback. We understand the importance of keeping pace with Laravel releases for security, stability, and long-term maintainability. We are planning to support Laravel 13 in the upcoming Bagisto v2.5.x release. Currently, Bagisto runs on Laravel 12, and we continue to provide security fixes and updates for Laravel 12 through the v2.4.x release series to ensure a stable and secure experience for existing users.

Thanks
Aviral
Team Bagisto

Hi,

Welcome to Bagisto!

The syntax itself is correct, but that declaration (const int USER_ID = 1;) uses typed class constants, which are only supported in PHP 8.3 and later.

This error usually means your server is running an older PHP version (such as 8.2, 8.1, or below), so PHP doesn't recognize the int type before the constant name and throws the parse error.

You can verify your PHP version by running:

php -v

or by checking the output of phpinfo() if you're using a web server.

If you're using a PHP version below 8.3, please upgrade to PHP 8.3, as the current Bagisto version requires it.

Thanks
Aviral
Team Bagisto

Hello @Snake

The important thing to understand first: in Bagisto the shipping and
payment steps aren't just UI — order creation still needs a shipping method and a
payment method saved on the cart. If you simply delete those steps, placing the order
will fail validation. So the cleanest approach is NOT to remove the steps, but to
AUTO-SELECT your single shipping and single payment method behind the scenes, then jump
straight to the "Place Order" button.

How the checkout flow works (so the fix makes sense)

The onepage checkout is a Vue flow with 4 steps: address -> shipping -> payment -> review.

Saving the billing address returns the available shipping methods. Selecting a shipping method saves it and returns the payment methods. Selecting a payment method saves it and moves to "review", which enables Place Order.

So instead of showing the shipping and payment screens, we let the address save trigger
those two saves automatically with your only method, then show Place Order.

Cleanest way (no core edits — override the view in your theme)

Override this file in your own theme (do not edit the package directly):

packages/Webkul/Shop/src/Resources/views/checkout/onepage/index.blade.php

In the Vue component, after the address step is processed, chain the two saves
automatically. The relevant handler is where the address emits its result
(stepProcessed / the 'processed' handler). Replace the normal step-forward logic with
an auto-advance like this:

// after address is saved, `shippingMethods` is available autoCheckout(shippingMethods) { // 1) pick the only shipping method code (e.g. "flatrate_flatrate") const shippingCode = Object.values(shippingMethods)[0].rates[0].method; this.$axios.post("{{ route('shop.checkout.onepage.shipping_methods.store') }}", { shipping_method: shippingCode, }) .then(response => { // 2) pick the only payment method and save it const payment = response.data.payment_methods[0]; return this.$axios.post("{{ route('shop.checkout.onepage.payment_methods.store') }}", { payment: { method: payment.method }, }); }) .then(response => { // 3) cart now has shipping + payment set -> enable Place Order this.selectedPaymentMethod = null; this.currentStep = 'review'; this.canPlaceOrder = true; this.getCart(); }); }

Then call autoCheckout(shippingMethods) from the address 'processed' handler instead of
moving to the shipping step, and hide the shipping/payment includes (the
<template v-if="... 'shipping' ...">/'payment' blocks in the same file). The "Continue"
buttons live inside those shipping/payment sections, so once they're hidden the customer
only sees: fill address -> Place Order.

Note: if your store has no stockable items, the address save returns payment_methods
directly (no shipping step) — the code above handles the normal stockable case; adjust
if needed.

Why this is the right approach No core files are modified, so upgrades stay clean. The cart still ends up with a valid shipping method + payment, so Place Order and the
order confirmation work exactly as normal. If you later add a second shipping or payment option, you only revert this override.

Thanks
Team Bagisto

Hello Justin,
Greetings!

Support for displaying third-level child categories on the frontend/API has been improved in the latest versions of Bagisto.

Kindly update to the latest version of Bagisto, as it includes the necessary changes for nested category support.

If you still encounter the same issue after upgrading, please let us know your Bagisto version and the API endpoint you are using. We'll be happy to assist you further.

Thank you!

Kartikey Dubey
Team Bagisto

@alex32 said in Bagisto 2.2.4 | Homepage not working:

I've installed Bagisto via Composer and with the Zip file.
I get the same problem when I try to access the homepage (attached).
The tables are saved in the database and there are no errors during the installation, but the homepage doesn't show up.
There is no log file under /storage/logs

Hello

Thanks for the details.

Since the installation completes successfully and the database tables are created, the issue is likely occurring when the application tries to render the homepage.

Could you please share the following?

The exact error message or a screenshot of the page you're seeing. The output of php artisan about. Your PHP and Laravel versions. The contents of your .env file (please hide any sensitive values such as passwords and API keys).

Also, if there is no log file under storage/logs, please make sure the storage and bootstrap/cache directories are writable, then run:

php artisan optimize:clear php artisan config:clear php artisan cache:clear

After that, try accessing the homepage again and let us know if any log file is generated or if the error changes.

Thanks
Aviral

Hello @kenninh

Glad you resolved it — and your diagnosis is exactly right. The error came from the
inventories column format, not from a missing package.

Please let us know if you face any issue further.

Thanks
Team bagisto

Hello @kenninh

You're right on both points — here's what's happening.

The success page relies on the order id being stored in the session like this:

session()->flash('order_id', $order->id);

Flash data in Laravel only lives for ONE request. That single detail explains both behaviors you're seeing.

Refreshing the success page redirects to the cart
This is normal/expected. The success page reads order_id once and renders it.
On refresh the flashed value is already gone, so there's no order to show and
it falls back to the cart page. Nothing needs fixing here.

Sometimes it goes straight to the cart instead of the success page
This is the real issue. Because the value survives only one request, if any
other request touches the session between "Place Order" and the success page
loading, the order_id gets consumed early and is lost. Common triggers:

a background request (mini-cart / cart summary) firing during the redirect a double click or browser prefetch a slow or non-shared session store (e.g. multiple servers behind a load
balancer without a shared session driver)
That timing race is why it only happens sometimes.

Thanks
Team Bagisto

Hello @beabay

Thanks for the details — the screenshots are very helpful. This is almost certainly NOT caused by your OnepageController edits. It's a side effect of running migrate:fresh, and here's why.

What's happening

product_inventory_indices is not filled directly from product_inventories. It's calculated by the inventory indexer, which sums a product's inventory ONLY for the inventory sources that are linked to your channel and are active. The relevant code is:

// Webkul\Product\Helpers\Indexers\Inventory::getQuantity() $channelInventorySourceIds = $this->channel->inventory_sources->where('status', 1)->pluck('id'); // qty is only added when the product's inventory_source_id is in that list

migrate:fresh DROPS all tables and re-runs migrations only — it does NOT re-run the seeders. So the channel_inventory_sources link table (channel <-> inventory source) ends up empty. With no active source linked to the channel, the indexer correctly computes qty = 0 for every product, even though product_inventories still shows 2. That's also why re-indexing and reverting your code changed nothing — it's a data/seed problem, not a code problem.

How to fix (short version)

Re-seed the core data that migrate:fresh wiped:

php artisan migrate:fresh --seed

(or reinstall cleanly: php artisan bagisto:install)

Confirm the link exists — the channel_inventory_sources table should have a row (channel_id = 1, inventory_source_id = 1), and in Admin -> Settings -> Inventory Sources the source must be Active (status = 1).

Rebuild the indices:

php artisan indexer:index --type=inventory

After that, product_inventory_indices.qty will match your stock again.

One extra note for the automatic update on save

The index job runs on the catalog.product.update.after event and is dispatched as a QUEUED job. Make sure QUEUE_CONNECTION=sync in .env (for local/dev) OR that a queue worker is running (php artisan queue:work) — otherwise the index won't refresh when you edit products. Also note the index for a brand-new product is built on the first save/update, not on the initial create.

Thanks
Team Bagisto

@enamulislamjisan
Updating only the qty on a refund item is not enough. The collectTotals() methods do not recalculate item amounts from the quantity—they only sum the values already stored on the refund items.

Because of this, changing refund_item.qty alone leaves fields such as total, base_total, tax_amount, and discount_amount unchanged, so the refund and order totals remain the same.

Recommended approach

If you're modifying the refund quantity for a partial refund, update the quantity before creating the refund. The RefundRepository::create() method calculates all refund item amounts, refund totals, order totals, and inventory adjustments based on the quantities provided in the input data.

For example:

$data['refund']['items'][$orderItemId] = $newQty; $refund = $refundRepository->create($data);

This ensures all related calculations are performed correctly.

If the refund has already been created

If you need to modify an existing refund, changing the qty alone is insufficient. You must also recalculate the refund item's monetary fields (such as total, base_total, tax_amount, and discount_amount) based on the new quantity, then call the appropriate collectTotals() methods to update the refund and order aggregates.

Keep in mind that if the refund quantity changes after creation, you may also need to adjust inventory manually, as inventory updates are handled during refund creation and are not recalculated by collectTotals().

@gauravjain1
Bagisto does not provide browser/web push notifications out of the box. The built-in notification system is only for in-app admin notifications (such as the notification bell in the admin panel) and does not send push notifications to browsers.

To add web push notifications, you have two options:

Use the official Web Push Notification extension available on the Bagisto Marketplace. Implement your own solution using Firebase Cloud Messaging (FCM). Implementing web push notifications with Firebase Cloud Messaging (FCM)

A typical implementation consists of the following steps:

Set up Firebase

Create a Firebase project. Register a Web App. Generate a Web Push (VAPID) key. Download the Firebase service account credentials for server-side authentication.

Store browser tokens

Register a Service Worker (firebase-messaging-sw.js). Request notification permission from the user. Retrieve the FCM registration token and store it in your Bagisto application.

Send notifications

Use an FCM package such as kreait/laravel-firebase or laravel-notification-channels/fcm to send notifications through the FCM HTTP v1 API.

Trigger notifications

Listen to Bagisto events (for example, order placement or order status updates) and send push notifications to the stored FCM tokens. Important notes Web push notifications require HTTPS (except on localhost during development). The Service Worker must be served from the application's root so it can control the entire site. Use the FCM HTTP v1 API, as the legacy FCM API is deprecated. Add your frontend JavaScript through a theme override or a view_render_event listener instead of modifying Bagisto core files.

This approach allows you to send push notifications for events such as new orders, order status updates, promotions, or any other custom events in your Bagisto application.

@wadim
You shouldn't need to run vendor:publish or php artisan cache:clear every time you modify your theme's Blade views.

The most likely reason is that your theme is loading views from the published directory instead of directly from your package source. Check the views_path for your theme in config/themes.php. If it points to the published location (for example, resources/themes/...), update it to point to your package's source views directory instead, such as:

'views_path' => 'packages/Km/Theme/src/Resources/views',

Once the theme is loading views directly from the package source, changes to .blade.php files are picked up automatically by Laravel. You should only need to refresh your browser, as Blade recompiles templates when the source files change.

For frontend assets (CSS and JavaScript), use:

npm run dev

during development instead of repeatedly running npm run build. The Vite development server watches for changes and reloads assets automatically.

If you ever need to clear compiled Blade templates manually, use:

php artisan view:clear

rather than clearing the entire application cache.

Development workflow Blade (.blade.php) changes: Refresh the browser. CSS/JS changes: Keep npm run dev running. vendor:publish: Only needed when initially publishing package resources or when you intentionally want to update the published copies, not for everyday view development.

Hello,
Greetings!

The Razorpay SDK cannot be used directly with Bagisto without additional customization.

Razorpay has now been integrated into the latest version of Bagisto. You can clone the latest Bagisto repository and follow our installation guide to get started:

https://devdocs.bagisto.com/getting-started/installation

You can also refer to our Razorpay configuration guide for detailed setup instructions:

https://docs.bagisto.com/configure/payment-methods.html#razorpay

If you face any issues during the installation or configuration process, please let us know. We'll be happy to assist you.

Thank you!

Kartikey Dubey
Team Bagisto

Hello,
Greetings!

Kindly follow the installation guide provided in our official documentation:

https://devdocs.bagisto.com/getting-started/installation

If you encounter any issues while following the installation steps, please let us know by sharing the error details or screenshots. We will be happy to assist you in resolving them.

Thank you!

Kartikey Dubey
Team Bagisto