View Issue Details

IDProjectCategoryView StatusLast Update
0007014OXID eShop (all versions)4.09. SEO, SEO URLpublic2019-08-01 12:31
Reporters.sadowski 
PriorityhighSeveritymajorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version6.1.1 
Target VersionFixed in Version 
Summary0007014: Second page of article list doesn't load via SEO
DescriptionWhen trying to view second page of a custom type of article list via SEO URL (e.g. "/Sanitaer/2/") articles from first page are being displayed. The bottom-page pagination also shows first page as being active, even though second page link, and the currently opened URL both correctly point at the second page.
The corresponding `oxseo` DB table entry contains the appropriate URL params:
 SELECT * FROM oxseo WHERE oxseourl = 'Sanitaer/2/'\G
*************************** 1. row ***************************
 OXOBJECTID: e83bc6f13d80fec4062b185a4b51f0b9
    OXIDENT: 930bf46348cbf0859c211872ae379a77
   OXSHOPID: 1
     OXLANG: 0
   OXSTDURL: index.php?cl=tc_b2b_item_list_product_group&id=e83bc6f13d80fec4062b185a4b51f0b9&pgNr=1
   OXSEOURL: Sanitaer/2/
     OXTYPE: tc_product_group
    OXFIXED: 0
  OXEXPIRED: 0
   OXPARAMS: 2/
OXTIMESTAMP: 2019-07-30 09:41:23

However, looking at the logic of \OxidEsales\EshopCommunity\Core\SeoDecoder::decodeUrl() I noticed a few things. Firstly, page number is extracted from the SEO URL correctly using `SeoDecoder::extractPageNumberFromSeoUrl()` - as a result I'm getting the base URL ("Sanitaer/") and the correct page number (1 - "2" taken from the SEO link and decreased by one). Afterwards however `oxseo` table entry is fetched by key (oxident) which is generated from the base URL only, so the returned entry will be the same for all pages of that product group, which should be OK, because the page number should be added to the parsed URL parameters. Unfortunately that's not the case - in the core SeoDecoder class, line 79, we can see the condition, under which page number is added to the URL params array:
if (is_array($urlParameters) && !is_null($pageNumber) && (1 < $pageNumber))

As you can see, the last part of this condition (1 < $pageNumber) is actually not met for $pageNumber=1, which is the case for the second page. Changing that condition to (0 < $pageNumber) in an extension has resolved the issue.
TagsSEO
ThemeOther
BrowserNot defined
PHP VersionNot defined
MySQL VersionNot defined

Activities

There are no notes attached to this issue.