search

manu37 / tinymce4

tinymce4_XH - tinyMCEv4 for CMSimple_XH
GNU General Public License v3.0
1 stars 3 forks source link

The editor fails to initialize if there are files with umlauts in userfiles/downloads/ #16

Closed cmb69 closed 7 years ago

cmb69 commented 7 years ago

Depending on the file system encoding, the OS and PHP version and the PHP configuration, there are issues with non UTF-8 compatible characters in file names in userfiles/downloads/. For instance, often a file named töst.pdf may cause get_internal_links() to return false, because XH_encodeJson() fails, and that causes include_tinymce4() to generate invalid JS.

manu37 commented 7 years ago

Ok, got it. Might be hard to get a setup to reproduce. In this setup there might be a bunch of other problems to arise. The best would be to prevent naming with non-ascii characters. The fix in the next release would be to throw an error message with json_last_error.

cmb69 commented 7 years ago

Might be hard to get a setup to reproduce.

An existing userfiles/downloads/töst.txt should reproduce the problem on Windows with PHP 7.0 and older, because NTFS stores filenames in UTF-16 or UCS-2 or some variant thereof, and PHP only allows to do semi-automatic conversion as of 7.1.

The best would be to prevent naming with non-ascii characters.

I'd rather see the problems with non ASCII characters fixed, see cmsimple-xh/cmsimple-xh#272.

The fix in the next release would be to throw an error message with json_last_error.

As an alternative you may consider to write the JSON error instead of the filenames for the selectbox.

manu37 commented 7 years ago

interesting solution, thks. In fact that this is a rare problem, we accept that there isn't any error msg for this case. I would have run it into an json_error and show JSON_LAST_ERROR instead of show nothing. Because this fail might become tricky. Not every non utf8 filename fails on JSON.

manu37 commented 7 years ago

OK, I agree. It is better to show what we have instead of throwing an error and show nothing. In the system requirements we should state that we assume utf8 charset even on filesystem and -content. Does it make sense to check php_info("default_charset")?

cmb69 commented 7 years ago

Does it make sense to check php_info("default_charset")?

I don't think so. Frankly, I think default_charset shouldn't relied upon at all, particularly as it's actual usage depends on the PHP version. I prefer to specify the "charset" for the relevant functions explicitly.