Advanced Search

Follow-up: Clone test results — config table fix + 6.x update

Following the guidance in this thread, I ran a full test on a subdirectory clone before touching the live site. Here is a detailed summary of what was done and the current state.

---

Starting state of the clone

• HikaShop version: Business 6.1.0
• Joomla version: 4.4.14
• PHP: ea-php82, max_execution_time: 300, memory_limit: 256M
• Database: separate clone DB (same table prefix: ajx70_)
• Active shipping plugin: HikaShop USPS 2 Shipping (usps2, v1.5.6, purchased Feb 2026, extension_id: 10856)
• Old built-in USPS plugin (usps, extension_id: 10093): present but disabled

---

Note on sequence: The HikaShop update was actually applied before the SQL fix below. The SQL cleanup and PRIMARY KEY addition were performed on an already-updated database. This means we have not yet tested whether the primary key fix prevents config resets during the update — that would require a fresh clone test with the fix applied first.

---

Step 1 — Diagnosed and fixed the hikashop_config duplicate row problem

Per the suggestion in this thread, I ran a query to check for duplicates:

This returned 35,162+ duplicate rows across many config keys. The root cause was a missing PRIMARY KEY on the config_namekey column, which allowed every HikaShop update to insert new default rows without removing the old ones. MySQL was returning the newest (default) row, making settings appear wiped after each update.

Fix applied (3-step SQL):

After running these 3 steps, a re-check still found 2 remaining duplicates:

These were cleaned with a targeted DELETE, then the primary key was added directly via SQL (bypassing Check Database):

This succeeded. A final run of HikaShop → System → Check Database returned all green — no errors.

---

Step 2 — HikaShop update (applied before the SQL fix)

The HikaShop update was installed via Joomla Extension Manager on the clone. The SQL fix in Step 1 was applied afterward to the already-updated database.

Manifest cache for the bundled USPS plugin after update:
Config values immediately after update:

• Currency: reset from USD to EUR
• Store address: cleared (was 3076 C Road, Palmdale CO 81526)
• Tax zone: reset to Europe
• Image thumbnail dimensions: 200px → 100px
• Product image links: preserved (improvement over a previous test)

Note: since the update ran before the SQL fix, we cannot conclude from this test whether the primary key fix would have prevented the config reset. A fresh clone test — with the primary key added before running the update — would be needed to answer that. What we can say is that the update installer is writing default values that overwrite existing settings.

---

Step 3 — Shipping plugin status after update

When attempting to open any shipping plugin in the HikaShop backend (not just USPS — all of them), I receive:

I queried the extensions table to check plugin state:

Results:

• extension_id 10093 | HikaShop USPS shipping plugin | usps | disabled | version 6.5.0 (updated with HikaShop)
• extension_id 10856 | HikaShop USPS 2 Shipping | usps2 | enabled | version 1.5.6 (not updated — marketplace plugin)

The shipping record in ajx70_hikashop_shipping is intact (record exists, params present, published: 1). The error is not caused by a missing record.

Since the error occurs on all shipping plugins, not just usps2, this points to a problem in the shared HikaShop shipping admin view or a missing/changed database schema element introduced in the update — not a usps2 compatibility issue specifically.

---

Current state summary

• hikashop_config PRIMARY KEY: fixed and in place
• Check Database: all green
• Config reset after update (currency/address/tax): still occurring
• All shipping plugin edit pages: broken (loadArray() on null)
• Live site: untouched — still on 6.1.0

---

Questions

1. The config reset (USD→EUR, address cleared, tax zone) is still happening after the primary key fix. Is the update installer writing default values unconditionally, overwriting existing settings? Is there a way to prevent this, or is the correct approach to simply re-enter values manually after each update?
2. All shipping plugin edit pages return "Call to a member function loadArray() on null" after the update. Is this a known issue with 6.5.0? Is there a schema migration step that needs to be run, or a table/column that the shipping admin view now requires that may not have been created during the update?
3. The usps2 marketplace plugin (v1.5.6, purchased Feb 2026) was not updated alongside HikaShop. Is there a newer version of usps2 that should be installed after updating HikaShop, and could the missing update be contributing to the shipping admin error?

Thank you.

P.S.
As I worked on a clone of the live website, I can Clone it again, then apply the SQL and after that update both Hikashop and the USPS plugin. Do you think that may produce better results?

I have edited the USPS plugin according to your guidelines. I am about to test it, but in the meantime I also tried a final upgrade of Hikashop pro on a clone of the website.

Update on the upgrade question:
I tested the 6.1.0 → 6.4.1 update on a cloned subdirectory with the following PHP settings (screenshot attached):

• max_execution_time: 300
• max_input_time: 300
• memory_limit: 256M
• PHP version: ea-php82

PHP Configuration


The installation wizard did not appear this time, which is progress (I attached the one that appeared the first time around for reference).


However, the same configuration fields were reset:

• Currency: reverted to EUR (was USD)
• Store address: cleared
• Tax zone: reverted to Europe
• Image thumbnail dimensions: reset to 100px (were 200px)

Image file links were preserved — products still show their images, which is an improvement over previous attempts.
Since the wizard did not run, the reset appears to be coming from the update process itself reinserting default values into the hikashop_config table, rather than from the wizard overwriting it. Is that correct? Is there a specific step or setting that controls whether the update rewrites config table defaults, and is there a way to prevent it?
Screenshots of before/after configuration attached.

Front End Comparison (Before > After)


Configuration Fields reset (before > After)

Thank you for the very detailed example. It actually points straight at the cause, and it is not the packing or dimensional weight.

On the dimensional weight edge case first, so it is out of the way: for Ground Advantage, USPS only applies dimensional weight to parcels that measure more than one cubic foot (more than 1,728 cubic inches), and only for zones 5 to 9. Your case is exactly 1,728 ci, which is the threshold, not above it, so dimensional weight does not trigger at all here. The package is rated on its actual 8.64 lb. So DIM weight is not what is inflating your quote.

The real cause is the price tier the plugin is asking USPS for. The new plugin has a "Price type" setting with three values: Retail, Commercial and Contract. You have it set to Commercial, so the USPS API returns the published Commercial Base price. The rate you actually pay through Click-N-Ship Business (your Business Rate Card) is not the published Commercial price, it is account specific negotiated pricing, which USPS exposes through the API only under the Contract price type, and only when you identify your account.

So the fix to try is:

- In the USPS plugin settings, set "Price type" to Contract.
- Fill in "Account type" with the type that matches your USPS account (EPS, PERMIT or METER, EPS being the usual one for a Click-N-Ship / online account).
- Fill in "Account number" with your USPS account number.

With those set, the plugin sends your account details to USPS and the API returns your account's contract pricing instead of the generic Commercial price. That is what should bring the quotes down to what you actually pay on the label. If your Business Rate Card is tied to that account, Contract is the price type that surfaces it.

To verify exactly what each price type returns for a given order, enable Debug mode in the plugin and place a test order through checkout. The payment log file in the HikaShop configuration page will show the request sent to USPS and the prices returned, so you can compare Commercial vs Contract side by side for the same parcel.

On your example numbers, a $25.24 Commercial quote versus $10.74 Business Rate Card is exactly the kind of gap you would expect between published Commercial and account contract pricing, so this is very likely the whole story.

On your second question about upgrading:

The breakage you described from the previous update (product images unlinking, currency reset from USD to EUR, default shipping address deleted) is not normal HikaShop update behaviour. A standard update does not touch your currency configuration, your stored product image assignments, or your addresses. There is no code in HikaShop's update mechanism (even updating from really old versions) in order to trigger what you describe. So it is most likely specific to how that one update ran on your server, not an expected behaviour of a given version jump. From what you're saying, I would say that the hikashop_config table in the database got emptied and default data got put in afterwards.

Your plan to test 6.1.0 to 6.4.1 on a cloned subdirectory first is exactly the right approach. A few points for the clone:

- A full file backup plus a full database dump is the authoritative backup. There is no separate export needed to protect image assignments or config values: the image assignments live in the database (the hikashop_file table) and the configuration lives in the hikashop_config table, so a complete database dump already captures both. The Products CSV export is not the right tool for that and is not needed for the backup.
- Run the update in one clean pass: put the site offline, make sure PHP max_execution_time and memory_limit are generous, and let the update finish without interruption.
- After updating the clone, check the configuration page (currency, default addresses) and a few products with images before touching the live site.

If the clone update completes cleanly and your config and images are intact, the live update should behave the same way.

Hi,

3600*~10 variants is only less than 50 000 entries in the hikashop_product.
That's not what is eating your database memory. It shouldn't take more than a few MB. Normally, variants don't have a description and just use the description of their main product, and the description is the main thing eating the memory for a product entry.

The first thing to do is to open your PHPMyAdmin and check the number of entries for each table in the database and the size of each table. I would wager the problem is elsewhere, in another table.
For example, if you've been running HikaShop for years with the Email history plugin activated without a "number of days" set in its settings, the email log table in the database has been steadily growing without any cleanup of its data. The emails take quite a bit of space individually, so if you have hundreds of thousands of them, that could take a significant share of the pie.
It's been a while now that this setting has been added with it's default set to 30 days. But if you updated from an old version, it's possible that you still have that setting empty.

But it could be something else entirely. I'm just talking about the email history because that's something that happened to someone else in the past. Anyways, what to do next depends on what you find in the database.

-- HikaShop version -- : 6.4,1
-- Joomla version -- : 5.4.5
-- PHP version -- : 8.2.30

My client's shop has been running for years now and the amount of products in HikaShop has grown steadily all that time. Right now the shop contains about 3600 products, many of which have 5 to 15 variants. Because of this my database is becoming quite large (currently around 1.2 GB), and this is starting to give memory issues on my server when doing things like product exports or generating a site map.
I have already asked the client to go though their products and delete any that are no longer needed, but this does not really fix the issue.
So my question is: are old products entries removed from the Hikashop database tables when they are deleted from the administrator console? And, if this is not the case, is there a way to clean up the product database, by removing any data that is no longer relevant?

screenshots
stack trace:
OutOfMemoryError

Symfony\Component\ErrorHandler\Error\OutOfMemoryError:
Error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 23072768 bytes)

at /var/www/ubuntushopbiz/administrator/components/com_hikashop/classes/cart.php:3135

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.