yes! this is an incompatibility.
I was able to devote some time to the problem, also because l'extra "ACE" is my "code editor" preferred.
Apparently the 5.3 is more strict, in the treatment and control of text under interpretation online.
Surely this concept will be very boring for an experienced programmer like you, but may be useful to others and, above all eliminates the BUG in ACE
under PHP 5.3
in the code of your plugin, there's something not really like, to the new PHP.
But this can have a quick fix solution, knowing that the javascript will need braces.
view "$mydata"
With a concatenation of supertext:
$modx->regClientStartupScript('<script type="text/javascript">'."
// <![CDATA[
Ext.onReady(function() {
var TextArea = Ext.getCmp('{$field}');
var CodeArea = MODx.load({
xtype: 'modx-codearea',
anchor: TextArea.anchor,
width: 'auto',
height: TextArea.height,
name: TextArea.name,
value: TextArea.getValue(),
mode: '{$mode}'
});
TextArea.el.dom.name = '';
TextArea.el.setStyle('display', 'none');
CodeArea.render(TextArea.el.dom.parentNode);
CodeArea.on('change', function(e){TextArea.fireEvent('keydown', e);});
});
Ext.apply(MODx.lang, { ".$mydata."});
// ]]>
".'</script>', true);
Not associated with an interpretation:
$modx->regClientStartupScript('<script type="text/javascript">'."
// <![CDATA[
Ext.onReady(function() {
var TextArea = Ext.getCmp('{$field}');
var CodeArea = MODx.load({
xtype: 'modx-codearea',
anchor: TextArea.anchor,
width: 'auto',
height: TextArea.height,
name: TextArea.name,
value: TextArea.getValue(),
mode: '{$mode}'
});
TextArea.el.dom.name = '';
TextArea.el.setStyle('display', 'none');
CodeArea.render(TextArea.el.dom.parentNode);
CodeArea.on('change', function(e){TextArea.fireEvent('keydown', e);});
});
Ext.apply(MODx.lang, { ${$mydata}});
// ]]>
".'</script>', true);
It is very important, the space between the first parentisi and the dollar sign!
SI NO
There are also other solutions concatenation, but they increase the running time.
But all this only serves to not generate javascript errors, the error was actually generated in the "method" "modLexicon :: fetch" but not because of the role, if not because of the data to be processed.
Banal as corrupt data in your file "default.inc.php"
![]()
What this is?
$_lang['ui_ace.message_replaced'] = 'Ïðîèçâåëîñü çàìåí: [[+count]].';
and I thought, write bad English
$_lang['ui_ace.message_replaced'] = 'Changed: [[+count]].';
If it is demonstrated that the earlier versions of PHP simply generate an error, returning a "big white" (display_errors == 0), and the new version tries to overcome the error, through everything you read, and that in other passages the program causes errors of interpretation, parsing, etc
I think that's a good practice in any case, generating a model code "assert"
or replace the errors with "empty valid" in this way:
$lang = $modx->toJSON($modx->lexicon->fetch('ui_ace'));
$lang = ($lang)?$lang:'{ }';
...
$modx->regClientStartupScript('<script type="text/javascript">'."
// <![CDATA[
Ext.onReady(function() {
var TextArea = Ext.getCmp('{$field}');
var CodeArea = MODx.load({
xtype: 'modx-codearea',
anchor: TextArea.anchor,
width: 'auto',
height: TextArea.height,
name: TextArea.name,
value: TextArea.getValue(),
mode: '{$mode}'
});
TextArea.el.dom.name = '';
TextArea.el.setStyle('display', 'none');
CodeArea.render(TextArea.el.dom.parentNode);
CodeArea.on('change', function(e){TextArea.fireEvent('keydown', e);});
});
Ext.apply(MODx.lang, $lang);
// ]]>
".'</script>', true);
take this opportunity to congratulate you for the development of the extra "ACE" is an indispensable component for who writes much code directly on the server.
Greetings.
PS. I hope you will later take more seriously the signs of bugs.
In my humble opinion: what makes it useful open source projects, is the dialogue between developers and users
