Back in 0.x, I believe JNeuhoff led the resistance against storing the descriptions in specialchars and preferred to store the actual html tags in the database. I also agreed that it made more sense and we made this change in 0.7.9. It looks like that change was never adopted into early 1.x so it never happened here. It would make much more sense to store the data in a proper format so that multiple consumers could reuse the data directly from the db in a standardized format without having to encode/decode.
But I too get confused by the way POSTing stuff gets passed around and automatically gets encoded. In this case, if you trace the post with liveheader monitoring, you can see that the webpage does indeed post the html for the description field:
But then when the controller has it in the $_POST field, the HTTP protocol or PHP engine appears to have encoded it automatically:
And that is simply passed as-is to the model function to save.
You could run htmlspecialchars_decode on the data right before the db inserts it by
1. EDIT: admin/model/catalog/product.php
2. FIND (2 INSTANCES):
Code: Select all
description = '" . $this->db->escape($value['description'])
3. REPLACE BOTH WITH:
Code: Select all
description = '" . $this->db->escape(htmlspecialchars_decode($value['description']))
That will save it to the database in proper html format.
Interestingly, I figured since I decoded it on the way in, I would need to re-encode it on the way out, otherwise it would display funny.. but again some magic appears to be working that it doesn't try to double decode. So with that above change alone, that might be all that is needed. Maybe I've overlooked something but it seems to be working correctly with just that change AND it is stored nicely in the db.
).
