View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002819||OXID eShop (all versions)||4.09. SEO, SEO URL||public||2011-05-03 08:56||2012-12-10 13:34|
|Product Version||4.5.0 revision 34568|
|Target Version||Fixed in Version||4.5.1 revision 38045|
|Summary||0002819: article url generation without active category generates link in random category|
|Description||if no actual category is defined (like in searchresults, startpage, or in the admin), the function |
oxseoencoderarticle -> _getArticleUri
returns a SEO URL, which points to the article in a random of its category. (not the main category!)
|Steps To Reproduce||demodata 4.5:|
- in admin, open article 2103 (wakeboard groove)
- pull a bunch of categories into the article (jeans, for her, for him, ...)
- remove the former main category (wakeboards)
- set one of the middle new categories as main category
- open seo tab in the same article
- empty seo-url field and click save
-> the generated seo url points to one of the new categories, but not to the new main-category. (should it actually point to the main-cat, it was by accident. Retry after setting a different main-cat. )
--> what happens here is that the _getArticleUri function is called within the _getAltUri function. Because no actcat is defined, it calls _getfromdb without params-parameter and so it selects the first seo-entry it finds.
The same thing happens whenever you get an articles url from a place without a category and you are not explicitly calling getMainUrl
|Additional Information||to fix:|
- return "" if $oActCat is undef
in _getAltUri, following the same logic as in getArticleUrl:
- call _getArticleMainUri if $sSeoUrl is empty after the switch block
|Tags||No tags attached.|
||The problem was, that in start page template oxArticle::getLink() was used instead of oxArticle::getMainLink().|
If you just modified the start.tpl, the issue is not fixed.
Did you try out my described steps to reproduce?
The issue is not template specific.
The problem is in the function _getArticleUri, which returns the first selected seo-link from oxseo wihout checking the oxparams.
Yes, i agree, just your change may require interface change also, so do you still thing we should do this in next patch? According you our policy we should postpone this refactoring level change to next major release..
In "basic" theme oxArticle::getMainLink() is used in places which you found working wrong.
since very few shops (if any at all) are using 4.5 azure right now, wouldnt it be okay to put this change into the current development version?
to the interface-changes:
it dont think, there are any neccessary, because:
- whereever mainlink is/was used, there is no problem anyway
- otherwise, when a wrong seo-url exists for a product (and it is not set to expired), it works furtheron, so no problem here too.
- when a seo-url is changed and recalculated after this fix, the old seo-url still exists in history and will be redirected to the new url.
so, yes - i would suggest to fix this in the next patch.