search

ezyang / htmlpurifier

Standards compliant HTML filter written in PHP
http://htmlpurifier.org
GNU Lesser General Public License v2.1
3.07k stars 327 forks source link

Made PSR-0 loading more standards-conform #253

Closed roelofr closed 4 years ago

roelofr commented 4 years ago

Although the class won't break anything when Composer 2.0 seizes to load the en-x-test file, it's causing deprecations all over the board. This would be easily solvable by letting the Composer autoloader take care of it, but with the wide range of autoloaders used, and the custom autoloader in the tests, this won't do.

This solves it by checking the HTMLPurifier/Languages directory for our class, after HTMLPurifier/Languages/clases/ doesn't contain it and the class isn't already loaded. It adds some extra logic, but in the 99% use-case this won't see any real impact.

The old structure has preference, for backwards compatibility.

Closes #246.

FabianKoestring commented 4 years ago

👍

FabianKoestring commented 4 years ago

The Issue #246 could easily be fixed by renaming the class from HTMLPurifier_Language_en_x_test to en_x_test. It is not compatible with the filename. Thats all 😁😨

roelofr commented 4 years ago

It's not compatible with the LanguageFactory when you change it like that though, which will cause issues for those not using en as language.

https://github.com/ezyang/htmlpurifier/blob/7e2d7054d85b07cd14c640def7fe211241e2328c/library/HTMLPurifier/LanguageFactory.php#L107-L110

roelofr commented 4 years ago

Although a rewrite is good, since its non-standard, the deprecation warning was fixed in 4faca32a4d4b8152d17956606e1fb5043fcc1f10.

ezyang commented 4 years ago

Yeah, this isn't worth it. Would be better to just remove localization support. I'd accept a PR that did that.