Advanced Search

Hi,

Thank you for the detailed information and screenshot. We found the issue.

In version 6.4.0, we removed the pagination from the shipping methods listing page to fix a display issue with single-instance plugins. As a result, all shipping methods were loaded at once. With your Weights plugin instances, with thousands of rate entries, loading all their configuration data simultaneously was consuming too much memory and exceeding PHP memory limits.

We have restored the pagination on the shipping and payment methods listing pages. The single-instance plugins are now properly included in the paginated total and displayed at the end of the list so that the pagination can still work while taking them into account.

You can download the latest update from your member area and install it over your current version. After updating, the shipping methods listing should load normally again with pagination controls at the bottom of the page.

I am experiencing a critical issue with the "HikaShop Shipping Plugins - Weights" plugin. This is the only shipping method on my site, and it contains over 3,000 entries.

[Current Symptoms]

1. When navigating to "System > Shipping methods," the list becomes blank (grey) after the 32nd entry, and everything beyond that is invisible.
2. Since updating to HikaShop 6.4.0, this occurs immediately upon opening the page, regardless of display settings.
3. In previous versions, the screen would go blank if I selected the default maximum display of "200." Therefore, I had been using the "100" setting as a workaround.

[Error Log Found]
I found the following warning in my server logs:

PHP Warning: PHP Request Startup: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini.
PHP Warning: PHP Request Startup: Multipart body parts limit exceeded 1020. To increase the limit change max_multipart_body_parts in php.ini.

[Steps Taken]
I increased the limits in my php.ini as follows, and confirmed they are active via phpinfo(), but the issue persists:

1. max_input_vars = 10000
2. max_multipart_body_parts = 10000

(Note: My memory_limit is set to 2G)

Could you please provide a fix or a workaround for managing such a large volume of shipping data in version 6.4.0?

Hi,

Thank you for the report. Could you help us understand a bit more about the issue?

When you mention the "Weights" screen, could you tell us exactly which page in HikaShop you are on when this happens? For example:
- Is it the product listing page in the backend (Products > Products)?
- Is it a configuration page (System > Configuration)?
- Or is it a specific category or section you've named "Weights"?

Also, when you mention "display quantity to 200", do you mean you've set the number of items per page to 200 in the listing?

A white/blank screen typically indicates a PHP memory limit or execution time issue. With 200 items per page, the server may run out of memory before the page can fully render. You could try:
1. Reducing the items per page to 50 or 100 to see if that resolves the issue
2. Increasing the PHP memory limit in your server configuration (e.g., `memory_limit = 512M`)
3. Checking your server's PHP error log for any fatal errors that would explain the blank screen

If you can share a screenshot of the page where this happens (before it goes blank) and tell us where you click on it to trigger the issue, that would help us pinpoint the exact issue.

Hi,

We've just added OpenAI / ChatGPT Shopping support to the Google Products plugin. It will be available in the next HikaShop release, to be released in a few days.

The plugin can now generate a JSON product feed alongside the existing Google Shopping XML feed. Both feeds share the same product data, so enabling the JSON feed has minimal performance impact. When both are active and the cron runs, the product data is loaded only once and passed to both generators.

What's included in the JSON feed:
- Title, description, URL, images (main + up to 9 additional)
- Price, currency, and sale price when applicable
- Availability (in_stock, out_of_stock, preorder, backorder)
- Brand, MPN, GTIN, condition
- Product weight and dimensions
- Seller name, store country, target countries, return policy
- Review count and star rating (from HikaShop's built-in voting system)
- Variant support: each variant is exported as a separate entry with a group_id linking it to the parent product and a variant_dict containing the characteristic names and values (e.g. {"Color":"Red","Size":"M"})

All existing plugin settings (product categories, price options, variant handling, custom fields, skip field, etc.) apply equally to the JSON feed.

To set it up:
1. Open the Google Products plugin settings.
2. Fill in the "OpenAI JSON file path" field with a path like `media/com_hikashop/openai_feed.json`. This will make the feed accessible at ` yoursite.com/media/com_hikashop/openai_feed.json `.
3. Configure the additional OpenAI settings that appear: store country, target countries, return policy, search/checkout eligibility, and whether to include reviews.
4. The feed will be regenerated automatically each time the cron runs. You can also download it manually with the "Download OpenAI JSON" button.

With your 1,600 to 2,000 SKUs, the feed generation should work fine. If you experience memory or timeout issues, the existing "Increase performances" setting applies to both feeds.

No core file modifications are needed. Everything works through the existing plugin configuration.

You can find the full documentation here: www.hikashop.com/support/documentation/8...products.html#openai

Hi,

1. If you disable the HikaShop cart notification plugin, AND you don't have the HikaShop cart module displayed on the page, the system will automatically redirect to the checkout after an add to cart.
Alternatively, you can also configure the settings of the HikaShop cart notification plugin to redirect to the checkout on success. This approach is recommended to better handle error messages when a problem happens during the add to cart process (for example, if the product can't be added because of a limit rule).

2. In the Products>Limits menu, you can configure limits on purchases. So, for example, you can configure a limit rule to restrict the cart to a quantity of 1. When you do so, if a user tries to add a product to his cart and he already has a product in his cart, the add to cart will be refused and he will see an error message explaining that he can only have 1 product in his cart.

3. Now, what I said in point 2 is not exactly what you want.
To get that, you'll have to develop a small plugin. I would recommend implementing the event onBeforeCartLoad(&$cachedCart, &$options)
In it:
- Check the URL of the current page. If it's not an add to cart request, skip.
- Then, also use a static variable so that you only do your process once ( because after the product is add to the cart in the database, the cart in memory is cleared and reloaded, and you don't want to delete the product from it at that point ).
- Then, get the cart id from HikaShop:If the id returned is empty, skip.
- Finally, you can run a MySQL query on the hikashop_cart_product table to delete the entries where the cart_id is equal to what you have in $id. It is important to directly run a MySQL query with Joomla's functions, and not use the save process of class.cart to avoid a potential loop of the code.

That way, the add to cart process will go like that:
- the cart controller get the request
- the method addProduct of class.cart is called
- the current cart starts loading. If no cart, it is created in the database in the hikashop_cart table
- onBeforeCartLoad is called
- your plugin delete existing products already in the cart
- the cart loading process continues the loading of the cart by loading the products of the current cart if any
- the product being added, is actually added to the cart in the database

Your plugin should only have a dozen lines of code, so, if you're a developer, it should not be a problem. And in that case, you don't want to use the limits system in HikaShop.

Hello,

you are right, when i disable Serials, i get this error again:


Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/breisig.live/www/htdocs/libraries/src/Log/LogEntry.php on line 126

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/breisig.live/www/htdocs/libraries/vendor/symfony/error-handler/Error/OutOfMemoryError.php on line 1

So i will search for it on another way.

Hello,

Please disable the plugin "HikaSerials - HikaShop Integration plugin" in your Joomla backend.
Then, perform a new test in your checkout.

Regarding the error message, we have not information on which "elements" is using too much memory, but the issue occurs in the Log System, not in HikaShop or HikaSerial.
Nevertheless, increasing the memory limitation in your hosting could be a good solution.
Specially if you are trying to generate big images with the "attach serial" plugin ; that kind of processing need to load the entire image (uncompressed) in memory in order to modify it with the rest of the content.

Regards,

-- HikaShop version -- : 5.1.6
-- HikaSerial version -- : 5.0.0
-- Joomla version -- : 5.3.0
-- PHP version -- : 8.4.6
-- Browser(s) name and version -- : FF 138.0.4
-- Error-message(debug-mod must be tuned on) -- : Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/breisig.live/www/htdocs/libraries/src/Log/LogEntry.php on line 126

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/breisig.live/www/htdocs/libraries/vendor/symfony/error-handler/Error/OutOfMemoryError.php on line 1

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/breisig.live/www/htdocs/libraries/vendor/joomla/database/src/Monitor/DebugMonitor.php on line 77

Warning: PHP Request Shutdown: Cannot call session save handler in a recursive manner in Unknown on line 0

Hello,
i have currently big Problems after checkout: www.breisig.live/kasse/checkout/confirm

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/breisig.live/www/htdocs/libraries/src/Log/LogEntry.php on line 126

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/breisig.live/www/htdocs/libraries/vendor/symfony/error-handler/Error/OutOfMemoryError.php on line 1

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/breisig.live/www/htdocs/libraries/vendor/joomla/database/src/Monitor/DebugMonitor.php on line 77

Warning: PHP Request Shutdown: Cannot call session save handler in a recursive manner in Unknown on line 0

Can you please help me urgently ?
Thanks. Michael

Hi,

Seeing the number of results for the first filter (423) this can't be what is generating the problem. The mass action should only need a few dozen of MB maximum of memory, nowhere near the 1 GB limit.
So the error was generated by something else.
Do you have that error only once in the PHP error log ? Or several times ? What are the dates and times of the errors ? Recent ? Close or far appart in time ?

Do you have other mass actions ?
Could it be that someone regularly use the "export" button of the orders listing in the backend, without any filter and without selecting any order ? In that case, it would run a MySQL query loading all the data of all the orders at once, resulting in a similar issue.

It could also be a browser extension, or something between your browser and your server prefetching the export URL without you doing anything yourself :
- a CDN like cloudflare ( developers.cloudflare.com/speed/optimiza...ntent/prefetch-urls/ ) or keyCDN ( www.keycdn.com/support/prefetching ). Some potentially useful information regarding cloudFlare: serverfault.com/questions/1165854/503-re...h-requests-nginx-php
- a browser extension on your browser: chromewebstore.google.com/detail/quickli...ibilpmekhgkbeg?hl=en
- a setting of chrome on your computer: stackoverflow.com/questions/28020184/how...tch-in-google-chrome
- a prefetching joomla extension ( extensions.joomla.org/extension/page-speed-optimizer/ ) which would run in the backend while it shouldn't ( not saying this one does, but if you have an extension like that on your website, that's a thing to check ).

A good way to check if it comes from something triggering unwanted exports of orders is to add the line:
exit;
after the line:
function export(){
in the file administrator/components/com_hikashop/controllers/order.php
This way, the "export" button of the orders listing won't do anything on your website.
If you don't have the problem anymore after this change, then it would confirm that it comes from something triggering unwanted exports of orders on your website backend.

The database just stopped for a while again. It's difficult because I don't have all the data about the sql logs on the server.
This is all I have in joomla logs:
PHP ​​Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 56623120 bytes) in /public_html/administrator/components/com_hikashop/helpers/spreadsheet.php on line 192
PHP Warning: Undefined property: stdClass::$massaction_name in /public_html/plugins/actionlog/hikashop/hikashop.php on line 578
PHP Warning: Undefined property: stdClass::$massaction_name in /public_html/plugins/actionlog/hikashop/hikashop.php on line 589
PHP Warning: Undefined variable $customer_num_uses in /public_html/administrator/components/com_awocoupon/awocoupon/library/class-awocoupon-library-discount.php on line 5597

When checking database with query SHOW OPEN TABLES WHERE In_use > 0;
I get some lock tables.