Troubleshooting
PrestaShopException: diagnosing Invalid address
The Invalid address #ID exception means PrestaShop could not load a valid address for that identifier. The stack trace tells you whether it comes from a cart, an order or a module; don't assume every case is fixed by setting an address to zero.
Find the reference
Note down the ID, action, URL and stack trace. Work on a copy first. Replace PREFIX_ with the real prefix and <ID> with the number you have checked:
SELECT id_address, deleted, active FROM PREFIX_address WHERE id_address = <ID>; SELECT c.id_cart, c.id_address_delivery, c.id_address_invoice, o.id_order FROM PREFIX_cart c LEFT JOIN PREFIX_orders o ON o.id_cart = c.id_cart WHERE c.id_address_delivery = <ID> OR c.id_address_invoice = <ID>;
If the address exists, check its status and the logic that uses it before changing it. If there is an order, preserve its historical address; a reference that doesn't exist may need to be recovered from a backup and the order's integrity checked.
Limited case: cart with no order and a missing address
Only when the stack trace confirms this case, identify one specific cart and the affected field. This example affects only the delivery address of the selected cart, which has no order and whose address doesn't exist. Also replace <ID_CARRITO> (the cart ID):
START TRANSACTION; UPDATE PREFIX_cart c LEFT JOIN PREFIX_orders o ON o.id_cart = c.id_cart LEFT JOIN PREFIX_address a ON a.id_address = c.id_address_delivery SET c.id_address_delivery = 0 WHERE c.id_cart = <ID_CARRITO> AND c.id_address_delivery = <ID> AND o.id_order IS NULL AND a.id_address IS NULL; SELECT id_cart, id_address_delivery, id_address_invoice FROM PREFIX_cart WHERE id_cart = <ID_CARRITO>; ROLLBACK;
The dry run needs transactional tables such as InnoDB and the same connection for every statement. Confirm that only the intended row changes and that ROLLBACK restores the previous value. It is no guarantee of rollback on MyISAM.
To check how the application behaves, commit the change only on the clone and reproduce the cart there. A web request on another connection won't normally see your transaction's uncommitted changes yet. The customer may have to select their address again.
If the wrong field is the invoice address, prepare and test the corresponding statement; don't change both out of habit. In production, keep another backup taken immediately beforehand and avoid concurrent writes before running only the change you have tested. Don't empty carts or normalise every orphaned reference in the shop.
If you can't identify a single relationship and its effect, give the stack trace and the identifiers to support or to the developer, without attaching personal address data.
You may also find useful
- Error "Argument X passed OrderProductForViewing must be of the type string" Identify the exact argument and row that deliver NULL when viewing a PrestaShop order, without bulk-...
- Error "Shop not found at line xxx in file classes/shop/Shop.php" Track down Shop not found by checking the requested URL, shop_url and the scope of PS_SHOP_DEFAULT b...
- GLPI time zone error with MariaDB or MySQL Tell apart time zone data that has not been loaded from the permission that only GLPI versions earli...
- SQLSTATE 2026 error when installing or updating PrestaShop Diagnose the SSL connection to MySQL that prevents Doctrine from querying the server version, withou...
Something wrong or out of date? Tell us and we will review it.