View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001214 | OXID eShop (all versions) | 4.06. Language and translations | public | 2009-08-18 11:36 | 2009-08-24 16:24 |
| Reporter | andreas_ziethen | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 4.1.4 revision 21266 | ||||
| Summary | 0001214: strange language SEO urls - caused due to new "feature" | ||||
| Description | Today switching a shop from EE 4.0.1.0 to 4.1.4 I noticed very strange language SEO URLs, like this: www.shop.de/en-oxid/en-oxid/en-oxid/mycategory/myarticle.html All the language URLs had that strang stuff in it. After hours of debugging I finally noticed that obviously in version 4.1.2 there was an important change in oxseoencoder which is NOWHERE documented! The change was to implement a new function _getReservedEntryKeys() which replaces the old functionality about reserved keys for seo urls in the admin interface. This is VERY annoying because: - a change like this HAS to be documented!! - the old admin interface is still there but useless - entries in there are not recognized any longer - the new function now takes all directory names in the shop root folder and declares them es "reserved keys" for seo urls. My customer has got some language dependent subdirs in the shop root, named "en", "fr", "it", "es" etc. - and THAT lead to the above mentioned strange URLs. So please guys: if you do such important changes - please DOCUMENT THEM!! :-( | ||||
| Tags | No tags attached. | ||||
| Theme | |||||
| Browser | All | ||||
| PHP Version | 5.2.6 | ||||
| Database Version | 5.0.33 | ||||
|
|
This is not a "feature" - its a way to avoid problems with SEO urls. E.g. you have category "forum" and subfolder "/forum", where third party software is installed. If we will not check for this during SEO url generation "forum" category and its articles will not be accessible. I believe that many customers will not check for such cases and call to support until this problem will be cleared up. As I remember, there was a discussion about removed language abbreviations from URLs, so these were returned back to shop. Maybe such behaviour occured because some left workarounds for this fix with language abbrevations? |
|
|
Reminder sent to: andreas_ziethen please review our reply |
|
|
Thank you for your hints. For sure we will include such behaviors in documentation in future. |
