Payment text: Bank transfer and cash-on-delivery instructions do not properly resolve language keys or render HTML. This makes the payment instructions unusable in multilingual stores.
Checkout address selectors: The checkout has separate Shipping Address and Billing/Invoice Address forms. Each form has a “Use Existing Address” dropdown, but both dropdowns currently list all saved addresses. As a result, the shipping selector includes billing addresses, and the billing selector includes shipping addresses. Each selector should show only addresses assigned to the relevant address type.
There is also a related display and validation issue. A billing address with a tax number but no personal name or street can appear as an empty option in the dropdown. The server also accepts an address of the wrong type. Expected behaviour: filter both the selector and server-side validation by address type, and always render a non-empty option label, for example using the company name or tax number.
Custom checkout fields: Values entered at checkout are saved, but they are missing from order details, the customer address book, and other customer/admin displays.
Guest email field: When email is enabled for guest shipping but disabled for guest billing, the email field is hidden from the first shipping form, even though it should still be visible there.
Checkout flow and guest email: The checkout process should always start with the Shipping Address form. Billing/Invoice Address should be the second step or an optional section, used only when the customer needs separate invoice details. This is especially important for guest checkout, because the customer’s email and delivery details logically belong to the shipping/contact step. If guest email is enabled for shipping but disabled for billing, the email field should still be visible in the first shipping form. Not every buyer is a business—statistically, the opposite is true, so the order in which the forms are filled out should be reversed.
Options and filters: Language keys are not translated in administrator product search, product views, or option/filter views. Searching by translated names also does not work.
Invoice billing data: By default, forcing first name and last name fields in invoice billing details is unnecessary and can be incorrect. Not every company is named after an individual. In Poland, the key business identifier is the NIP / VAT number, and the invoice should be issued to the legal company name assigned to that tax number, not automatically to an individual person. The form should allow company name + tax number without requiring separate personal first name and last name fields.
I have already fixed these issues locally in my installation, but I would strongly prefer to have them fixed in the core component. Otherwise, every J2Commerce update forces me to reapply or rebuild the same local fixes.
best regards,
KK
