I think I traced the issue down to the `filter_var($value, FILTER_SANITIZE_STRING);` we're doing everywhere…

That will remove everything it thinks is a tag. So everything between an opening '<' and either the text-end or a closing '>'

Is is safe to skip the `filter_var`entirely? Or do a different filter? We should be fine from SQLInjections due to PDO and prepared statements. And the end user should be safe due to either submitting JSON (and putting the burden of escaping onto the consumer) or (once) escaped HTML…

Due to the fact that the tags are removed they are lost in the DB so there's nothing we can fix at that point IMO.

Ideas?

There's certainly an inconsistency somewhere which is resulting in html escaped characters ending up in the database.

As a result there's a few things to look at:

1. fixing data in the db that's already escaped & needs unescaping
2. ensuring that escaped data is never stored
3. ensuring that html rendering next double escapes
4. ensuring that html rendering always escapes once

And the other question is: How did the escaped Ampersand end up in the database in the first place. Might that be an issue with legacy?

I couldn't test that this morning due to being redirected to web2 on login for legacy on the new box 🙂 I'll investigate that though…

Ok, fine by me 🙂

I'd see it the same way as Rob. We're returning JSON (usually and in that special case anyway) and since "&" and "<" arent't special characters there IMHO there's no need to escape them.

Different story when returning HTML!