DOMDocument schemaValidate error migrating to PHP 8.2 #7278

@greg0ire commented on GitHub (Dec 13, 2023):

💡 OK I think I get it

there is a new version of libxml which is stricter => we might have to fix our XSD file because of it.
Invalid Schema is not an issue about the xml file, but about the xsd file itself, which explains why libxml_use_internal_errors(true); does not remove the warning about the schema.

@greg0ire commented on GitHub (Dec 13, 2023): :bulb: OK I think I get it - there is a new version of libxml which is stricter => we might have to fix our XSD file because of it. - `Invalid Schema` is not an issue about the xml file, but about the xsd file itself, which explains why `libxml_use_internal_errors(true);` does not remove the warning about the schema.

admin commented

@mleko64 commented on GitHub (Dec 13, 2023):

Exactly, the error concerns the schema file (doctrine-mapping.xsd), not the current xml file that needs to be checked.

@mleko64 commented on GitHub (Dec 13, 2023): Exactly, the error concerns the schema file (doctrine-mapping.xsd), not the current xml file that needs to be checked.

admin commented

@greg0ire commented on GitHub (Dec 13, 2023):

OK, well, let's take a look at the first error found by @yard-mschwartz I guess…

complex type 'sql-result-set-mapping': The content model is not determinist.

It refers to this: 2b91edc525/doctrine-mapping.xsd (L146-L156)

Let's try to get more info on that error, maybe from the PR that introduced it? There should be a commit labeled "regexp: Fix determinism checks" in libxml.

EDIT: here is the commit, couldn't find a PR for it: a06eaa6119

Related issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/624

I wonder if this could be caused by the <xs:any tags in the schema… given their name, they sound like they could allow anything. If somebody with the error can try removing them and see if they still get the error about sql-result-set-mapping, that would help.

@greg0ire commented on GitHub (Dec 13, 2023): OK, well, let's take a look at the first error found by @yard-mschwartz I guess… `complex type 'sql-result-set-mapping': The content model is not determinist.` It refers to this: https://github.com/doctrine/orm/blob/2b91edc525bde4f23f9ada22a82c021b5c18c92b/doctrine-mapping.xsd#L146-L156 Let's try to get more info on that error, maybe from the PR that introduced it? There should be a commit labeled "regexp: Fix determinism checks" in libxml. EDIT: here is the commit, couldn't find a PR for it: https://github.com/GNOME/libxml2/commits/a06eaa6119ca5b296b8105dc8c9a34ed5fc1f338 Related issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/624 I wonder if this could be caused by the `<xs:any` tags in the schema… given their name, they sound like they could allow anything. If somebody with the error can try removing them and see if they still get the error about `sql-result-set-mapping`, that would help.

admin commented

@mbabker commented on GitHub (Dec 13, 2023):

[root@host ~]# ea-php82 -i | grep libxml
[...snip...]
libxml Version => 2.12.2
libxml
libxml2 Version => 2.12.2
libxslt compiled against libxml Version => 2.9.1

Linked files as they are now:

[root@host ~]# ea-php82 parse.php 
<pre>array(5) {
  [0]=>
  object(LibXMLError)#2 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(77) "complex type 'sql-result-set-mapping': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(146)
  }
  [1]=>
  object(LibXMLError)#3 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(72) "complex type 'mapped-superclass': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(227)
  }
  [2]=>
  object(LibXMLError)#4 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(65) "complex type 'embeddable': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(238)
  }
  [3]=>
  object(LibXMLError)#5 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(66) "complex type 'many-to-one': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(561)
  }
  [4]=>
  object(LibXMLError)#6 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(65) "complex type 'one-to-one': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(579)
  }
}
</pre>

After commenting the <xs:any tag in the sql-result-set-mapping type:

[root@host ~]# ea-php82 parse.php 
<pre>array(4) {
  [0]=>
  object(LibXMLError)#2 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(72) "complex type 'mapped-superclass': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(227)
  }
  [1]=>
  object(LibXMLError)#3 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(65) "complex type 'embeddable': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(238)
  }
  [2]=>
  object(LibXMLError)#4 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(66) "complex type 'many-to-one': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(561)
  }
  [3]=>
  object(LibXMLError)#5 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(3070)
    ["column"]=>
    int(0)
    ["message"]=>
    string(65) "complex type 'one-to-one': The content model is not determinist.
"
    ["file"]=>
    string(26) "/root/doctrine-mapping.xsd"
    ["line"]=>
    int(579)
  }
}
</pre>

So, yes, it does appear to be related to those tags and the issue reported by @shyim with Shopware's XSD at least looks somewhat related.

It's not all of the any's, either. This passes for sql-result-set-mapping:

  <xs:complexType name="sql-result-set-mapping">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:choice minOccurs="0" maxOccurs="unbounded">
            <xs:element name="entity-result" type="orm:entity-result"/>
            <xs:element name="column-result" type="orm:column-result"/>
            <!-- <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"/> -->
        </xs:choice>
        <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"/>
    </xs:choice>
    <xs:attribute name="name" type="xs:string" use="required" />
  </xs:complexType>

@mbabker commented on GitHub (Dec 13, 2023): ```sh [root@host ~]# ea-php82 -i | grep libxml [...snip...] libxml Version => 2.12.2 libxml libxml2 Version => 2.12.2 libxslt compiled against libxml Version => 2.9.1 ``` Linked files as they are now: ```sh [root@host ~]# ea-php82 parse.php <pre>array(5) { [0]=> object(LibXMLError)#2 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(77) "complex type 'sql-result-set-mapping': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(146) } [1]=> object(LibXMLError)#3 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(72) "complex type 'mapped-superclass': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(227) } [2]=> object(LibXMLError)#4 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(65) "complex type 'embeddable': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(238) } [3]=> object(LibXMLError)#5 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(66) "complex type 'many-to-one': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(561) } [4]=> object(LibXMLError)#6 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(65) "complex type 'one-to-one': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(579) } } </pre> ``` After commenting the `<xs:any` tag in the `sql-result-set-mapping` type: ```sh [root@host ~]# ea-php82 parse.php <pre>array(4) { [0]=> object(LibXMLError)#2 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(72) "complex type 'mapped-superclass': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(227) } [1]=> object(LibXMLError)#3 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(65) "complex type 'embeddable': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(238) } [2]=> object(LibXMLError)#4 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(66) "complex type 'many-to-one': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(561) } [3]=> object(LibXMLError)#5 (6) { ["level"]=> int(2) ["code"]=> int(3070) ["column"]=> int(0) ["message"]=> string(65) "complex type 'one-to-one': The content model is not determinist. " ["file"]=> string(26) "/root/doctrine-mapping.xsd" ["line"]=> int(579) } } </pre> ``` So, yes, it does appear to be related to those tags and the issue reported by @shyim with Shopware's XSD at least looks somewhat related. It's not all of the any's, either. This passes for `sql-result-set-mapping`: ```xml <xs:complexType name="sql-result-set-mapping"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="entity-result" type="orm:entity-result"/> <xs:element name="column-result" type="orm:column-result"/>  </xs:choice> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other"/> </xs:choice> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> ```

admin commented

2026-01-22 15:48:58 +01:00

@greg0ire commented on GitHub (Dec 13, 2023):

This is worrying: https://www.xml.com/axml/notes/Determinism.html
This is a bit more understandable: https://www.xml.com/axml/target.html#determinism

Translating the original sql-result-set-mapping into english, I think it says that when you have a tag sql-result-set-mapping, then you can must have a name attribute, and then inside you can have one of:

entity-result
column-result
anything else, as many times as you want
again, anything else, as many times as you want?

If you try commenting out the other any, and not the first, does it also pass? If yes, this might mean that when you put something that isn't entity-result or column-result in there, it doesn't know whether it should validated that against the first any, or the second one?

@greg0ire commented on GitHub (Dec 13, 2023): This is worrying: https://www.xml.com/axml/notes/Determinism.html This is a bit more understandable: https://www.xml.com/axml/target.html#determinism Translating the original `sql-result-set-mapping` into english, I think it says that when you have a tag `sql-result-set-mapping`, then you can must have a `name` attribute, and then inside you can have one of: - `entity-result` - `column-result` - anything else, as many times as you want - again, anything else, as many times as you want? If you try commenting out the other `any`, and not the first, does it also pass? If yes, this might mean that when you put something that isn't `entity-result` or `column-result` in there, it doesn't know whether it should validated that against the first `any`, or the second one?

admin commented

@shyim commented on GitHub (Dec 13, 2023):

When you know exactly which elements will be inside the XML I would get rid of the xsd:any. In our case it was allowed to add custom elements which were not described in the xsd.

@shyim commented on GitHub (Dec 13, 2023): When you know exactly which elements will be inside the XML I would get rid of the `xsd:any`. In our case it was allowed to add custom elements which were not described in the xsd.

admin commented

2026-01-22 15:48:58 +01:00

@greg0ire commented on GitHub (Dec 14, 2023):

Looking at the repository history, I can find this commit by myself: 12babcc1c2

This is interesting as well: https://github.com/doctrine-extensions/DoctrineExtensions/issues/2613

@greg0ire commented on GitHub (Dec 14, 2023): Looking at the repository history, I can find this commit by myself: 12babcc1c24759002605057b79e5bc6f93e3bf0a This is interesting as well: https://github.com/doctrine-extensions/DoctrineExtensions/issues/2613

admin commented

@mbabker commented on GitHub (Dec 14, 2023):

Yeah, there's a whole chain of issues on the DoctrineExtensions repo about the XML mappings and validation issues in general, which to my understanding of https://github.com/doctrine-extensions/DoctrineExtensions/issues/2055 haven't even worked with the MongoDB ODM for years since they went strict on their schema and totally disallowed extending like the ORM had allowed.

@mbabker commented on GitHub (Dec 14, 2023): Yeah, there's a whole chain of issues on the DoctrineExtensions repo about the XML mappings and validation issues in general, which to my understanding of https://github.com/doctrine-extensions/DoctrineExtensions/issues/2055 haven't even worked with the MongoDB ODM for years since they went strict on their schema and totally disallowed extending like the ORM had allowed.

admin commented

@greg0ire commented on GitHub (Dec 15, 2023):

A way out of this would be to make the default schema stricter (remove all the xs:any), so that it validates, and then allow defining custom schemas: https://github.com/doctrine/orm/issues/11123

@greg0ire commented on GitHub (Dec 15, 2023): A way out of this would be to make the default schema stricter (remove all the `xs:any`), so that it validates, and then allow defining custom schemas: https://github.com/doctrine/orm/issues/11123

admin commented

@AlbanDeveloppeur commented on GitHub (Dec 20, 2023):

Hello ! I've got the same issue, and I don't understand how to solve it. I've tried what I've seen here, but nothing changes. The problem appeared when I tried to upgrade my Project from Symfony 6.3 to 6.4. My libxml version is 2.9.1

@AlbanDeveloppeur commented on GitHub (Dec 20, 2023): Hello ! I've got the same issue, and I don't understand how to solve it. I've tried what I've seen here, but nothing changes. The problem appeared when I tried to upgrade my Project from Symfony 6.3 to 6.4. My libxml version is 2.9.1

admin commented

@yard-mschwartz commented on GitHub (Dec 21, 2023):

Hi @AlbanDeveloppeur, from our current understanding the problem should only occur with libxml 2.12 onwards. Are you sure it's the same issue? Perhaps the error is the same, but the cause is different (e.g. you're not using friendsofsymfony/user-bundle)

@yard-mschwartz commented on GitHub (Dec 21, 2023): Hi @AlbanDeveloppeur, from our current understanding the problem should only occur with libxml 2.12 onwards. Are you sure it's the same issue? Perhaps the error is the same, but the cause is different (e.g. you're not using `friendsofsymfony/user-bundle`)

admin commented

2026-01-22 15:49:00 +01:00

@AlbanDeveloppeur commented on GitHub (Dec 22, 2023):

I work with
Symfony : 6.4.1
PHP : 8.2.10
doctrine/orm : 2.17.2
vich/uploader-bundle : 2.3.0
libxml : 2.9.1

Summary
Hello ! To update my issue from this comment : https://github.com/doctrine/orm/issues/11117#issuecomment-1864457851

In the development environnement I have this error message when I try to use php bin/console cache:clear

Warning: DOMDocument::schemaValidate(): Invalid Schema

And when I'm in production environnement, I have this error message :

In MappingException.php line 1004:

libxml error: complex type 'mapped-superclass': The content model is not determinist.
in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd atline 227

libxml error: complex type 'embeddable': The content model is not determinist.
in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd at line 238

libxml error: complex type 'many-to-one': The content model is not determinist.
in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd at line 561

libxml error: complex type 'one-to-one': The content model is not determinist.
in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd at line 579

So for now, it seems to be the same problem you've discovered here.

After a lot of manipulations, I tried to delete some vendors. And after deleting vich/uploader-bundle, both errors in the development and production environment have disappeared and I can do php bin/console cache:clear again.

I don't know why this vendor created this type of issue, but in my case, deleting this vendor solved my problem.

@AlbanDeveloppeur commented on GitHub (Dec 22, 2023): **I work with** Symfony : 6.4.1 PHP : 8.2.10 doctrine/orm : 2.17.2 vich/uploader-bundle : 2.3.0 libxml : 2.9.1 **Summary** Hello ! To update my issue from this comment : https://github.com/doctrine/orm/issues/11117#issuecomment-1864457851 In the development environnement I have this error message when I try to use `php bin/console cache:clear` ``` Warning: DOMDocument::schemaValidate(): Invalid Schema ``` And when I'm in production environnement, I have this error message : ``` In MappingException.php line 1004: libxml error: complex type 'mapped-superclass': The content model is not determinist. in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd atline 227 libxml error: complex type 'embeddable': The content model is not determinist. in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd at line 238 libxml error: complex type 'many-to-one': The content model is not determinist. in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd at line 561 libxml error: complex type 'one-to-one': The content model is not determinist. in /home/admin/preprod/vendor/doctrine/orm/doctrine-mapping.xsd at line 579 ``` So for now, it seems to be the same problem you've discovered here. After a lot of manipulations, I tried to delete some vendors. And after deleting `vich/uploader-bundle`, both errors in the development and production environment have disappeared and I can do `php bin/console cache:clear` again. I don't know why this vendor created this type of issue, but in my case, deleting this vendor solved my problem.

admin commented

@greg0ire commented on GitHub (Dec 22, 2023):

It does seem to be the same error. How did you determine the libxml version? I think looking at the output of php -i might be the right way to do this in case it's possible to have several different versions on your system

@greg0ire commented on GitHub (Dec 22, 2023): It does seem to be the same error. How did you determine the libxml version? I think looking at the output of `php -i` might be the right way to do this in case it's possible to have several different versions on your system

admin commented

2026-01-22 15:49:00 +01:00

@aratinau commented on GitHub (Dec 26, 2023):

Hello
I have exactly the same problem, the only bundle I added is symfonycasts/verify-email-bundle

@aratinau commented on GitHub (Dec 26, 2023): Hello I have exactly the same problem, the only bundle I added is `symfonycasts/verify-email-bundle`

admin commented

2026-01-22 15:49:00 +01:00

@danielsreichenbach commented on GitHub (Dec 28, 2023):

Using PHP 8.2.14 (compiled against libxml 2.12.0) with a Symfony 7 app.

This issue basically renders Symfony unusable. You can not use make:entity or any other Doctrine workflow.

Can confirm though that the removal of xsd:any from doctrine-mapping.xsd makes things work again.

@danielsreichenbach commented on GitHub (Dec 28, 2023): Using PHP 8.2.14 (compiled against libxml 2.12.0) with a Symfony 7 app. This issue basically renders Symfony unusable. You can not use `make:entity` or any other Doctrine workflow. Can confirm though that the removal of `xsd:any` from `doctrine-mapping.xsd` makes things work again.

admin commented

@mbabker commented on GitHub (Dec 28, 2023):

Don't use 2.12.0 or 2.12.1, those versions had bugs causing PHP to segfault. https://github.com/php/php-src/issues/12847

@mbabker commented on GitHub (Dec 28, 2023): Don't use 2.12.0 or 2.12.1, those versions had bugs causing PHP to segfault. https://github.com/php/php-src/issues/12847

admin commented

@justpilot commented on GitHub (Dec 31, 2023):

php -i | grep libxml

libxml Version => 2.12.3
libxml
libxml2 Version => 2.12.3

php -v
PHP 8.2.14 (cli) (built: Dec 21 2023 14:02:51) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.14, Copyright (c) Zend Technologies

pacman -Ss libxml

core/libxml2 2.12.3-1 [installed]
    XML C parser and toolkit

extra/libxmlb 0.3.14-1 [installed]
    Library to help create and query binary XML blobs

extra/python-lxml 4.9.2-3 [installed]
    Python3 binding for the libxml2 and libxslt libraries

As far as I know the version 2.12.3 should run fine, but it produces the same error.

@justpilot commented on GitHub (Dec 31, 2023): ``` php -i | grep libxml libxml Version => 2.12.3 libxml libxml2 Version => 2.12.3 ``` ``` php -v PHP 8.2.14 (cli) (built: Dec 21 2023 14:02:51) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.14, Copyright (c) Zend Technologies ``` ``` pacman -Ss libxml core/libxml2 2.12.3-1 [installed] XML C parser and toolkit extra/libxmlb 0.3.14-1 [installed] Library to help create and query binary XML blobs extra/python-lxml 4.9.2-3 [installed] Python3 binding for the libxml2 and libxslt libraries ``` As far as I know the version 2.12.3 should run fine, but it produces the same error.

admin commented

@greg0ire commented on GitHub (Dec 31, 2023):

As far as I know the version 2.12.3 should run fine

2.12.3 might not have the segmentation fault, but I see no reason why it would no longer have the schema validation error.

@greg0ire commented on GitHub (Dec 31, 2023): > As far as I know the version 2.12.3 should run fine 2.12.3 might not have the segmentation fault, but I see no reason why it would no longer have the schema validation error.

admin commented

@danielsreichenbach commented on GitHub (Jan 7, 2024):

Can confirm 2.12.3 still causes the schema validation error. Only remedy still remains xsd:any change.

@danielsreichenbach commented on GitHub (Jan 7, 2024): Can confirm `2.12.3` still causes the schema validation error. Only remedy still remains `xsd:any` change.

admin commented

2026-01-22 15:49:02 +01:00

@japodhidev commented on GitHub (Jan 12, 2024):

Don't really know if this is a fix or just some cheat. I've had this problem which seems to be originating from gesdinet/jwt-refresh-token-bundle . I came across https://github.com/doctrine-extensions/DoctrineExtensions/issues/2613 which suggested setting validate_xml_mapping: false. This seemed to fix my issue.

Some probably useful info:

$ php -i | grep libxml
libxml Version => 2.12.3
libxml
libxml2 Version => 2.12.3
libxslt compiled against libxml Version => 2.12.0

$ php -v
PHP 8.2.14 (cli) (built: Dec 21 2023 14:02:51) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.14, Copyright (c), by Zend Technologies
    with Xdebug v3.2.2, Copyright (c) 2002-2023, by Derick Rethans

A little excerpt from my composer.json

{
    "require": {
        "php": "^8.1.0",
        "doctrine/orm": "^2.18|^3",
        "gesdinet/jwt-refresh-token-bundle": "^1.1"
     }
}

I'm on Symfony version 6.4.2. Hope this sheds some light or possibly helps someone someway.

@japodhidev commented on GitHub (Jan 12, 2024): Don't really know if this is a fix or just some cheat. I've had this problem which seems to be originating from `gesdinet/jwt-refresh-token-bundle` . I came across [https://github.com/doctrine-extensions/DoctrineExtensions/issues/2613](2613) which suggested setting `validate_xml_mapping: false`. This seemed to fix my issue. Some probably useful info: ```sh $ php -i | grep libxml libxml Version => 2.12.3 libxml libxml2 Version => 2.12.3 libxslt compiled against libxml Version => 2.12.0 ``` ```sh $ php -v PHP 8.2.14 (cli) (built: Dec 21 2023 14:02:51) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.14, Copyright (c) Zend Technologies with Zend OPcache v8.2.14, Copyright (c), by Zend Technologies with Xdebug v3.2.2, Copyright (c) 2002-2023, by Derick Rethans ``` A little excerpt from my `composer.json` ```json { "require": { "php": "^8.1.0", "doctrine/orm": "^2.18|^3", "gesdinet/jwt-refresh-token-bundle": "^1.1" } } ```` I'm on Symfony version `6.4.2`. Hope this sheds some light or possibly helps someone someway.

admin commented

@mbabker commented on GitHub (Jan 12, 2024):

Don't really know if this is a fix or just some cheat.

It's a cheat. That validate_xml_mapping setting disables the XML schema validation, preventing the error in this thread from being triggered in the first place. And IIRC, that setting is no-op'd with ORM 3 and XML validation is always required.

@mbabker commented on GitHub (Jan 12, 2024): > Don't really know if this is a fix or just some cheat. It's a cheat. That `validate_xml_mapping` setting disables the XML schema validation, preventing the error in this thread from being triggered in the first place. And IIRC, that setting is no-op'd with ORM 3 and XML validation is always required.

admin commented

2026-01-22 15:49:02 +01:00

@IndraGunawan commented on GitHub (Jan 15, 2024):

still facing DOMDocument::schemaValidate(): Invalid Schema error on libxml2 from HEAD commit

php -i | grep libxml 
libxml Version => 2.13.0
libxml
libxml2 Version => 2.13.0

php -v
PHP 8.3.1 (cli) (built: Jan 15 2024 23:10:16) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.1, Copyright (c) Zend Technologies

@IndraGunawan commented on GitHub (Jan 15, 2024): still facing `DOMDocument::schemaValidate(): Invalid Schema` error on libxml2 from HEAD commit ``` php -i | grep libxml libxml Version => 2.13.0 libxml libxml2 Version => 2.13.0 ``` ``` php -v PHP 8.3.1 (cli) (built: Jan 15 2024 23:10:16) (NTS) Copyright (c) The PHP Group Zend Engine v4.3.1, Copyright (c) Zend Technologies ```

admin commented

@greg0ire commented on GitHub (Jan 15, 2024):

@IndraGunawan why do you expect it to be fixed?

@greg0ire commented on GitHub (Jan 15, 2024): @IndraGunawan why do you expect it to be fixed?

admin commented

@sophoniie commented on GitHub (Jan 15, 2024):

I have the same issue cause by : vich/uploader-bundle

@sophoniie commented on GitHub (Jan 15, 2024): I have the same issue cause by : `vich/uploader-bundle`

admin commented

@IndraGunawan commented on GitHub (Jan 15, 2024):

why do you expect it to be fixed?

@greg0ire the issue was on libxml, is it? or xsd file needs some changes?

i downgraded libxml2 to 2.11.6 and compile the PHP 8.3.1. i don't see invalid schema error

php -i | grep libxml            
libxml Version => 2.11.6
libxml
libxml2 Version => 2.11.6

@IndraGunawan commented on GitHub (Jan 15, 2024): > why do you expect it to be fixed? @greg0ire the issue was on libxml, is it? or xsd file needs some changes? i downgraded libxml2 to 2.11.6 and compile the PHP 8.3.1. i don't see `invalid schema` error ``` php -i | grep libxml libxml Version => 2.11.6 libxml libxml2 Version => 2.11.6 ```

admin commented

@greg0ire commented on GitHub (Jan 15, 2024):

the issue was on libxml

Why are you using the past tense? The issue still exists. Because of new libxml versions that are stricter since libxml 2.12, the XSD file is now considered invalid, and will need some changes, yes.

@greg0ire commented on GitHub (Jan 15, 2024): > the issue was on libxml Why are you using the past tense? The issue still exists. Because of new libxml versions that are stricter since libxml 2.12, the XSD file is now considered invalid, and will need some changes, yes.

admin commented