USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?

Hello,

1.
Regarding the packing logic, where the 2x to 3.9x discrepancy almost certainly comes from, HikaShop does not have a "shipping box catalogue" concept. It does not know about your Small (1,440 cu in) or Medium (3,584 cu in) USPS boxes. What it does instead, for every quote request, is:
- Take each product's per-unit dimensions (length, width, height) and weight.
- For an order line of N units of one product, build a virtual package by stacking N units along the product's smallest dimension. So for example 6 units of a 4 x 6 x 10 in product become a single 24 x 6 x 10 in virtual package. The other two dimensions stay at the single-unit max.
- Split that into additional packages only when a hard USPS limit is reached (provided by the plugin): 70 lb total weight, or 130 in length + girth.

2.
HikaShop doesn't compute DIM weight on its side. It sends raw weight + length/width/height to USPS, and USPS applies its own DIM weight rule on their end.

3.
There is no built-in way to map "Product X => Small Box" or "Product Y => Medium Box". The dimensions sent to USPS come from the product record, not from a box library. The two workarounds we suggest to merchants in your situation are:
- Set each product's dimensions to the dimensions of the shipping box that will actually be used for one unit of that product (so a soap that goes in a 6 x 6 x 4 mailer should be configured as 6 x 6 x 4, not as the bar itself). HikaShop's stacking logic for multi-unit orders then approximates a stack of those boxes, which is usually closer to the truth than stacking the bare products.
- Use a "Group packages" toggle on the plugin (setting "Group packages") and the per-API "Packaging weight" settings (Letters / Flats / Packages) to add the empty-box weight on top, so the rated weight matches what you actually put on the scale.
The "Group packages" option is enabled by default; when disabled, each unit is rated as its own package, which would absolutely explain a 2x+ overquote on multi-unit orders. Worth a quick check that it is on for your configuration.

A few other usual suspects for 2x+ over-quotes on Ground Advantage:

- "Price type" in the plugin settings: should be Commercial in your case (you mentioned you use Click-N-Ship Commercial Plus). Retail would be substantially higher.
- "Weight approximation" and "Dimension approximation" inputs in the plugin: any non-zero value here is added on top of every package's weight / smallest-dim and can quietly inflate the rated package.
- "Has nonstandard characteristics" toggle: if on, USPS adds a nonstandard surcharge that you probably do not pay on your own labels.

To investigate your specific 2x to 3.9x gap, what would help us most is one concrete order from your data:
- The list of products in the cart, each with their HikaShop product dimensions (L x W x H, units) and weight (units) as stored in the backend, and the quantity ordered.
- The shipping destination ZIP code.
- The rate HikaShop quoted at checkout, and the rate Click-N-Ship actually charged you on the label.
- A screenshot of the USPS plugin's settings page, especially the Price type, Services, Group packages, the approximation fields, and the packaging weight fields.

4.
Yes, the plugin we released last year at www.hikashop.com/marketplace/product/290-usps.html uses the new API.

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,

There is no such step or setting because this is not supposed to happen and it doesn't happen for anyone else when updating their HikaShop.
What's likely is that you have a problem with the hikashop_config table which leads to the update system behaving in an unexpected manner.
Try clicking on the "Check database" button on the configuration page of HikaShop. Does it says anything about the hikashop_config table ?

Hi,

The hikashop_config table is supposed to have a primary key on the config_namekey column, so there is only one entry per setting. The update system relies on that primary key: if an entry already exists for a setting it leaves it alone, otherwise it adds it. On your database that primary key is missing, so each update keeps adding a new (default) row for settings that already exist. When HikaShop reads the table, the last row returned by MySQL wins, which is the newly added default one, and your real settings look wiped out.

So the fix is to remove the duplicate rows (keeping one per setting) and let "Check database" put the primary key back. Rather than deleting them one namekey at a time, you can clean the whole table at once.

1. First make a backup: in phpMyAdmin, select the hikashop_config table and use Export, so you have a copy if anything goes wrong.

2. Then open the SQL tab and run this (replace PREFIX_ with your table prefix, the part before hikashop_config that you see in phpMyAdmin):

ALTER TABLE PREFIX_hikashop_config ADD COLUMN tmp_id INT AUTO_INCREMENT PRIMARY KEY;

DELETE c1 FROM PREFIX_hikashop_config c1
JOIN PREFIX_hikashop_config c2
ON c1.config_namekey = c2.config_namekey AND c1.tmp_id > c2.tmp_id;

ALTER TABLE PREFIX_hikashop_config DROP PRIMARY KEY, DROP COLUMN tmp_id;

What it does: it temporarily numbers the rows in the order they were added, deletes every duplicate while keeping the oldest one of each setting (your original value, not the default that was re-added), then removes that temporary column. It does this for every setting at once, not only cart_retaining_period_checked.

3. Click the "Check database" button again. With the duplicates gone, it will be able to add the missing primary key to hikashop_config, and the problem won't come back on the next updates.

4. Finally, go through your HikaShop configuration page settings and re-save anything that still looks wrong; now that there is a single entry per setting, the saved value sticks.

If "Check database" then reports the same kind of duplicate-key error on another table, the same approach works on that table by changing the table name (and the column it complains about).

The action_button_type error is probably linked to this and I hope the steps above will also take care of this.

Hi,

Thank you, that is an excellent write-up, and it lets me answer precisely. The short version is that everything you saw traces back to the missing primary key, and your P.S. plan is the right one.

1. Config values being reset by the update

The update installer is not overwriting your settings on purpose. HikaShop saves the configuration with a single REPLACE INTO query on the hikashop_config table, and REPLACE relies on the primary key on config_namekey to decide whether to update the existing row or insert a new one. When HikaShop reads the configuration back, it indexes the rows by config_namekey and, if a key appears more than once, the last row returned by MySQL wins.

With the primary key missing, REPLACE had nothing to match on, so it behaved like a plain INSERT: every save and every update appended a brand new row, including the default values written during the update. On the next read, the newest row (the default) won. That is the single cause of both the 35,162 duplicate rows and the settings looking wiped (USD to EUR, address, tax zone) after each update.

So you do not need to re-enter the values after every update. Once the primary key is back in place, REPLACE updates the one existing row per setting, and the values stick across updates. The resets you observed happened during the update you ran before the key was added, which is expected. The clean way to confirm the fix is exactly your P.S. plan (see the end).

2. "Call to a member function loadArray() on null" on every shipping plugin

This is not normal 6.5.0 behaviour: a clean update does not produce it, otherwise everyone would hit it. loadArray() is not called anywhere in HikaShop's own code, so this fatal is Joomla calling loadArray() on an object that is null while opening the plugin edit screen. That points at a missing schema element or an incomplete plugin extension record (null params / empty manifest_cache), which fits an update that could not finish cleanly on a database that was as damaged as yours was.

Three steps, in order:

a) Get the exact location. In Joomla, Global Configuration > Server > Error Reporting, set it to Maximum (or Development) and activate the Debug system setting, reproduce the error, and you will get the file, line and full stack trace instead of the one-line message. Send me that trace, it will tell us exactly which object is null and where the problem comes from.

b) Run "Check database" on the HikaShop configuration page after the update. It creates or repairs any missing tables, columns and keys for 6.5.0, the same mechanism that puts the config primary key back. On a database in your state, the update's own schema step may not have completed, and Check database finishes it.

c) If it still fails, reinstall the 6.5.0 package over the existing install (Joomla > Install Extensions, upload the same HikaShop package again). That re-runs the install routine, recreates any missing schema and refreshes the plugin manifests, without deleting your data. This usually clears half-applied-update states like this one.

3. The usps2 plugin not being updated with the core

usps2 is a separate plugin from the marketplace and updates on its own schedule, independent of the HikaShop core version, so it not moving when the core updated is normal. Your 1.5.6 is current, so you are not behind. After updating the core you can still go to the Updates area and install the latest usps2 if one is offered, as good hygiene. But it is very unlikely to be the cause of the admin error here, because that error hits every shipping plugin, not just usps2, so it is the shipping admin / install state rather than usps2 itself.

P.S. Your re-clone plan is exactly right, and I would do it that way:

1. Re-clone the live site (keep the backup).
2. On the clone, de-duplicate hikashop_config and add the primary key FIRST, before updating anything.
3. Then update HikaShop.
4. Run "Check database".
5. Then update usps2 to the latest.
6. Verify the shipping plugin edit pages open and that your settings (currency, address, tax zone) survived the update.

Doing the primary key fix before the update means REPLACE INTO works correctly throughout the update, so the settings will not be duplicated or reset, and step 6 directly answers your open question of whether the key fix prevents the resets. Once the clone passes, apply the same sequence to the live site (backup, de-dupe + primary key, update, Check database, update usps2).