M2.4.2 Customer Name Prefixes Showing as numbers not Mr., Mrs., Ms. etc

Question

M2.4.2 Customer Name Prefixes Showing as numbers not Mr., Mrs., Ms. etc

Closed this issue 2 years ago · 38 comments

After upgrading Magento from 2.4.1 to 2.4.2, customer orders are coming through with numbers instead of Name Prefixes such as Mr., Mrs. etc. No settings have been changed since the upgrade.

Preconditions (*)

Magento CE 2.4.2
Magento 2.4-develop

Steps to reproduce (*)

Enable customer prefix
Go to Sales->Orders
Click Create New Order
Click Create New Customer
Fill required fields and choose Name Prefix from dropdown
Click Submit Order

Expected result (*)

The name will show in the order summary page as [Name Prefix] [First Name] [Surname]

Actual result (*)

The name shows as [Number] [First Name] [Surname]. This also replicated in the transactional emails.

Answer 1 · 2021-02-15T16:48:09.000Z

Hi @likearocket. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

Summary of the issue
Information on your environment
Steps to reproduce
Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

Join Magento Community Engineering Slack and ask your questions in #github channel.

⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

Answer 2 · 2021-02-16T06:38:14.000Z

Hi @engcom-Delta. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
Details
If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.
3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
4. Verify that the issue is reproducible on 2.4-develop branch
Details
- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
5. Add label Issue: Confirmed once verification is complete.
6. Make sure that automatic system confirms that report has been added to the backlog.

Answer 3 · 2021-02-16T08:08:58.000Z

✅ Confirmed by @engcom-Delta
Thank you for verifying the issue. Based on the provided information internal tickets MC-40899 were created

Issue Available: @engcom-Delta, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

Answer 4 · 2021-02-18T20:21:12.000Z

@magento I am working on it

Answer 5 · 2021-02-18T20:21:15.000Z

Hi @ashtonsax! 👋
Thank you for collaboration. Only members of Community Contributors Team are allowed to be assigned to the issue. Please use @magento add to contributors team command to join Contributors team.

Answer 6 · 2021-02-18T20:21:28.000Z

@magento add to contributors team

Answer 7 · 2021-02-18T20:21:31.000Z

Hi @ashtonsax! 👋
Thank you for joining. Please accept team invitation 👉 here 👈 and add your comment one more time.

Answer 8 · 2021-02-18T20:21:51.000Z

@magento I am working on it

Answer 9 · 2021-02-21T15:00:37.000Z

It seems this does only happen for guest orders. The customer prefix is saved as integer inside the prefix column in sales_orders_address table instead as string.

Answer 10 · 2021-03-09T16:26:17.000Z

This issue is caused by some questionable logic in Magento\Checkout\Block\Checkout\LayoutProcessor that was exposed by the change to Magento\Customer\Model\Options in #28238.

In the convertElementsToSelect() function of the LayoutProcessor it assumes the array key has relevance to the option and the content that it's getting ready to render. Previously to 2.4.2 the Options file created an array key that matched the array value so this wasn't a problem. Since the change in 2.4.2 to solve another issue the array key is now an integer element id that has no relevance to the display or function of the checkout process. The solution looks to be assigning the value from the $options array in the function to both the value & the label. So that the nested foreach inside that function would become as follows.

foreach ($options as $key => $value) { $elements[$code]['options'][] = [ 'value' => $value, 'label' => $value, ]; }

Although this solution does not solve the issue in the administration console's edit address for an order that's been processed as it seems to follow the same logic as the layout processor did to generate it's display.

Answer 11 · 2021-03-26T10:26:07.000Z

Any news on this? This is a very annoying bug and there seems to be no working patch around

Answer 12 · 2021-03-26T11:02:57.000Z

This is the patch we've used for the issue on the frontend of our magento stores as a quick fix, until a full range solution can be written and incorporated into Magento itself.
0001-prefix-array-element-index-issue-bugfix.patch.txt

Edit (21/06/21):
Gist for the fix including a composer.json snippet in case the file link breaks at some point.
https://gist.github.com/Sental/d5f81a8d5e66f0ca9383968749074e41

Answer 13 · 2021-04-30T08:29:25.000Z

I'm surprised that anyone is using version 2.4.2 productively, when it can't even send mails to customers with the correct form of address.
Thanks for the fix for the frontend. Since we very often have to correct the addresses of the customers so that we can automatically create the labels for the packages, we unfortunately also need a solution for the backend. That's why I tried to solve the problem in the backend by myself.
I have adapted the following file for this purpose:
/module-sales/Block/Adminhtml/Order/Create/Form/Address.php.

In the _prepareForm function, I replaced the retrieved simple array $prefixOptions with one that also has the Value as an index. With this, the address change in the backend works again for now.

 if ($prefixElement) {
            $prefixOptions = $this->options->getNamePrefixOptions($this->getStore());
            if (!empty($prefixOptions)) {
				// fix for prefix value
				$prefixOptions2=array ();
				foreach ($prefixOptions as $prefix) {
					$prefixOptions2[$prefix]=$prefix;
				}
                $fieldset->removeField($prefixElement->getId());
                $prefixField = $fieldset->addField($prefixElement->getId(), 'select', $prefixElement->getData(), '^');
                $prefixField->setValues($prefixOptions2);
                if ($this->getAddressId()) {
                    $prefixField->addElementValues($this->getAddress()->getPrefix());
                }
            }
       }

Answer 14 · 2021-05-19T08:50:51.000Z

We've written a small plugin to intercept the Order Address Model and check the prefix against Magento\Customer\Model\Options::getNamePrefixOptions() as it's loaded. If the prefix appears as a key in the getNamePrefixOptions array (the case when it's an integer), the prefix in the Model is updated to use the matching value from the options array. https://github.com/DanBeckett/door4-customer-prefix-patch.

Answer 15 · 2021-05-28T08:17:16.000Z

What is the status of this issue?

Answer 16 · 2021-06-01T09:33:00.000Z

Hello, is there any update on this issue? Thanks.

Answer 17 · 2021-06-01T14:31:09.000Z

@antonio-valdez-arce Still not working in 2.4.2-p1. I used the solution of @DanBeckett for the admin and the emails and I used the patch from @Sental for in the frontend.

Answer 18 · 2021-06-01T15:43:55.000Z

@antonio-valdez-arce Still not working in 2.4.2-p1. I used the solution of @DanBeckett for the admin and the emails and I used the patch from @Sental for in the frontend.

ok, thank you. I will try it.

Answer 19 · 2021-06-21T16:26:45.000Z

here @DanBeckett s link again: https://github.com/DanBeckett/door4-customer-prefix-patch (link was broken).

However, as far as my debugging and testing was showing: the fix of @Sental is working fine - also for emails and admin area! The fix of @DanBeckett is only needed to display orders correctly which have been stored with without the fix into the database (since the prefix is written directly into the database). This applies also for all customer addresses which have been added to the address book within the checkout process.
In a long term I recommend to clean the values in the database - otherwise you'll need this workaround for ever

Answer 20 · 2021-07-20T10:04:37.000Z

this error happens to us on 2.4.2-p1, but the fix from @Sental doesnt work somehow
edit: door4/customerprefixpatch module works 👍🏼

Answer 21 · 2021-07-20T10:37:42.000Z

this error happens to us on 2.4.2-p1, but the fix from @Sental doesnt work somehow
edit: door4/customerprefixpatch module works 👍🏼

In that case you were dealing with a prefix that had already been saved with the incorrect data which the door4 patch fixes. The patch I've made available corrects fields when new addresses are created/saved and the error could have occurred. If you have corrupted data in your database you need both patches.

Answer 22 · 2021-10-14T20:54:08.000Z

door4/customerprefixpatch module works fine for already registered customers. But I can't find a way to get it working for guest customers. Anyone else still working on this?

Answer 23 · 2021-10-27T12:03:16.000Z

@magento I am working on it

Answer 24 · 2021-12-08T10:44:41.000Z

I have created a fix for this and this fix works for me.

https://github.com/bunnyofficiial/Customerprefixchange

Answer 25 · 2021-12-08T13:13:57.000Z

I tried the solution by bunnyofficiial, DanBecket and Sental. For me only Sental's solution worked via core patch. It's also the most elegant as it gets obsolete as soon as there is a fix in the core (because then the patch cannot be applied anymore).

Answer 26 · 2022-03-04T14:00:05.000Z

I recently stumbled on this issue. As @Sental mentioned the issue was introduced with #28238.

The issue #32066 seems also to be related. After the change to nummeric array index in the prefix options, the current value is no longer found and get added.

My current fix is a composer patch, reverting the change from #28238.
I'm not done testing, but so far frontend issues seems to be fixed.
I am also not sure, what the intentions the prefix options changes had. But clearly there where some parts of that didn't get changed to support numeric index for the customer prefix array.

Composer patch for "magento/module-customer":
github-issue-32177.diff.txt

Answer 27 · 2022-05-02T09:20:04.000Z

This issue is still reproducible on Magento 2.4.4.

Answer 28 · 2022-08-30T09:26:45.000Z

I made a fix which works with no problems for me.

I created after plugin on \Magento\Customer\Model\Options::getNamePrefixOptions method. It looks like this:

<?php
declare(strict_types=1);
namespace Vendor\Module\Plugin;

use Magento\Customer\Model\Options;

class ChangePrefixOptionKeys
{
    /**
     * @param Options $subject
     * @param array|bool $result
     * @return array|bool
     */
    public function afterGetNamePrefixOptions(Options $subject, array|bool $result): array|bool
    {
        if (!is_array($result)) {
            return $result;
        }

        $newPrefixArray = [];
        foreach ($result as $prefixValue) {
            $newPrefixArray[$prefixValue] = $prefixValue;
        }

        return $newPrefixArray;
    }
}

Answer 29 · 2022-08-30T10:21:18.000Z

@Beraa995 Pretty cool! Thanks for sharing. It looks like you implemented your own "array_unique". I think you could reduce some lines of code by using the native array_unique-function.

Answer 30 · 2022-08-30T11:06:31.000Z

#36003 could maybe also fix it?

Answer 31 · 2022-08-30T11:09:18.000Z

The pull request #35060 has also been raised to fix this issue.

Answer 32 · 2022-09-20T05:45:50.000Z

The issue is reproducing in M2.4.3. Any solution for this?

Answer 33 · 2022-09-20T13:01:55.000Z

PR with the fix: #36003
Composer Patch: https://patch-diff.githubusercontent.com/raw/magento/magento2/pull/36003.diff
Instructions: https://devdocs.magento.com/guides/v2.4/comp-mgr/patching/composer.html

Answer 34 · 2022-10-30T17:18:25.000Z

Quick solution : edit this file : /vendor/magento/module-customer/Model/Options.php
Inline 104 update code :
$result[] = $this->escaper->escapeHtml(trim($value)) ?: ' ';
to :
$result[$value] = $this->escaper->escapeHtml(trim($value)) ?: ' ';

Answer 35 · 2023-05-30T14:55:23.000Z

Well this is back again, if you change an order adres via admin the value is 0,1,2. @vutrankien's fix still applies

Answer 36 · 2023-06-01T17:09:15.000Z

Well this is back again, if you change an order adres via admin the value is 0,1,2. @vutrankien's fix still applies

Which version is it back in @stefanfr ? I will do another PR to fix it.

Answer 37 · 2023-06-02T06:15:42.000Z

@Sental Just ran into this issue on M2.4.4 when a new address is created in the checkout

Answer 38 · 2023-07-20T14:14:19.000Z

@Sental Didn't see your message, as @oskars-elksnitis said it is back since 2.4.4 and onwards, latest 2.4.6-p1 still has this issue:

foreach ($options as $value) {
    $result[] = $this->escaper->escapeHtml(trim(__($value))) ?: ' ';
}