php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #80499 simplexml_load_string does not work as on PHP 7.X
Submitted: 2020-12-09 13:06 UTC Modified: 2020-12-10 11:30 UTC
From: gilperon at gmail dot com Assigned:
Status: Verified Package: *XML functions
PHP Version: 8.0.0 OS: ANY
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: gilperon at gmail dot com
New email:
PHP Version: OS:

 

 [2020-12-09 13:06 UTC] gilperon at gmail dot com
Description:
------------
On versions of PHP prior to 8.0 when you use `simplexml_load_string` you could access the values with no problems and assign them to other functions. However on PHP 8.0 the values are of type SimpleXMLObject and not of string, float...

You can see this in action running the pretty simple test script. You will see the first `var_dump`, instead of showing `float(46.50)` or `string(46.50)` it shows:

object(SimpleXMLElement)#4 (1) {
  [0]=>
  string(5) "46.50"
}

Of course, it's pretty easy to convert this to a string or float using (string)$x or (float)$x HOWEVER this didnt happen on other versions of PHP. And the real problem arises when you try to use a function like `number_format` that expects a number to work, however it's not getting a number and fails.

For some strange reason functions like `round` work just fine without converting the SimpleXMLElement object, however `number_format` has problems dealing with it. Maybe `round` casts the parameter to a numeric value and `number_format` does not. Anyway, I think that if this is an expected result it should be mentioned on migration guide/incompatibiliy notes.

Test script:
---------------
$xml_retorno = simplexml_load_string('<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?><transaction><date>2020-12-09T09:20:51.000-03:00</date><code>EACDE7D2-EBD5-4F69-B760-640A5EFDC6A6</code><type>1</type><status>3</status><lastEventDate>2020-12-09T09:23:01.000-03:00</lastEventDate><paymentMethod><type>1</type><code>102</code></paymentMethod><grossAmount>46.50</grossAmount><discountAmount>0.00</discountAmount><feeAmount>2.72</feeAmount><netAmount>43.78</netAmount><extraAmount>0.00</extraAmount><escrowEndDate>2020-12-23T01:00:00.000-03:00</escrowEndDate><installmentCount>1</installmentCount><itemCount>1</itemCount><items><item><id>Prestação de serviço digital</id><description>XCHCU7</description><quantity>1</quantity><amount>46.50</amount></item></items><sender><name>GGGG</name><email>corporativo@vvvv.agr.br</email><phone><areaCode>16</areaCode><number>981746872</number></phone></sender><shipping><address><street>Rua Mariana Amaral</street><number>138</number><complement></complement><district>Lagoinha</district><city>SAO XXXDO XXX</city><state>MG</state><country>BRA</country><postalCode>445333</postalCode></address><type>3</type><cost>0.00</cost></shipping></transaction>');

var_dump($xml_retorno -> items -> item[0] -> amount);

echo number_format($xml_retorno -> items -> item[0] -> amount,2);

Expected result:
----------------
Return the value as string/float...

Actual result:
--------------
It return the value as a XML object.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-12-09 13:14 UTC] nikic@php.net
This never worked: https://3v4l.org/ZrhSM

Only difference is that it now throws TypeError instead of a warning and incorrect result.

That part is expected, but I can't seem to find the relevant entry in the migration guide...
 [2020-12-09 13:58 UTC] cmb@php.net
-Status: Open +Status: Verified -Type: Bug +Type: Documentation Problem
 [2020-12-09 13:58 UTC] cmb@php.net
Indeed, there should be an entry in the migration guide telling
that calling functions with unexpected parameter types (in
non-strict mode value coercion still applies) now throws TypeError
instead of raising E_WARNING and returning null (or false for some
functions).
 [2020-12-09 14:33 UTC] gilperon at gmail dot com
nikic@php.net

It always worked. I cant understand why you said "it never worked". It always worked because it raised a Warning and, despite the warning, the interpreter would move on executing the remaining code and everything just worked. NOW IT SHOWS "Fatal error" and that's what is causing this problem I am having because previously, when this problem happened, my entire code just worked. Now, it simply stops at the fatal error.
 [2020-12-10 03:10 UTC] Dygear at gmail dot com
I think there might be a few edge cases in the XML functions that have cropped up in PHP 8.0 that didn't really show their face in the previous versions. I'm currently having a very hard time with SimpleXMLElement so this might be the start of a larger problem. I'm going to do some tests and see if I can reproduce them with some short test cases. I might be submitting my own bug report soon as well.
 [2020-12-10 11:30 UTC] cmb@php.net
> I cant understand why you said "it never worked".

Because it never echoed the expected "46.50", because
number_format() returned NULL in that case.  That looks like a
serious bug to me.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 17:01:29 2024 UTC