I'm really restricted on space, so I wanted to present a counter point on today's funcaday: Performance.
The disadvantage with the escape for now, not for later approach is simple. If you save a user's post to the database, then that user's post is displayed 2,000 times there will be some serious differences. Under the approach I reccomend the post will be escaped with mysql_real_escape_string() once, and with htmlentiteis() 2,000 times. If you had escaped it twice in the first place those functions would have been called once each, saving you 1,999 calls to htmlentities.
You will need to balance your security concerns with performance needs.
Note: This blog post was written well in advance, I'm on vacation, don't have my laptop or internet, and it's likely that my cell phone won't even turn on. So replies may be a bit tardy.
Note^2: But I'm not dumb, someone's looking after my server
The disadvantage with the escape for now, not for later approach is simple. If you save a user's post to the database, then that user's post is displayed 2,000 times there will be some serious differences. Under the approach I reccomend the post will be escaped with mysql_real_escape_string() once, and with htmlentiteis() 2,000 times. If you had escaped it twice in the first place those functions would have been called once each, saving you 1,999 calls to htmlentities.
You will need to balance your security concerns with performance needs.
Note: This blog post was written well in advance, I'm on vacation, don't have my laptop or internet, and it's likely that my cell phone won't even turn on. So replies may be a bit tardy.
Note^2: But I'm not dumb, someone's looking after my server
Comments »
That 2000 htmlentities calls are nothing compared to the 2000 queries that you are doing, so indeed, make sure you cache properly.
Doing htmlentities before it goes into the database makes your database data very html centric. If you ever switch to publishing to other mediums, that will be slightly more difficult.
Doing htmlentities before it goes into the database makes your database data very html centric. If you ever switch to publishing to other mediums, that will be slightly more difficult.
I agree with the last comments, I prefer to have raw data in the database available to do whatever I want with, then cache as necessary.
I think you made a good point. However, one of PHPs strengths is rapid prototyping. It is totally aligned with the open source mantra "release early, release often". PHP allows you to release an application as early as possible and grow it from there. The business is happy because there's no need to wait forever to launch a website or to release an application.
As you get traffic, there are a bunch of ways optimize. One of them is caching. You can cache on the htmlspecialchars() level by storing the result of htmlspecialchars() in a separate caching field in the database (besides storing the unescaped values for searching and other purposes).
It usually turns out however that caching is not the most efficient on the htmlspecialchars() level but on upper levels like the caching of whole blocks on a page. I think this is why the efficiency of htmlspecialchars() is not really an issue. From the technology point of view it is, but from the POV of a business, it doesn't really worth to spend your precious time and attention on it.
As you get traffic, there are a bunch of ways optimize. One of them is caching. You can cache on the htmlspecialchars() level by storing the result of htmlspecialchars() in a separate caching field in the database (besides storing the unescaped values for searching and other purposes).
It usually turns out however that caching is not the most efficient on the htmlspecialchars() level but on upper levels like the caching of whole blocks on a page. I think this is why the efficiency of htmlspecialchars() is not really an issue. From the technology point of view it is, but from the POV of a business, it doesn't really worth to spend your precious time and attention on it.
I believe in "best of both worlds" - save the raw and escaped versions 
Then if you need to edit the original or change mediums, you can do it, but still don't have to call htmlentities 2000 times...
Then if you need to edit the original or change mediums, you can do it, but still don't have to call htmlentities 2000 times...
In Today's Funcaday (http://funcaday.com/displayEntry.php?id=81), you spelled definition wrong, twice. That is, you used two completely different incorrect spellings. If you want to be taken seriously, you have to at least use spell check.
I use htmlspecialchars instead of htmlspecialentities and do not experience any problems. The only mistake that can catch you is calling this twice - before putting data into database and after. Just avoid it
Paul Reinheimer, one of two behind the funcaday website (providing details ...
Tracked: Jan 07, 14:14