Product Attributes are not typed correctly

[gwharton]

Preconditions and environment

Tested on

• 2.4.8
• 2.4.7
• PHP 8.2
• PHP 8.3

Steps to reproduce

• Deploy vanilla magento and install sample data.
• Run the following test code in the root which demonstrates the problem by getting the status of the product (enabled/disabled) and printing the return type of the getStatus() call.

use Magento\Framework\App\Bootstrap;
use Magento\Catalog\Api\ProductRepositoryInterface;

require __DIR__ . '/app/bootstrap.php';

$productRepository = Bootstrap::create(BP, $_SERVER)
    ->getObjectManager()
    ->create(ProductRepositoryInterface::class);

$product = $productRepository->get("24-MB01");
$status = $product->getStatus();
echo "Return type of getStatus() is : " . gettype($status) . PHP_EOL;

return;

Expected result

Return type of getStatus() is : int

Actual result

Return type of getStatus() is : string

Additional information

The Status Product Attribute is defined in core Magento as an integer.

When products are created, the Attribute "status" is stored in the catalog_product_entity_int table confirming it is typed as integer.

The Magento ProductInterface defines the call getStatus() as returning an int or null.

magento2/app/code/Magento/Catalog/Api/Data/ProductInterface.php

Lines 133 to 138 in c8ba4ab

	/**
	* Product status
	*
	* @return int|null
	*/
	public function getStatus();

Yet calls to $product->getStatus() return a string.

The same thing happens when retrieving float values, for example $product->getPrice() returns a string despite the Interface mandating float or null.

magento2/app/code/Magento/Catalog/Api/Data/ProductInterface.php

Lines 118 to 123 in c8ba4ab

	/**
	* Product price
	*
	* @return float|null
	*/
	public function getPrice();

EDIT : I'm willing to concede on getPrice as Price is stored as a DECIMAL type in MySQL which is a fixed precision string representation of a floating point number, and not a float.

Release note

No response

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @gwharton. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

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, join the Community Contributions Triage session to discuss the appropriate ticket.

[gwharton]

Also note, this is not just specific to product attributes. If you create a database table with a series of colums of type int, then use your model factory to create and load an instance of your model from the database, the resulting model object will have values set to strings, not ints, as per the database.

[gwharton]

OK, the fix to the DB Model not typing things correctly, is to add the following PDO option to your driver options in env.php

PDO::ATTR_STRINGIFY_FETCHES = false (Option 17)

This option was added in 2.4.4-p1 to default to true, which means all model loads from that point on, load all model data as strings!!! I have no idea why this change would be introduced, but for me, I want my model types to match my database types.

This doesn't fix the typing of product attributes which are loaded by a different mechanism.

EDIT : If you set this, other modules in Magento break. e.g module-security is expecting the admin user ID to be a string of the numerical user id.

[m2-assistant]

Hi @engcom-Hotel. 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).
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

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

[engcom-Hotel]

Hello @gwharton,

Thanks for the report and collaboration!

We have tried to reproduce the issue in 2.4-develop branch, and it is working as the actual result mentioned above.

But we have some observation here, even if we add in app/etc/env.php, the issue doesn't seems to be solved:

'driver_options' => [
                    1014 => false,
                    17 => false,
                ]

But when we add :int in app/code/Magento/Catalog/Model/Product:getStatus as follows:

public function getStatus() :int
{
    $status = $this->_getData(self::STATUS);
    return $status !== null ? $status : Status::STATUS_ENABLED;
}

the issue seems to be solved.

Thanks

[gwharton]

I've mixed two problems here

The first is that product attributes are not typed correctly.

The second is that model types in general (but not product) are not typed. Adding the PDO option 17 resolves the second issue, that general model values are not typed correctly, but this then breaks other things in core, that have been written to expect things to be broken. Ignore this second issue for now, and concentrate on product attributes. Product attributes are obtained differently than general model values.

I used product->getStatus as an example that should return an int, but if you xdebug step and inspect any product and it's attributes, you will see that any attribute with the type int, is represented as a string.

In my opinion, the fix for this is to fix the underlying product attribute mechanism to respect the attribute type without treating everything as a string, and not hard code cast the string to an int in the getStatus call which is just masking the underlying problem.