2.1 Issue with JS

I had another issue with my 2.1 install that might be worth a patch in the next release:

after installation the manager was not displaying the resources tree + other oddities; Firebug console reported a javascript error in ext-all.js

missing ) in parenthetical
<b>Strict Standards</b>: Redefining a...class.php</b> on line <b>75</b>

I then looked in MODx Error Logs (under Reports tab) and found a PHP warning referencing the same ’75’ line:

(ERROR @ /modx/core/model/modx/moduser.class.php : 159) PHP warning: Cannot modify header information - headers already sent by (output started at /modx/core/model/modx/registry/modregister.class.php:75)

I suspected that the HTML-string generated by the Warning, was being passed unescaped to the Javascript, causing some kind of injection because of a missing ’)’, hence I tried adding an .htaccess with:

php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off

in ’/modx/core/model/modx/registry/’ (did not work),
in ’/modx/core/model/modx/’ (did not work)
in the modx root -> SUCCESS, the manager returned fully functional.

I think the double header issue between the 2 modx classes should be cleaned, furthermore an ’htmlspecialchars’ is missing somewhere in your PHPs, or maybe the equivalent javascript escaping function should be in ext-all.js

Congrats on the release!

This is a STRICT standards bug in the modRegister class. Thanks for the details and I’ll get it fixed for 2.1.1 — http://bugs.modx.com/issues/4884

Quote from: OpenGeek at May 27, 2011, 12:56 PM

This is a STRICT standards bug in the modRegister class. Thanks for the details and I’ll get it fixed for 2.1.1 — http://bugs.modx.com/issues/4884

Great, but this only solves the issue for that particular warning; I think the interaction between PHP warning/error_messages in general and their effects in extJS is still a potential failure point for the manager UI: the warning/errors strings should be escaped.
I understand that they are probably generated by Apache and managed in extJS/Sencha, as such the miss-behaviour I experienced is not caused by any MODx code; so it might be necessary to forward it in the extJS bugtracker, or try to include extJS 4 in the MODx Revo distribution in place of the currenly included version (3.3.1).

unfortunately, replacing extjs3 by extjs4 is not trivial in this case.

yep... good luck with reading http://www.sencha.com/blog/ext-js-3-to-4-migration/ !