All descriptions etc., that are maintained in Admin via the HTML editor appear in the database as though HTMLSSpecialcharacters (which I only found out about this morning before I sound too clever) has been called, although it never is.
For example:
<p><strong>Product</strong></p>
is stored as:
<p><strong>Product</strong></p>
Is saving as HTML or Special Characters an editor option?
Would I have a problem if I ran a query to replace all '<' to '<' and '>' to '>' in all description fields?
Is it possible to make HTML data save as raw HTML tags?
or can anyone plug the gap in my ignorance as to what I should be doing?!
The object is to manage HTML content from a Back-Office system through ODBC.
Free v1.4.9 Extensions: Default Specials | Improved Search | Customer Activity Report | Customer Groups | Royal Mail With Handling | Improved Product Page | Random Products | Stock Report | All Products
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'])
Code: Select all
description = '" . $this->db->escape(htmlspecialchars_decode($value['description']))
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.
I just added a product and used htmlspecialchars_decode (two new keywords in one day!) so the data is stored as html. When it comes to viewing the product on the website or loading them into ckeditor, neither seems to care less whether it is stored as html or special characters.
If something was stored as specialcharacters, I would have expected products to show on the website with literal tags (eg. '<b><u>Product Name</u></b>').
Reverting, when I edit an (html) product in ckeditor and save it, it is special characters again but the website doesn't care either way.
I need to lie down for a bit.
Free v1.4.9 Extensions: Default Specials | Improved Search | Customer Activity Report | Customer Groups | Royal Mail With Handling | Improved Product Page | Random Products | Stock Report | All Products
I'm just as stumped as you in this case... the internets still hold some secret magic that even I don't understand... but perhaps this is a gift horse... and I'm not going to look it in the mouth (wow our societal phrases really make no sense)mystifier wrote:Very confusing!
I just added a product and used htmlspecialchars_decode (two new keywords in one day!) so the data is stored as html. When it comes to viewing the product on the website or loading them into ckeditor, neither seems to care less whether it is stored as html or special characters.
If something was stored as specialcharacters, I would have expected products to show on the website with literal tags (eg. '<b><u>Product Name</u></b>').
Reverting, when I edit an (html) product in ckeditor and save it, it is special characters again but the website doesn't care either way.
I need to lie down for a bit.
<p>text</p>
It's useful but crazy; I just don't get it ?!!?
Free v1.4.9 Extensions: Default Specials | Improved Search | Customer Activity Report | Customer Groups | Royal Mail With Handling | Improved Product Page | Random Products | Stock Report | All Products
Code: Select all
$_GET = $this->clean($_GET);
$_POST = $this->clean($_POST);
$_REQUEST = $this->clean($_REQUEST);
$_COOKIE = $this->clean($_COOKIE);
$_FILES = $this->clean($_FILES);
$_SERVER = $this->clean($_SERVER);
Code: Select all
public function clean($data) {
if (is_array($data)) {
foreach ($data as $key => $value) {
unset($data[$key]);
$data[$this->clean($key)] = $this->clean($value);
}
} else {
$data = htmlspecialchars($data, ENT_COMPAT);
}
return $data;
}
Automatic encode really confused me here and I if I remember correctly the good practice was storing the data as it originally was. If requests get encoded, storing/fetching gets tricky and if different ways of inserting/modifying the data get used, one can end up with a mess of encoded/unencoded characters like the last poster here.
Hmmm, wouldn't that be you? OR are you referring to !the last poster here
Ok, jokes aside, looks like somebody who coded that in had an idea of securing data being entered into the db through the catalog side. Then forgot about that class and then had to deal with the situation since it was a mystery.
Anyway, what would be the best way to clean up the mess?
Move everything to the class or weed out the base controllers?
And no, I'm not particularly interested in leaving it up to the end user since most will have no clue about securing this.
But if this was in the class, then you could have switches to pass to allow you to change on the fly like the SSL links do.
IMHO, CFKEditer is F!keditor ... I bet there is a bunch of cleaning or what not going on inside that huge baggage code.
930sc ... because it is fun!
I tried to modify the db methods escape() and query() (walking through $query->rows and $query->row) in order not to have htmlspecialchars in db tables. The problem is that we need to know also which are the serialize fields (they are not only in the setting table only)
The proper approach to the problem is:
1. never to use htmlspecialchars encoded data in db, just db/sql escaped data;
2. escape data in html output and form field values not the get / post data itself
That would mean minor changes in the request class (getting rid of the clean() method), but would also mean changing all controllers classes in both catalog and admin applications (because OC does not use escaping functions in tpl and the model classes is not the proper place to do that).
Anyway , it's a change that should be done along with reverting all tables to utf8_general_ci ....
As far as fckeditor goes, i noticed that values are doubled escaped like & => &
Maks Feltrin
Or simply use the JSON POST calls which has already been improved since v1.5x releases. One example to see would be the commission value assigned to the orders from the admin when either adding / removing values.That would mean minor changes in the request class (getting rid of the clean() method), but would also mean changing all controllers classes in both catalog and admin applications (because OC does not use escaping functions in tpl and the model classes is not the proper place to do that).
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
&lt;div class=&quot;cpt_product_description &quot;&gt;\r\n\t&lt;div&gt;\r\n\t\t&lt;p&gt;&lt;span style=&quot;color: rgb(153, 153, 153); font-family: Lato; font-size: 14px; font-weight: bold;&quot;&gt;
Users browsing this forum: No registered users and 105 guests