[Skip to main content](#vessel-content)
# Profile for conticreative
##
[](/forum/user/12955-conticreative "View conticreative's Profile")
**[ Offline](/forum/user/12955-conticreative)**
- **User Type:** User
- **Register Date:** 17 Jan 2013
- **Last login:** 3 weeks 2 days ago
- **Time Zone:** UTC +0:00
- **Local Time:** 08:04
- **Posts:** 214
- **Profile views:** 349
- **Thank you received:** 7
- **Gender:** Unknown
- **Birthdate:** Unknown
- **Medals:** Hikashop Business
- Posts
# conticreative's recent posts (214 messages )
All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year
| [ ](#forumbottom) | Subject | Replies / Views | Last Post | [ ](#forumtop) |
|---|---|---|---|---|
| [](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372209) | [USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372209 "-- url of the page with the problem -- : pearblossomfarms.com/products -- HikaShop version -- : 6.4.1 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.2 -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : n/a I'm seeing a systematic overquoting problem where the USPS plugin quotes customers roughly 2× what the shipper actually pays via Click-N-Ship (Business Rate Card / Commercial pricing), for the same USPS Ground Advantage service. USPS Plugin Setup: * Origin ZIP: 81326 (Durango, CO area) * Service selected in plugin: USPS Ground Advantage only * Price Type: Commercial * Group Packages: Yes * Packaging weight: 0 oz, Weight approximation: 0% * Product dimensions entered per unit (e.g., a single jar: 4" × 3" × 3", 1.02 lb) The problem — likely dimensional weight: Product dimensions are entered per individual unit in HikaShop. For a multi-unit order (e.g., 12 jars), I believe the plugin packs N items using those per-unit dimensions and selects the smallest box from the configured box list that fits them. Our box sizes: * Small: 12" × 10" × 12" (1,440 ci) — used for orders under 11 lbs * Medium: 16" × 14" × 16" (3,584 ci) — used for orders 11–32 lbs The USPS dimensional weight threshold is 1,728 cubic inches (volume ÷ 166 = billed weight). Our Small box (1,440 ci) stays under the threshold — no dimensional weight, billed at actual weight. Our Medium box (3,584 ci) is well above it — dimensional weight = 3,584 ÷ 166 = 21.6 lb billed weight, even if the actual package weighs only 8–9 lbs. Cross-referenced with real shipment data: I exported 60 days of Click-N-Ship history (37 labels, all USPS Ground Advantage). Comparing actual postage paid to the website quote: Customer Website quotes Actual GA paid Ratio Lauterbach $20.28 $12.39 1.64× Drake $35.37 $14.09 2.51× Hummel $33.10 $8.48 3.90× Kolb $25.24 $10.74 2.35× Steakley $16.81 $13.83 1.22× The "close" orders (ratio ~1.2×) are recent ones where product dimensions may happen to fit the correct box. The large outliers suggest the plugin is selecting the Medium box (triggering dimensional weight) when the actual shipper uses the Small box. My questions: * How does the plugin calculate which box to select for a multi-unit order? Does it sum per-unit volumes and find the smallest fitting box, or use a different algorithm? * Does the plugin compute and send a dimensional weight to the USPS API when the selected box exceeds 1,728 ci? Or does it always send actual weight? * Is there a way to set a fixed box size per product (rather than having the plugin compute from per-unit dimensions) so it always requests the rate for the box the shipper actually uses? * Is the plugin currently using the new USPS API? I saw a March 2025 forum thread where Nicolas mentioned a new plugin was being developed to replace the old Web Tools API (retired January 25, 2026). We're now in May 2026 — is there an updated plugin I should install? Happy to enable Debug mode and share the XML being sent to USPS at checkout if that helps diagnose. Thank you. (Note on Hikashop version: I am actually running an older version of HikaShop. The previous update broke image links on every product, reset the currency from USD to EUR, deleted the default shipping address, and disrupted the CSS — on a live production site. I have not been able to safely update since. I am testing the 6.4.1 update on a cloned subdirectory before applying it to the live site. I listed 6.4.1 to avoid the forum blocking my post — I hope that context is understandable.)") Category: [Shipping Methods](/forum/28-shipping-methods "Discussions about the different shipping methods for Hikashop") Topic started 5 months 2 weeks ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") 4 months 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:10 Views:410 | [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 4 months 3 weeks ago |
| [](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372206) | [USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372206 "-- url of the page with the problem -- : pearblossomfarms.com/products -- HikaShop version -- : 6.4.1 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.2 -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : n/a I'm seeing a systematic overquoting problem where the USPS plugin quotes customers roughly 2× what the shipper actually pays via Click-N-Ship (Business Rate Card / Commercial pricing), for the same USPS Ground Advantage service. USPS Plugin Setup: * Origin ZIP: 81326 (Durango, CO area) * Service selected in plugin: USPS Ground Advantage only * Price Type: Commercial * Group Packages: Yes * Packaging weight: 0 oz, Weight approximation: 0% * Product dimensions entered per unit (e.g., a single jar: 4" × 3" × 3", 1.02 lb) The problem — likely dimensional weight: Product dimensions are entered per individual unit in HikaShop. For a multi-unit order (e.g., 12 jars), I believe the plugin packs N items using those per-unit dimensions and selects the smallest box from the configured box list that fits them. Our box sizes: * Small: 12" × 10" × 12" (1,440 ci) — used for orders under 11 lbs * Medium: 16" × 14" × 16" (3,584 ci) — used for orders 11–32 lbs The USPS dimensional weight threshold is 1,728 cubic inches (volume ÷ 166 = billed weight). Our Small box (1,440 ci) stays under the threshold — no dimensional weight, billed at actual weight. Our Medium box (3,584 ci) is well above it — dimensional weight = 3,584 ÷ 166 = 21.6 lb billed weight, even if the actual package weighs only 8–9 lbs. Cross-referenced with real shipment data: I exported 60 days of Click-N-Ship history (37 labels, all USPS Ground Advantage). Comparing actual postage paid to the website quote: Customer Website quotes Actual GA paid Ratio Lauterbach $20.28 $12.39 1.64× Drake $35.37 $14.09 2.51× Hummel $33.10 $8.48 3.90× Kolb $25.24 $10.74 2.35× Steakley $16.81 $13.83 1.22× The "close" orders (ratio ~1.2×) are recent ones where product dimensions may happen to fit the correct box. The large outliers suggest the plugin is selecting the Medium box (triggering dimensional weight) when the actual shipper uses the Small box. My questions: * How does the plugin calculate which box to select for a multi-unit order? Does it sum per-unit volumes and find the smallest fitting box, or use a different algorithm? * Does the plugin compute and send a dimensional weight to the USPS API when the selected box exceeds 1,728 ci? Or does it always send actual weight? * Is there a way to set a fixed box size per product (rather than having the plugin compute from per-unit dimensions) so it always requests the rate for the box the shipper actually uses? * Is the plugin currently using the new USPS API? I saw a March 2025 forum thread where Nicolas mentioned a new plugin was being developed to replace the old Web Tools API (retired January 25, 2026). We're now in May 2026 — is there an updated plugin I should install? Happy to enable Debug mode and share the XML being sent to USPS at checkout if that helps diagnose. Thank you. (Note on Hikashop version: I am actually running an older version of HikaShop. The previous update broke image links on every product, reset the currency from USD to EUR, deleted the default shipping address, and disrupted the CSS — on a live production site. I have not been able to safely update since. I am testing the 6.4.1 update on a cloned subdirectory before applying it to the live site. I listed 6.4.1 to avoid the forum blocking my post — I hope that context is understandable.)") Category: [Shipping Methods](/forum/28-shipping-methods "Discussions about the different shipping methods for Hikashop") Topic started 5 months 2 weeks ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") 4 months 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:10 Views:410 | [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 4 months 3 weeks ago |
| [](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372145) | [USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372145 "-- url of the page with the problem -- : pearblossomfarms.com/products -- HikaShop version -- : 6.4.1 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.2 -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : n/a I'm seeing a systematic overquoting problem where the USPS plugin quotes customers roughly 2× what the shipper actually pays via Click-N-Ship (Business Rate Card / Commercial pricing), for the same USPS Ground Advantage service. USPS Plugin Setup: * Origin ZIP: 81326 (Durango, CO area) * Service selected in plugin: USPS Ground Advantage only * Price Type: Commercial * Group Packages: Yes * Packaging weight: 0 oz, Weight approximation: 0% * Product dimensions entered per unit (e.g., a single jar: 4" × 3" × 3", 1.02 lb) The problem — likely dimensional weight: Product dimensions are entered per individual unit in HikaShop. For a multi-unit order (e.g., 12 jars), I believe the plugin packs N items using those per-unit dimensions and selects the smallest box from the configured box list that fits them. Our box sizes: * Small: 12" × 10" × 12" (1,440 ci) — used for orders under 11 lbs * Medium: 16" × 14" × 16" (3,584 ci) — used for orders 11–32 lbs The USPS dimensional weight threshold is 1,728 cubic inches (volume ÷ 166 = billed weight). Our Small box (1,440 ci) stays under the threshold — no dimensional weight, billed at actual weight. Our Medium box (3,584 ci) is well above it — dimensional weight = 3,584 ÷ 166 = 21.6 lb billed weight, even if the actual package weighs only 8–9 lbs. Cross-referenced with real shipment data: I exported 60 days of Click-N-Ship history (37 labels, all USPS Ground Advantage). Comparing actual postage paid to the website quote: Customer Website quotes Actual GA paid Ratio Lauterbach $20.28 $12.39 1.64× Drake $35.37 $14.09 2.51× Hummel $33.10 $8.48 3.90× Kolb $25.24 $10.74 2.35× Steakley $16.81 $13.83 1.22× The "close" orders (ratio ~1.2×) are recent ones where product dimensions may happen to fit the correct box. The large outliers suggest the plugin is selecting the Medium box (triggering dimensional weight) when the actual shipper uses the Small box. My questions: * How does the plugin calculate which box to select for a multi-unit order? Does it sum per-unit volumes and find the smallest fitting box, or use a different algorithm? * Does the plugin compute and send a dimensional weight to the USPS API when the selected box exceeds 1,728 ci? Or does it always send actual weight? * Is there a way to set a fixed box size per product (rather than having the plugin compute from per-unit dimensions) so it always requests the rate for the box the shipper actually uses? * Is the plugin currently using the new USPS API? I saw a March 2025 forum thread where Nicolas mentioned a new plugin was being developed to replace the old Web Tools API (retired January 25, 2026). We're now in May 2026 — is there an updated plugin I should install? Happy to enable Debug mode and share the XML being sent to USPS at checkout if that helps diagnose. Thank you. (Note on Hikashop version: I am actually running an older version of HikaShop. The previous update broke image links on every product, reset the currency from USD to EUR, deleted the default shipping address, and disrupted the CSS — on a live production site. I have not been able to safely update since. I am testing the 6.4.1 update on a cloned subdirectory before applying it to the live site. I listed 6.4.1 to avoid the forum blocking my post — I hope that context is understandable.)") Category: [Shipping Methods](/forum/28-shipping-methods "Discussions about the different shipping methods for Hikashop") Topic started 5 months 2 weeks ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") 4 months 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:10 Views:410 | [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 4 months 3 weeks ago |
| [](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372123) | [USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372123 "-- url of the page with the problem -- : pearblossomfarms.com/products -- HikaShop version -- : 6.4.1 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.2 -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : n/a I'm seeing a systematic overquoting problem where the USPS plugin quotes customers roughly 2× what the shipper actually pays via Click-N-Ship (Business Rate Card / Commercial pricing), for the same USPS Ground Advantage service. USPS Plugin Setup: * Origin ZIP: 81326 (Durango, CO area) * Service selected in plugin: USPS Ground Advantage only * Price Type: Commercial * Group Packages: Yes * Packaging weight: 0 oz, Weight approximation: 0% * Product dimensions entered per unit (e.g., a single jar: 4" × 3" × 3", 1.02 lb) The problem — likely dimensional weight: Product dimensions are entered per individual unit in HikaShop. For a multi-unit order (e.g., 12 jars), I believe the plugin packs N items using those per-unit dimensions and selects the smallest box from the configured box list that fits them. Our box sizes: * Small: 12" × 10" × 12" (1,440 ci) — used for orders under 11 lbs * Medium: 16" × 14" × 16" (3,584 ci) — used for orders 11–32 lbs The USPS dimensional weight threshold is 1,728 cubic inches (volume ÷ 166 = billed weight). Our Small box (1,440 ci) stays under the threshold — no dimensional weight, billed at actual weight. Our Medium box (3,584 ci) is well above it — dimensional weight = 3,584 ÷ 166 = 21.6 lb billed weight, even if the actual package weighs only 8–9 lbs. Cross-referenced with real shipment data: I exported 60 days of Click-N-Ship history (37 labels, all USPS Ground Advantage). Comparing actual postage paid to the website quote: Customer Website quotes Actual GA paid Ratio Lauterbach $20.28 $12.39 1.64× Drake $35.37 $14.09 2.51× Hummel $33.10 $8.48 3.90× Kolb $25.24 $10.74 2.35× Steakley $16.81 $13.83 1.22× The "close" orders (ratio ~1.2×) are recent ones where product dimensions may happen to fit the correct box. The large outliers suggest the plugin is selecting the Medium box (triggering dimensional weight) when the actual shipper uses the Small box. My questions: * How does the plugin calculate which box to select for a multi-unit order? Does it sum per-unit volumes and find the smallest fitting box, or use a different algorithm? * Does the plugin compute and send a dimensional weight to the USPS API when the selected box exceeds 1,728 ci? Or does it always send actual weight? * Is there a way to set a fixed box size per product (rather than having the plugin compute from per-unit dimensions) so it always requests the rate for the box the shipper actually uses? * Is the plugin currently using the new USPS API? I saw a March 2025 forum thread where Nicolas mentioned a new plugin was being developed to replace the old Web Tools API (retired January 25, 2026). We're now in May 2026 — is there an updated plugin I should install? Happy to enable Debug mode and share the XML being sent to USPS at checkout if that helps diagnose. Thank you. (Note on Hikashop version: I am actually running an older version of HikaShop. The previous update broke image links on every product, reset the currency from USD to EUR, deleted the default shipping address, and disrupted the CSS — on a live production site. I have not been able to safely update since. I am testing the 6.4.1 update on a cloned subdirectory before applying it to the live site. I listed 6.4.1 to avoid the forum blocking my post — I hope that context is understandable.)") Category: [Shipping Methods](/forum/28-shipping-methods "Discussions about the different shipping methods for Hikashop") Topic started 5 months 2 weeks ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") 4 months 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:10 Views:410 | [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 4 months 3 weeks ago |
| [](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372098) | [USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372098 "-- url of the page with the problem -- : pearblossomfarms.com/products -- HikaShop version -- : 6.4.1 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.2 -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : n/a I'm seeing a systematic overquoting problem where the USPS plugin quotes customers roughly 2× what the shipper actually pays via Click-N-Ship (Business Rate Card / Commercial pricing), for the same USPS Ground Advantage service. USPS Plugin Setup: * Origin ZIP: 81326 (Durango, CO area) * Service selected in plugin: USPS Ground Advantage only * Price Type: Commercial * Group Packages: Yes * Packaging weight: 0 oz, Weight approximation: 0% * Product dimensions entered per unit (e.g., a single jar: 4" × 3" × 3", 1.02 lb) The problem — likely dimensional weight: Product dimensions are entered per individual unit in HikaShop. For a multi-unit order (e.g., 12 jars), I believe the plugin packs N items using those per-unit dimensions and selects the smallest box from the configured box list that fits them. Our box sizes: * Small: 12" × 10" × 12" (1,440 ci) — used for orders under 11 lbs * Medium: 16" × 14" × 16" (3,584 ci) — used for orders 11–32 lbs The USPS dimensional weight threshold is 1,728 cubic inches (volume ÷ 166 = billed weight). Our Small box (1,440 ci) stays under the threshold — no dimensional weight, billed at actual weight. Our Medium box (3,584 ci) is well above it — dimensional weight = 3,584 ÷ 166 = 21.6 lb billed weight, even if the actual package weighs only 8–9 lbs. Cross-referenced with real shipment data: I exported 60 days of Click-N-Ship history (37 labels, all USPS Ground Advantage). Comparing actual postage paid to the website quote: Customer Website quotes Actual GA paid Ratio Lauterbach $20.28 $12.39 1.64× Drake $35.37 $14.09 2.51× Hummel $33.10 $8.48 3.90× Kolb $25.24 $10.74 2.35× Steakley $16.81 $13.83 1.22× The "close" orders (ratio ~1.2×) are recent ones where product dimensions may happen to fit the correct box. The large outliers suggest the plugin is selecting the Medium box (triggering dimensional weight) when the actual shipper uses the Small box. My questions: * How does the plugin calculate which box to select for a multi-unit order? Does it sum per-unit volumes and find the smallest fitting box, or use a different algorithm? * Does the plugin compute and send a dimensional weight to the USPS API when the selected box exceeds 1,728 ci? Or does it always send actual weight? * Is there a way to set a fixed box size per product (rather than having the plugin compute from per-unit dimensions) so it always requests the rate for the box the shipper actually uses? * Is the plugin currently using the new USPS API? I saw a March 2025 forum thread where Nicolas mentioned a new plugin was being developed to replace the old Web Tools API (retired January 25, 2026). We're now in May 2026 — is there an updated plugin I should install? Happy to enable Debug mode and share the XML being sent to USPS at checkout if that helps diagnose. Thank you. (Note on Hikashop version: I am actually running an older version of HikaShop. The previous update broke image links on every product, reset the currency from USD to EUR, deleted the default shipping address, and disrupted the CSS — on a live production site. I have not been able to safely update since. I am testing the 6.4.1 update on a cloned subdirectory before applying it to the live site. I listed 6.4.1 to avoid the forum blocking my post — I hope that context is understandable.)") Category: [Shipping Methods](/forum/28-shipping-methods "Discussions about the different shipping methods for Hikashop") Topic started 5 months 2 weeks ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") 4 months 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:10 Views:410 | [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 4 months 3 weeks ago |
| [](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#371989) | [USPS plugin quotes 2× actual rate - dimensional weight from per-unit dimensions?](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#371989 "-- url of the page with the problem -- : pearblossomfarms.com/products -- HikaShop version -- : 6.4.1 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.2 -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : n/a I'm seeing a systematic overquoting problem where the USPS plugin quotes customers roughly 2× what the shipper actually pays via Click-N-Ship (Business Rate Card / Commercial pricing), for the same USPS Ground Advantage service. USPS Plugin Setup: * Origin ZIP: 81326 (Durango, CO area) * Service selected in plugin: USPS Ground Advantage only * Price Type: Commercial * Group Packages: Yes * Packaging weight: 0 oz, Weight approximation: 0% * Product dimensions entered per unit (e.g., a single jar: 4" × 3" × 3", 1.02 lb) The problem — likely dimensional weight: Product dimensions are entered per individual unit in HikaShop. For a multi-unit order (e.g., 12 jars), I believe the plugin packs N items using those per-unit dimensions and selects the smallest box from the configured box list that fits them. Our box sizes: * Small: 12" × 10" × 12" (1,440 ci) — used for orders under 11 lbs * Medium: 16" × 14" × 16" (3,584 ci) — used for orders 11–32 lbs The USPS dimensional weight threshold is 1,728 cubic inches (volume ÷ 166 = billed weight). Our Small box (1,440 ci) stays under the threshold — no dimensional weight, billed at actual weight. Our Medium box (3,584 ci) is well above it — dimensional weight = 3,584 ÷ 166 = 21.6 lb billed weight, even if the actual package weighs only 8–9 lbs. Cross-referenced with real shipment data: I exported 60 days of Click-N-Ship history (37 labels, all USPS Ground Advantage). Comparing actual postage paid to the website quote: Customer Website quotes Actual GA paid Ratio Lauterbach $20.28 $12.39 1.64× Drake $35.37 $14.09 2.51× Hummel $33.10 $8.48 3.90× Kolb $25.24 $10.74 2.35× Steakley $16.81 $13.83 1.22× The "close" orders (ratio ~1.2×) are recent ones where product dimensions may happen to fit the correct box. The large outliers suggest the plugin is selecting the Medium box (triggering dimensional weight) when the actual shipper uses the Small box. My questions: * How does the plugin calculate which box to select for a multi-unit order? Does it sum per-unit volumes and find the smallest fitting box, or use a different algorithm? * Does the plugin compute and send a dimensional weight to the USPS API when the selected box exceeds 1,728 ci? Or does it always send actual weight? * Is there a way to set a fixed box size per product (rather than having the plugin compute from per-unit dimensions) so it always requests the rate for the box the shipper actually uses? * Is the plugin currently using the new USPS API? I saw a March 2025 forum thread where Nicolas mentioned a new plugin was being developed to replace the old Web Tools API (retired January 25, 2026). We're now in May 2026 — is there an updated plugin I should install? Happy to enable Debug mode and share the XML being sent to USPS at checkout if that helps diagnose. Thank you. (Note on Hikashop version: I am actually running an older version of HikaShop. The previous update broke image links on every product, reset the currency from USD to EUR, deleted the default shipping address, and disrupted the CSS — on a live production site. I have not been able to safely update since. I am testing the 6.4.1 update on a cloned subdirectory before applying it to the live site. I listed 6.4.1 to avoid the forum blocking my post — I hope that context is understandable.)") Category: [Shipping Methods](/forum/28-shipping-methods "Discussions about the different shipping methods for Hikashop") Topic started 5 months 2 weeks ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") 4 months 3 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:10 Views:410 | [Last Post](/forum/28-shipping-methods/910536-usps-plugin-quotes-2-actual-rate-dimensional-weight-from-per-unit-dimensions#372210 "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).") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 4 months 3 weeks ago |
| [](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368838) | [Authorize.net credit card module/plugin won't allow entering of a credit card, F](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368838 "-- url of the page with the problem -- : pearblossomfarms.com/ -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : The Aurthorize.net Credit card module refreshes but it won't show the form to enter credit card. We have processed transactions without issues until last week, but today we received a message that the customer could not find a form to enter their credit card after creating an account and purchasing a product. In going over things, I realized our subscription expired in April 2025. I will be renewing it as soon as my client sends me their credit card or has time to go online with zoom so I can renew hikashop, but that cannot be the reason since we have had transactions clearing until recently. What happens now is that after login or after creating an account we get this message: Credit Card PBF You can pay by credit card using this payment method You chose the payment method: Credit Card PBF Clicking on "Pay" or "Continue" just refreshes the page and there is no form to enter the credit card. I also turned on Paypal Checkout, but that too only refreshes and never goes to paypal to pay. Again, everything worked fine as of last week. I am checking Authorize.net in case something went wrong there, but it all seems in order. I'll have my client call them to confirm. Meantime there is no available payment method on the website. PS: The Authorize.net plugin is named Hikashop Authorize.net Payment Plugin I cannot find out if this is the same plugin as this one: www.hikashop.com/marketplace/product/150...e-js-by-obsidev.html I am having my client call authorize.net to make sure nothing is broken over there.") Category: [Checkout](/forum/27-checkout "Everything about the checkout process in Hikashop") Topic started 1 year 2 months ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") 1 year 1 month ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:12 Views:814 | [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 1 year 1 month ago |
| [](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368797) | [Authorize.net credit card module/plugin won't allow entering of a credit card, F](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368797 "-- url of the page with the problem -- : pearblossomfarms.com/ -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : The Aurthorize.net Credit card module refreshes but it won't show the form to enter credit card. We have processed transactions without issues until last week, but today we received a message that the customer could not find a form to enter their credit card after creating an account and purchasing a product. In going over things, I realized our subscription expired in April 2025. I will be renewing it as soon as my client sends me their credit card or has time to go online with zoom so I can renew hikashop, but that cannot be the reason since we have had transactions clearing until recently. What happens now is that after login or after creating an account we get this message: Credit Card PBF You can pay by credit card using this payment method You chose the payment method: Credit Card PBF Clicking on "Pay" or "Continue" just refreshes the page and there is no form to enter the credit card. I also turned on Paypal Checkout, but that too only refreshes and never goes to paypal to pay. Again, everything worked fine as of last week. I am checking Authorize.net in case something went wrong there, but it all seems in order. I'll have my client call them to confirm. Meantime there is no available payment method on the website. PS: The Authorize.net plugin is named Hikashop Authorize.net Payment Plugin I cannot find out if this is the same plugin as this one: www.hikashop.com/marketplace/product/150...e-js-by-obsidev.html I am having my client call authorize.net to make sure nothing is broken over there.") Category: [Checkout](/forum/27-checkout "Everything about the checkout process in Hikashop") Topic started 1 year 2 months ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") 1 year 1 month ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:12 Views:814 | [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 1 year 1 month ago |
| [](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368795) | [Authorize.net credit card module/plugin won't allow entering of a credit card, F](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368795 "-- url of the page with the problem -- : pearblossomfarms.com/ -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : The Aurthorize.net Credit card module refreshes but it won't show the form to enter credit card. We have processed transactions without issues until last week, but today we received a message that the customer could not find a form to enter their credit card after creating an account and purchasing a product. In going over things, I realized our subscription expired in April 2025. I will be renewing it as soon as my client sends me their credit card or has time to go online with zoom so I can renew hikashop, but that cannot be the reason since we have had transactions clearing until recently. What happens now is that after login or after creating an account we get this message: Credit Card PBF You can pay by credit card using this payment method You chose the payment method: Credit Card PBF Clicking on "Pay" or "Continue" just refreshes the page and there is no form to enter the credit card. I also turned on Paypal Checkout, but that too only refreshes and never goes to paypal to pay. Again, everything worked fine as of last week. I am checking Authorize.net in case something went wrong there, but it all seems in order. I'll have my client call them to confirm. Meantime there is no available payment method on the website. PS: The Authorize.net plugin is named Hikashop Authorize.net Payment Plugin I cannot find out if this is the same plugin as this one: www.hikashop.com/marketplace/product/150...e-js-by-obsidev.html I am having my client call authorize.net to make sure nothing is broken over there.") Category: [Checkout](/forum/27-checkout "Everything about the checkout process in Hikashop") Topic started 1 year 2 months ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") 1 year 1 month ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:12 Views:814 | [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 1 year 1 month ago |
| [](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368791) | [Authorize.net credit card module/plugin won't allow entering of a credit card, F](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368791 "-- url of the page with the problem -- : pearblossomfarms.com/ -- Browser(s) name and version -- : Chrome -- Error-message(debug-mod must be tuned on) -- : The Aurthorize.net Credit card module refreshes but it won't show the form to enter credit card. We have processed transactions without issues until last week, but today we received a message that the customer could not find a form to enter their credit card after creating an account and purchasing a product. In going over things, I realized our subscription expired in April 2025. I will be renewing it as soon as my client sends me their credit card or has time to go online with zoom so I can renew hikashop, but that cannot be the reason since we have had transactions clearing until recently. What happens now is that after login or after creating an account we get this message: Credit Card PBF You can pay by credit card using this payment method You chose the payment method: Credit Card PBF Clicking on "Pay" or "Continue" just refreshes the page and there is no form to enter the credit card. I also turned on Paypal Checkout, but that too only refreshes and never goes to paypal to pay. Again, everything worked fine as of last week. I am checking Authorize.net in case something went wrong there, but it all seems in order. I'll have my client call them to confirm. Meantime there is no available payment method on the website. PS: The Authorize.net plugin is named Hikashop Authorize.net Payment Plugin I cannot find out if this is the same plugin as this one: www.hikashop.com/marketplace/product/150...e-js-by-obsidev.html I am having my client call authorize.net to make sure nothing is broken over there.") Category: [Checkout](/forum/27-checkout "Everything about the checkout process in Hikashop") Topic started 1 year 2 months ago, by [conticreative](/forum/user/12955-conticreative "View conticreative's Profile") [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") 1 year 1 month ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") | Replies:12 Views:814 | [Last Post](/forum/27-checkout/909674-authorize-net-credit-card-module-plugin-wont-allow-entering-of-a-credit-card-f#368840 "Hi, Yes, dimensions are required with UPS OAuth. Note that it is not a requirement of the plugin itself. It's a requirement of the UPS OAuth API, while the old UPS API didn't have that requirement and thus you could do without them with the old UPS plugin. I'm glad it now works for you.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 1 year 1 month ago |
[](/forum/topics/feed/mode-topics?format=feed&type=rss)
Time to create page: 0.139 seconds
[Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)