View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003465 | OXID eShop (all versions) | 4.07. Source code, Test | public | 2011-12-29 10:06 | 2022-02-03 08:05 |
| Reporter | tjungcl | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | 4.5.6 revision 40808 | ||||
| Summary | 0003465: custom dynvalues have language specific input names | ||||
| Description | if you create dynvalues for a custom payment method, you can give language specific names, such as "Telefonnr." and "Phone number". The tpl then generates a input field for the new field and uses as its name "dynvalues[Telefonnr.]" and "dynvalues[Phone number]". Meaning, here the language specific title of the dynvalue field and the internal name of the request variable is mixed, making it neccessary to create a special php handler for the dynvalues. On the other hand, the new input fields also get an id "oxempty_1", which is not language specific, but cant be used to access the value from the request. This unideal structure makes it neccessary so have special templates for creditcard and direct debit, where else the "payment_other" tpl could suffice. => Either you could add id/title to the payment dynvalues in the admin, so the admin can set the id to "lsktonr" and the name to "Kontonr."/"Account No.", or you could use the logic from other_payments id as input name. | ||||
| Tags | Payment | ||||
| Theme | Not defined | ||||
| Browser | All | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
waiting for the PO decision. |
|
|
Still reproducible. Steps to reproduce: 1. goto admin (language: english) 2. Shop settings -> payment settings -> Invoice 3. Add the field "english", save it. 4. At the bottom, change the language to German at the select box "In Language: English -> German". 5. Add the field "german", save it. 6. Open the frontend, english, go through the checkout until payment and choose invoice. 7. Set the value "en" for the field "english". 8. Repeat the steps 6 and 7 but with the german language. Instead of the field "english" you must see "german" in checkout step 3 (payment). Use the value "de" this time. Result: string(13) "english__en@@" string(13) "german__de@@" Problem: For the same field two identifiers are used. Instead of english and german one unique identifier should be used. - Michael Keiluweit |
|
|
Thanks. I agree there is an issue here. Although I disagree on the general assessment that the ID usage is wrong. The problem here is, that the change of the language is actually referring to the payment method and not the fields. So for the shop the german language payment method just has completely different custom fields than the english language payment method. This CAN be intended, but I doubt this is the usual usecase. Unfortunately a fix here is not trivial since it MIGHT be intentional to use different fields in different languages and there is currently no way to connect the 2 different custom fields with another. I could imagine 2 different ways to fix this: - add separate id and title inputs for custom fields and only translate the title field when you switch (and only show those in the frontend (or an error message) if you have untranslated titles - make the custom fields completely independent objects and give them their own tab at least The first option needs a new UI/UX pass, the second one probably even slight changes in the architecture |
