@Rishabh-Webkul A mi me pasa lo mismo y no se ya como resolverlo, A mi me arroja un Forbidden. Tengo bagisto en Hostinger. Si pudieras ayudarme te lo agradeceria

Hello @bob

I think aapenal has Cpanel .

Then you can use Softaculous to install Bagisto.

Warm Regards
Team Bagisto

@rishabh-webkul19 Hello Rishabh

When we move to checkout and go to razpayr to payment then we see "amount must be in integer error" on final payment page. check screenshot i added.

Can you help me to solve this, can you tell me where to change what t change

https://github.com/vfixtechnology/bagisto-razorpay

This Razorpay extension has been copied by this person from our old original Bagisto Razorpay extension. All our function names and comments are also present in their code. Please be advised — do not use this repository. We recently came to know about this from our user.

@danieldino said in Problem with tax:

I have a shop, with 3 languages,
I have 3 tax rates
Poland 23%, Hungary 27%, Germany 19%
if I switch to the website, it calculates the tax incorrectly or it does not actually calculate the tax,
please help

Its like your shop’s tax configuration isn’t matching the language or region settings. Make sure each country’s tax rule is linked to the correct store view or customer location. Also check that “tax based on customer shipping/billing address” is enabled in your store settings to calculate correctly per region.

@Sul Okay, so this is where you are looking to move your 16,000 products, right? https://azmalenjaz.com/store/public/

May I where do you have the current data of products, in excel file or somewhere else?

Hello @alshaboty

For this, you need to enable the payment method from the Bagisto admin panel

Go to Configure -> Sales - Payment Method

and enable the status of the payment method that you want to show on a checkout page onthe frontend.

Image for your reference

ss2.png

Regards
Team Bagisto

Hello @Hossam

Kindly check inside the console or network is there any error are visible ?

Also you can run the command in the root of bagisto and let us know if the issue gets resolved or not

php artisan storage:link

and if possible let us know the APP_URL with a screenshot which is present in the .env file of bagisto

Regards
Team Bagisto

Hello @rawainv

Kindly check the complete guide with all the detailed explation of how category will work and how it will gets visible on the storefront.

Link: https://docs.bagisto.com/category/create-category.html

Regards

@webepic Gracias men eres el mejor, estuve mucho tiempo tratando de arreglar ese problema, gracias...

Hello @zeeshsoft

Kindly let us know the current Bagisto version you are using. This will help us identify the issue. Also, please provide images/screenshots of the issue for reference.

Regards

Hello @huynp139

Okay Great..!!

Regards

This happens because Bagisto expects a default channel before most services boot. Easiest fix is to run the initial migration and seed in isolation by temporarily disabling the API package or commenting the channel call in Core.php, then run php artisan migrate --seed to recreate the default channel, and restore the code after.

Hello @Zeryab

We have already raised this issue. You can track and review it through the following link, and also share your observations there:

https://github.com/bagisto/bagisto/issues/11294

Regards

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

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 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

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

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

@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.