tinymce uses php open tag which can crash visual editor when server is set to parse JS files for PHP

[oldbucsfan]

When apache is set to parse .js files for PHP (needed in some cases), it causes tinymce.min.js to return a 500 error. This is because one part of the file uses a php open tag "<?":

pi:function(e,t){t?r.push("<?",e," ",s(t),"?>"):r.push("<?",e,"?>"),i&&r.push("\n")}

It would be best if this part of the file was written so that it would not return a 500 error if .js files are parsed for PHP. A simple fix:

pi:function(e,t){t?r.push("<"+"?",e," ",s(t),"?"+">"):r.push("<"+"?",e,"?"+">"),i&&r.push("\n")}

[johnbillion]

What's your use case for parsing JS files as PHP? This sounds like something you definitely shouldn't be doing.

[oldbucsfan]

Creating custom content through javascript based on a logged in user's group. PHP can read the session data and modify the javascript accordingly.

[oldbucsfan]

Also, it is useful to ensure a user is logged in through PHP (session data) before serving a javascript file that contains sensitive data. In some instances, javascript needs to contain sensitive data. Requiring that the user is logged in and has correct permissions with PHP before serving the file is a useful tool in such a situation since it can't be handled client side.

[swissspidy]

It's worth noting that the minified tinymce.min.js file is directly obtained from upstream, ​https://www.tinymce.com/.

Besides that, I agree with johnbillion. If the JS output depends on PHP, you should add that part as an inline script instead.

[oldbucsfan]

Inline is a great solution when you have an isolated piece of code, but when many pages call the same code, it is inefficient to have each page contain it's own code.

The only real solutions are to parse .js files or to change your javascript files to .php files and use the appropriate header to let the browser know it is actually a javascript file.

It seems to me that the small change would simply be a good way to go to prevent any potential problems with php, but it may be too rare a situation to warrant a change.

[azaozz]

Agree with @johnbillion that this shouldn't be done. Also as @swissspidy mentions above the <? comes from upstream and depends on the JS minifier. There is little we can do about it.

The WordPress way of doing something like that is to output an object with the private information then use that in the "standard" script, the same way translated strings work.

Closing as wontfix, feel free to reopen with some examples if there is an edge case that cannot be handled in any other way.