View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003346 | OXID eShop (all versions) | 4.09. SEO, SEO URL | public | 2011-11-02 13:04 | 2012-12-10 13:34 |
| Reporter | csimon | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Product Version | 4.5.4 revision 39463 | ||||
| Fixed in Version | 4.5.6 revision 40808 | ||||
| Summary | 0003346: SEO URLs defined in admin are saved with htmlentities | ||||
| Description | As described. This is not really clean because the htmlentities aren't really a part of a proper URL and if you want to fetch some seo url with "&" in it, you wonder why you don't get the URL. | ||||
| Steps To Reproduce | Define a SEO URL for a view in admin with &-signs in it. oxseo.oxstd url will contain the url with & instead of & | ||||
| Tags | No tags attached. | ||||
| Theme | Both | ||||
| Browser | All | ||||
| PHP Version | any | ||||
| Database Version | any | ||||
|
|
I mean 'amp; sign instead of a & sign. The bugtracker has eaten that. |
|
|
all dynamic URLs in database are stored this way - & character is translated into html entity, so if you need plain URL - use use html_entity_decode() function. In future we plan to implement special object, who keeps/transforms URLs according your needs, so you will be able to fetch save (encoded) URLs and decoded.. So it's not a bug.. |
|
|
According to http://tools.ietf.org/html/rfc3986 & is an control character and therefore the seo urls with 'amp; signs are wrong. I cannot test it now, but if you would call the encoded url from the database for example with curl, the url would be wrong and the request would fail. The HTML Encoding has nothing to do with the url standard and is only for display purposes, so it should at least be corrected in a later version that the urls aren't saved in the wrong format anymore. |
|
|
Normally URL's are used in templates (html) and & character should be transformed into entity (or HTML validator will tell that we have badly formatted HTML). When URL's are used for redirection to another page - we usually process them and replace entities with resp. characters. Also - as now we do not have any specific object/class responsible for URL formatting (something like oxField and its getValue()/getRawValu()) so we must ensure that data is safe for use in HTML and we came to idea, that we will keep data in DB converted into entities. As soon as we implement class (probably already in next major release) responsible for formatting, you will have both - plain and encoded values. |
|
|
Also - we cant just change code now and make everywhere straight & instead of entity. That would lead to many incompatibilities with third party modules and shop itself. So - id call this change MAJOR and would really like to keep current solution until next major release. |
