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

@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

@telrefaie1980 The payment method icon displayed on the checkout page is provided by the getImage() method. By default, it retrieves the image from the payment method configuration using:

$this->getConfigData('image')

The package generator creates a basic payment method, but it does not include an Image/Logo field in the generated system.php configuration. As a result, there is no option to upload an icon from the admin panel, and getImage() returns null, so no icon is displayed.

Solution

Add an image field to your payment method configuration in src/Config/system.php:

[ 'name' => 'image', 'title' => 'admin::app.configuration.index.sales.payment-methods.logo', 'type' => 'image', 'depends' => 'active:1', 'channel_based' => true, 'locale_based' => false, 'validation' => 'mimes:bmp,jpeg,jpg,png,webp', ],

Then clear the cache:

php artisan optimize:clear

After that, go to Admin → Configure → Sales → Payment Methods → Your Payment Method, upload the logo, and save the configuration. The uploaded icon will then be displayed on the checkout page.

Alternatively, if you want to use a fixed icon instead of an admin-uploaded one, you can override the getImage() method in your payment class:

public function getImage() { return $this->getConfigData('image') ?: bagisto_asset('images/your-icon.png', 'shop'); }

Place the icon in your package's published assets so that bagisto_asset() can resolve it correctly.

Note: The missing composer.json file generated by the package generator is unrelated to the payment icon. The icon is controlled entirely by the payment method configuration and the getImage() method.

@Miswanto Why can't the price be more than one hundred million rupiah?

This limitation is not controlled by a setting in the Bagisto admin panel. It is usually caused by the database schema used to store price values.

If the price-related columns in your Bagisto installation are defined as DECIMAL(12,4), the database can store a maximum value of:

99,999,999.9999

This is because DECIMAL(12,4) allows:

12 total digits 4 digits after the decimal point 8 digits before the decimal point

A price of 100,000,000.0000 requires 9 digits before the decimal point, so it exceeds the column's capacity and the database rejects the value.

Where can I change it?

There is no configuration or admin setting in Bagisto to increase the maximum price. The limit comes from the database column definitions.

To support prices greater than 100 million rupiah, increase the precision of the relevant price columns, for example from DECIMAL(12,4) to DECIMAL(18,4), by creating a database migration and then running:

php artisan migrate

Make sure all price-related database columns use the same precision. Updating only the product price column may not be enough, as price values are also used in carts, orders, invoices, and refunds.

Summary

The 100 million rupiah limit is a database schema limitation, not a Bagisto configuration setting. Updating the relevant price columns to a larger precision such as DECIMAL(18,4) through a database migration will allow prices above 100 million rupiah to be stored and processed correctly.

Hi,

Thank you for reaching out.

In Bagisto v2.3.7, visitor logging works through a queued process. When a user visits a supported page, the visitor()->visit() method dispatches the UpdateCreateVisitIndex job, which is responsible for inserting the record into the visits table. If any part of this process is not configured correctly, no records will be stored, even after multiple visits.

Please go through the following checks:

1. Verify that Visitor Logging is Enabled

Navigate to Admin → Configure → General → General → Visitor Options and ensure that Enabled is set to ON.

This option is disabled by default in Bagisto. If it is disabled, visitor tracking exits immediately without creating any records.

After enabling it, please clear the application cache:

php artisan optimize:clear 2. Verify That the Queue Worker Is Running

Visitor records are created through a queued job, so they are only written to the database after the queue worker processes them.

Check the value of QUEUE_CONNECTION in your .env file. If it is set to database, redis, or sqs, make sure a queue worker is running: php artisan queue:work In a production environment, the queue worker should be managed by Supervisor or systemd so it remains running. If QUEUE_CONNECTION=sync, jobs are executed immediately and no queue worker is required.

You can also verify the queue status using Laravel Tinker:

DB::table('jobs')->count(); DB::table('failed_jobs')->count(); If the jobs count continues to increase, the queue worker is not processing jobs. If failed_jobs contains records, please review the exception column to identify the failure. 3. Verify the Page You're Testing

Visitor tracking is intentionally limited to the following pages:

Home page Product pages Category pages (URL rewrite routes)

Visits to cart, checkout, search, CMS, and customer account pages are not recorded. Please perform your test on the homepage or a product/category page.

4. Understand Visit Deduplication

Bagisto stores only one visit per day for the same combination of:

HTTP method URL IP address Visitor ID Channel ID

Refreshing the same page from the same IP address will not create additional records. To verify the functionality, try using an incognito window or access the site from a different IP address.

5. If Response Cache Is Enabled

If you have the following setting in your .env file:

RESPONSE_CACHE_ENABLED=true

cached responses bypass the controller. Bagisto still dispatches the visitor logging job through an event listener, but this also depends on Visitor Options → Enabled being turned on.

6. Check the Excluded URL List

Please review the except array in:

config/visitor.php

Any URL matching these patterns will be excluded from visitor tracking. If this file has been customized, ensure that the page you're testing is not listed there.

Recommended Verification Steps Enable Visitor Options from the admin panel. Run: php artisan optimize:clear Temporarily set: QUEUE_CONNECTION=sync Clear the cache again. Open the storefront homepage in an incognito browser window. Run the following SQL query: SELECT * FROM visits ORDER BY id DESC LIMIT 5;

You should now see a new record in the visits table.

Once you've confirmed that visitor logging is working, you can switch QUEUE_CONNECTION back to database (or your preferred driver) and ensure that a queue worker is running continuously.

If the visits table is still empty after completing the above steps, please share the following information:

The value of QUEUE_CONNECTION from your .env file. The output of the following Tinker commands: DB::table('jobs')->count(); DB::table('failed_jobs')->count(); Any recent entries from storage/logs/laravel.log. A screenshot of Admin → Configure → General → General → Visitor Options.

With this information, we'll be able to identify the root cause more accurately.

Best Regards,
Team Bagisto

Hi,

Thank you for reaching out.

This is a known issue in Bagisto v2.3.6. The problem is not with the Load More button itself.

The root cause is that Laravel's paginator generates the next page URL based on the incoming request. When your application is running behind a reverse proxy (such as Nginx, Cloudflare, or a load balancer) that terminates HTTPS, Laravel may detect the request as HTTP unless the proxy is trusted. As a result, the pagination URL is generated with http:// instead of https://.

This issue has already been fixed in the Bagisto core and is available starting from v2.3.10.

Recommended Solution

Upgrade your Bagisto installation to v2.3.10 or later. This release includes the trusted proxy fix along with other important improvements and bug fixes.

Alternative (for v2.3.6)

If upgrading is not possible at the moment, you can apply the same fix manually.

In your bootstrap/app.php file, inside the ->withMiddleware(...) block, add:

$middleware->trustProxies('*');

After making the change, clear the application cache:

php artisan optimize:clear Please also verify the following server configuration

Ensure APP_URL in your .env file is set to your HTTPS URL, for example:

APP_URL=https://yourdomain.com

Make sure your reverse proxy forwards the X-Forwarded-Proto: https header.

Nginx:

proxy_set_header X-Forwarded-Proto $scheme;

Cloudflare: This header is forwarded automatically.

Once the trusted proxy configuration is in place, Laravel will correctly detect HTTPS requests, and the Load More button will generate secure (https://) pagination URLs.

Please let us know if you need any assistance applying the fix or upgrading your Bagisto installation.

Best regards
Team Bagisto

Hi,

Thank you for reaching out.

This behavior is expected in Bagisto.

The Invoice Status and Order Status are managed independently:

Invoice Status indicates the payment status (e.g. Pending or Paid). Order Status represents the order lifecycle (e.g. Pending Payment, Processing, Completed).

For Cash on Delivery (COD) orders, the initial order status is determined by the Cash on Delivery configuration at the time the order is created. Updating an invoice to Paid later does not automatically update the order status.

For future COD orders

Please check the following configuration:

Admin → Configure → Sales → Payment Methods → Cash On Delivery

Recommended settings:

Generate Invoice: Yes Invoice Status: Paid Order Status: Processing (or Pending, depending on your preferred workflow)

With this configuration, new COD orders will be created with a Paid invoice and the configured order status.

For existing orders

If an order is already showing:

Order Status: Pending Payment Invoice Status: Paid

the order status will not change automatically if the invoice status was updated manually. The recommended approach is to use Bagisto's standard order workflow (Invoice/Shipment actions from the Admin panel), which recalculates the order status automatically.

If the invoice has already been marked as Paid and the order has been fully processed, you can manually update the order status (for example, to Processing or Completed, depending on whether the order has been shipped).

Best regards
Team Bagisto

Hi,

We reviewed the invoice creation flow, and the "Order invoice creation is not allowed." error is expected system behavior.

This message is triggered when the following condition is met:

if (! $order->canInvoice()) { session()->flash('error', trans('admin::app.sales.invoices.create.creation-error')); return redirect()->back(); }

The canInvoice() method returns false in the following scenarios:

The order status is Closed or Fraud. All order items have already been fully invoiced. All remaining order items have been canceled, leaving no quantity available for invoicing.

In other words, the system prevents invoice creation when there is no invoiceable quantity remaining or when the order is no longer eligible for invoicing.

We also reviewed the sendInvoice() implementation currently being used. Since it follows the same validation flow and invokes canInvoice() before creating the invoice, this behavior is expected and is not caused by the custom implementation.

To determine the exact reason for the affected order, please verify the following:

The current order status (ensure it is not Closed or Fraud). The ordered, invoiced, and canceled quantities for each order item. Whether an invoice has already been created for the order.

Once these details are verified, the exact cause of the issue can be identified.

Thank you!

Best Regards,
Team Bagisto

@Chelsea said in Cutomer List View (override):

How can I overwrite the Blade view of the customer list to add a new custom column without touching the core view or copying it to my new package?

You're on the right track by trying to avoid copying the entire view. Bagisto provides an official extension mechanism for this, but the customer list is a special case, so here's the complete picture.

Using view_render_event hooks

Bagisto includes view_render_event hooks throughout the admin panel, allowing you to inject additional content into core views without modifying or copying them.

For the customer list (packages/Webkul/Admin/src/Resources/views/customers/index.blade.php), the available hooks are:

bagisto.admin.customers.customers.list.before bagisto.admin.customers.customers.list.after

You can register a listener in your package like this:

use Illuminate\Support\Facades\Event; public function boot() { Event::listen( 'bagisto.admin.customers.customers.list.before', function ($viewRenderEventManager) { $viewRenderEventManager->addTemplate('yourpackage::customers.extra'); } ); }

This injects your Blade template before the customer list without overriding the core view.

The limitation for adding a new column

The customer list differs from most Bagisto grids. Although it uses a DataGrid, the table itself is rendered using custom Vue slots (#header and #body) defined directly in the Blade view.

The available view_render_event hooks are only placed before and after the grid—they don't exist inside the table header or row templates. Because of this, you cannot inject an additional table column using only render events.

Step 1: Add the data (no view override required)

To make your custom field available in the grid, extend the CustomerDataGrid and bind your implementation in your package:

// Service Provider $this->app->bind( \Webkul\Admin\DataGrids\Customers\CustomerDataGrid::class, \YourPackage\DataGrids\CustomerDataGrid::class );

Then extend the DataGrid:

class CustomerDataGrid extends \Webkul\Admin\DataGrids\Customers\CustomerDataGrid { public function prepareQueryBuilder() { $queryBuilder = parent::prepareQueryBuilder(); $queryBuilder->addSelect('customers.your_field'); return $queryBuilder; } public function prepareColumns() { parent::prepareColumns(); $this->addColumn([ 'index' => 'your_field', 'label' => 'Your Column', 'type' => 'string', ]); } }

After this, your value is available on the frontend as record.your_field.

Note: For most Bagisto DataGrids, adding a column in the DataGrid class is enough—the UI renders it automatically. The customer grid is an exception because its table layout is manually defined using Vue slots.

Step 2: Display the column

Since the customer grid's row and header are hardcoded in the Blade template and there are no render hooks inside those slots, there isn't a supported way to inject a new <th> or <td> without overriding the view.

The recommended approach is to override only this single Blade file from your package by registering your package's views with higher priority. This keeps the core untouched while allowing you to add your custom column.

Alternatively, if you'd like to avoid maintaining an overridden view in the future, you could contribute a new view_render_event hook inside the customer grid to Bagisto, which would make this kind of customization possible without any view override.

Summary Inject content around the customer list: Use view_render_event hooks. Add custom data to the grid: Extend and rebind CustomerDataGrid. Add a new table column to the customer list: The current implementation requires overriding the customer list Blade view, as there are no extension hooks inside the custom Vue row/header templates.

So, while Bagisto provides clean extension points for many scenarios, adding a new in-row column to the customer list cannot currently be achieved without overriding that specific Blade view.

Thanks
Aviral

Hello
Since the same database works correctly on your local setup, the issue is most likely related to the live server environment rather than the Bagisto data itself.

Please check the following:

Open your browser's Developer Tools (F12) and inspect the Network and Console tabs while loading the checkout page. Check if the API request that fetches customer addresses is failing or returning an error.

Verify that the APP_URL in your .env file matches your live domain exactly, then run:

php artisan optimize:clear php artisan config:cache

Ensure that storage and bootstrap/cache have the correct write permissions.

Compare the PHP version and installed PHP extensions between your local and live environments. A mismatch can sometimes lead to unexpected behavior.

Check the Laravel logs (storage/logs/laravel.log) and your web server error logs for any exceptions generated when the checkout page is loaded.

This information will help determine whether the issue is caused by a failed API request, session/authentication problem, or a server configuration issue.

Thanks
Aviral

Hi,

Thanks for the detailed explanation! Here's what's going on, in plain terms.

What's happening

In Bagisto 2.3.6, the Brand filter is designed to show every option you created for that attribute all, ~150 brands, no matter which ones are actually used in the category you're viewing. So on both the Processor and Motherboard pages, you see the full brand list.

This is how Bagisto works out of the box. It's not a bug or a setting you missed, the filter simply doesn't check "which brands are actually used by products in this category" before showing the list.

Does Elasticsearch or Redis fix it?

No. I checked, and even with Elasticsearch running, Bagisto only uses it to speed up product search and price ranges. It does not narrow down the filter options to what's used in a category. So there's no toggle in the admin panel or in Redis/Elasticsearch that will turn this on.

What you can do

To get the behavior you want (Processor page shows only Intel + AMD, Motherboard page shows only MSI/ASUS/GIGABYTE), you needs to make a small customization. It's a well-understood change:

The category page currently asks for "all brands." The customization makes it instead ask for "only the brands used by products in this category."

It's a focused change to one part of the storefront code, and it doesn't require rebuilding your site or changing your data, just a small custom addition.

Thanks
Aviral

Customizing the Footer in Bagisto 2.4.1 (Default Theme)

File name & location

The footer is not controlled by a plain CSS file. Bagisto's default theme uses Tailwind CSS utility classes written directly in the Blade template.

The footer is not controlled by a plain CSS file. Bagisto's default theme uses Tailwind CSS utility classes
written directly in the Blade template.

packages/Webkul/Shop/src/Resources/views/components/layouts/footer/index.blade.php

The custom colors it references (lightOrange, navyBlue) are defined here:

packages/Webkul/Shop/tailwind.config.js

Changing the Background Color

The footer has two background areas:

a) The main footer area line 24 uses the class bg-lightOrange:

<footer class="mt-9 bg-lightOrange max-sm:mt-10">

b) The bottom copyright bar line 140 uses bg-[#F1EADF]:

<div class="flex justify-between bg-[#F1

To change them, either swap the classes inline (e.g. bg-lightOrange bg-[#1a1a1a]), or change the color value
centrally in tailwind.config.js:

// packages/Webkul/Shop/tailwind.config.js
colors: {
navyBlue: "#060C3B",
lightOrange: "#F6F2EB", // change this hex to recolor the whole footer
}

Text & Link Color Copyright text (line143): text-zinc-6e. Newsletter heading (line 96): text-navyBlue. Footer links (lines 42 & 76): they currently inherit the default text color there's no color class on the <a> tags. To recolor them, add a text-color class:

<a href="{{ $link['url'] }}" class="text
{{ $link['title'] }}
</a>

3.Two important notes

Rebuild assets after editing. Because th runtime CSS), you must recompile afterany change:

cd packages/Webkul/Shop
npm install # first time only
npm run build # or: npm run dev

If you add a brand-new arbitrary class like bg-[#123456], Tailwind will pick it up on the next build. Also clear the view cache: php artisan view:clear.

Don't edit the vendor package directly if you can avoid it changes inside packages/Webkul/... are overwritten
when you update Bagisto. The upgrade-safheme (Admin < Settings < Themes) or publish/override just this footer view into a custom theme folder, then edit the copy there.

Remember to run npm run build afterward.

Hello Gwenaelle,

Greetings!

Thank you for reaching out and for sharing your findings.

The @csrf token is already included in our shop form component located at:

packages/Webkul/Shop/src/Resources/views/components/form/index.blade.php

Therefore, there is no need to add @csrf manually on pages that use the <x-shop::form> component.

Could you please clear your browser cache and try again? If you still encounter the same 419 (CSRF Token Mismatch) error, kindly let us know. We'll investigate it further.

Thank you as well for your suggestion regarding the seller approval documentation. We appreciate your feedback and will consider improving the documentation to make this process easier to find.

Regards,
Kartikey Dubey
Team Bagisto

Hello Gwenaelle,
Greetings!

Thank you for reaching out and for sharing your findings.

We were able to identify this issue, and it has already been fixed in the latest version of the Marketplace package (v2.4.6).

If you continue to experience any problems after changes in database, please let us know. We'll be happy to assist you further.

Regards,
Kartikey Dubey
Team Bagisto

Hello,

Thanks for flagging this. You're right — the rating, status, and sort filters on GET /api/shop/products/{productId}/reviews were not being applied. This has been fixed in the latest release (v2.0.0) — the filters now work as documented.

Please update to the latest version of the package, and the filtered requests will return correctly. Let us know if you still see any discrepancy after upgrading.

Best regards,
Bagisto Support