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

[likearocket]

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 (*)

1. Magento CE 2.4.2
2. Magento 2.4-develop

Steps to reproduce (*)

1. Enable customer prefix
   
2. Go to Sales->Orders
3. Click Create New Order
4. Click Create New Customer
5. Fill required fields and choose Name Prefix from dropdown
6. Click Submit Order

Expected result (*)

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

Actual result (*)

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

[m2-assistant]

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

[m2-assistant]

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.

[magento-engcom-team]

✅ 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.

[ashtonsax]

@magento I am working on it

[m2-assistant]

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.

[ashtonsax]

@magento add to contributors team

[m2-assistant]

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

[ashtonsax]

@magento I am working on it

[codedge]

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.

[Sental]

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.

[stephansteiner]

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

[Sental]

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

[mad-develop]

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

[BorisovskiP]

This issue is still reproducible on Magento 2.4.4.

[Beraa995]

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;
    }
}

[homecoded]

@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.

[hostep]

#36003 could maybe also fix it?

[Sental]

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

[kazimck]

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

[lbajsarowicz]

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

[vutrankien]

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)) ?: ' ';

[stefanfr]

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

[Sental]

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.

[oskars-elksnitis]

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

[stefanfr]

@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))) ?: ' ';
}