Page MenuHomePhabricator

`Error: Class "Wikimedia\Parsoid\Wt2Html\XMLSerializer" not found` in PHPUnit tests
Closed, ResolvedPublic

Event Timeline

Change #1144710 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

https://gerrit.wikimedia.org/r/1144710

There is a class_alias, but Composer doesn't support generating autoload data for class aliases, so the class is not loaded when the alias is used.

Change #1144710 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

https://gerrit.wikimedia.org/r/1144710

Change #1144715 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@wmf/1.45.0-wmf.1] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

https://gerrit.wikimedia.org/r/1144715

Ugh, needs backporting.

@matmarex I can't figure out if this is an actual blocker for 1.45.0-wmf.1. Is the fix required to sync deploy 1.45.0-wmf.1 to prod?

Zabe triaged this task as Unbreak Now! priority.May 13 2025, 10:11 AM
Zabe subscribed.

looking at logstash

Planning to backport this as soon as I've dealt with other deployment issues

Change #1144715 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@wmf/1.45.0-wmf.1] Update for Parsoid's rename of XMLSerializer to XHtmlSerializer

https://gerrit.wikimedia.org/r/1144715

Mentioned in SAL (#wikimedia-operations) [2025-05-13T10:18:58Z] <jnuche@deploy1003> Started scap sync-world: Backport for [[gerrit:1144715|Update for Parsoid's rename of XMLSerializer to XHtmlSerializer (T393983)]]

Mentioned in SAL (#wikimedia-operations) [2025-05-13T10:26:19Z] <jnuche@deploy1003> matmarex, jnuche: Backport for [[gerrit:1144715|Update for Parsoid's rename of XMLSerializer to XHtmlSerializer (T393983)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-05-13T10:35:36Z] <jnuche@deploy1003> Finished scap sync-world: Backport for [[gerrit:1144715|Update for Parsoid's rename of XMLSerializer to XHtmlSerializer (T393983)]] (duration: 16m 38s)

Errors are no longer showing up in the logs

There is a class_alias, but Composer doesn't support generating autoload data for class aliases, so the class is not loaded when the alias is used.

This answer doesn't quite make sense to me. We've done class_alias before in libraries, (eg 301b9150416ce6efa970caa61a149b77d7fd3378) and it didn't break production. The class_alias was on a PSR-4 path and should have been loaded as library code. Why didn't this work (and why did it work before?) and what would have been the "right" way to do this?

The missing piece of the puzzle is the fact that in the mediawiki/vendor repo, composer.json uses "classmap-authoritative": true:

This makes composer not use PSR-4 autoloading, but instead generate a map of all classes it knows about to the files that define them, and only load files from this list. In the vendor patch https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/1144664, if you look at the relevant files (I don't know which of the two is used in production), the entry for XMLSerializer is removed:


I am not sure why the previous times this did not break production. I see that in 301b91… (https://gerrit.wikimedia.org/r/c/mediawiki/libs/RemexHtml/+/731867), there was another entry in "autoload", and the class_alias calls were in the same files as the real classes; maybe one of those things, or both combined, made it work.

(sent too early) As for the "right" way to solve this, I think there isn't really one, but there are workarounds:

  • Just list all of the aliases explicitly in "autoload" in your composer.json. At that point it's probably easier to also keep the class_alias in the same file as the real class. This shouldn't be too bad if you don't have many of them.
  • Do this silly thing, which I just accidentally found by codesearching for "classmap-authoritative". I suppose this fake class definition makes Composer find it when generating its classmap. I wonder if it breaks Phan or IDEs…

Change #1145344 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/services/parsoid@master] Fix XMLSerializer alias

https://gerrit.wikimedia.org/r/1145344

Change #1145344 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Fix XMLSerializer alias

https://gerrit.wikimedia.org/r/1145344

Change #1147810 had a related patch set uploaded (by Jgiannelos; author: Jgiannelos):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a3

https://gerrit.wikimedia.org/r/1147810

Change #1147810 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a3

https://gerrit.wikimedia.org/r/1147810

Change #1162957 had a related patch set uploaded (by Jgiannelos; author: Jgiannelos):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a3

https://gerrit.wikimedia.org/r/1162957

Change #1162957 abandoned by Jgiannelos:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a3

https://gerrit.wikimedia.org/r/1162957