I can confirm this in version 2.2.5.
Clearly an escaping issue…
<?phpn/**n * …
The malformed html is present in the database table filemeta so it’s getting mangled on “commit”.
Problem isolated:
the problem is that on commit the code calls func
add_file_meta which then calls built-in func
add_metadata
– this function uses func wp_unslash on the passed in value.
wp_unslash removes escape slashes like in
O\'Brian >> O'Brian
So our poor newlines are being converted to “n”
2 newlines next \n\nNewline here >> newline next nnNewline here
…aaaanyway
the simple fix for this is to not use esc_sql in function ajax_commit_file as subsequent call to add_metadata sanitizes input anyhow, it’s a bit redundant:
$file_content = /**esc_sql**/($_POST['file_content']);
Adrian, thanks for the fix. I would have never figured that out myself. Working properly now!
@adrian, I just restored a theme file that had strings with escaped characters. Upon restoration, the file was messed up due to my escaped characters getting unescaped… I know you mentioned “wp_unslash” earlier which must be the culprit.
In your opinion, is this normal behavior? How can this be avoided?
It can easily be avoided, but I don’t think the author cares. The plugin is clearly incomplete in it’s realization. I stopped using it. Idea: The data could be stored using base64_encode/decode to avoid all these issues.
You’re best going to the author for a proper fix…
