View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007174||OXID eShop (all versions)||4.09. SEO, SEO URL||public||2020-09-11 11:03||2020-09-14 14:02|
|Priority||normal||Severity||minor||Reproducibility||unable to reproduce|
|Target Version||Fixed in Version|
|Summary||0007174: wrong SEO URLs for pages if first page has no SEO URL|
|Description||If you have a SEO URL for the page of a category in your DB: /test-category/2/|
but none for the first page of that category: /test-category/
all additional SEO URLs that are created for the category use /test-category/2/ as base SEO URL
That is because the _loadFromDb method only checks for the oxparams column if $sParams isn't empty. But for the main URL of a category the oxparams column is empty. Thus in this situation the URL for the second page, which has "2" as oxparams, is returned.
This results in URLs like /test-category/2/3/ for the other pages, because the URL of the second page is returned as main URL and then the page number is added to the URL.
For the first page this is even worse, because for the first page you always get the URL of the second page returned and thus can no longer access the first page.
|Steps To Reproduce||I'm not exactly sure how it happened that a later page got a SEO URL before the first page got a SEO URL, but I have multiple such categories in the shop.|
I guess you create a category with multiple pages and then access one of the later pages first.
|Additional Information||To solve this the check for $sParams in /vendor/oxid-esales/oxideshop-ce/source/Core/SeoEncoder.php on line 534 must be removed.|
|Tags||No tags attached.|
|PHP Version||Not defined|
|Database Version||Not defined|
Dear Helmut L.,
i cannot reproduce your report.
1. I set up a new OXID 6.2.2 shop with demodata.
2. I created a new categorie and added all articles.
3. I called the url testshop.de/test-categorie/5
and this call was successfull.
if i understand your report correct this should fail?
I also read the possibility, that you created a categorie named " 2 ".
Please see this bug-report: https://bugs.oxid-esales.com/view.php?id=6928
QA - SG -
||The call to testshop.de/test-categorie/5 should be successful. But afterwards there should be no URL testshop.de/test-categorie/ in the oxseo table. Thus when the shop tries to create the SEO URLs for the other pages it will use testshop.de/test-categorie/5 as the base URL.|
Dear Helmut L.,
I repeated steps 1-3 and as 4th step:
4. I call testhop.de/test-categorie
Still there is not such behavior.
Could you please try to reproduce the behavior on a clean installation?
If you create a categorie through the backend, there is automatically a entry in SEO URL.
Could you please double check if you have a entry in the tab seo?
Also to check:
Are there any modules related to SEO generation?
Do you import categories somehow?
QA - SG -
As I wrote, I'm not exactly sure how it happened that the SEO URL for the first page is missing, but the SEO URLs for the later pages are there.
I guess the easiest way to replicate it would be to directly delete the SEO URL of the first page from the oxseo table.
The bug here is not the missing URL for the first page, but that the _loadFromDb method doesn't check for an empty params column if it gets empty $sParams string passed.
I investigated further into this topic and I think a misunderstanding of the SEO handling happened here.
The core statement is: The SEO page number is not saved with the SEO URLs in the table oxseo, nor even respected by the SEO handling.
Let me explain this a bit further:
The page numbers are only important for the class \OxidEsales\EshopCommunity\Application\Component\Locator, which creates them (https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/Application/Component/Locator.php#L108). Beyond that the shop doesn't need them. That means also, page numbers are not stored in the oxseo table. So you only find entries without a page number in your oxseo table, like this for example:
OXTYPE, OXSEOURL oxarticle, test/Kite-Leinen-VECTOR-QUAD-PRO.html oxarticle, test/Kite-FLYSURFER-SPEED3.html oxarticle, test/KiteFix-Kleber-GLUFIX-30g.html oxcategory, test/ oxarticle, test/Stickerset-MIX.html oxarticle, test/Neoprenschuh-ION-BALLISTIC-SLIPPER-1-5.html oxarticle, test/Kite-LIQUID-FORCE-HAVOC.html oxarticle, test/Transportcontainer-THE-BARREL.html oxarticle, test/Kite-CORE-RIOT-XR.html oxarticle, test/Kuyichi-T-Shirt-TIGER.html oxarticle, test/Set-O-BRIEN-VICE.html oxarticle, test/Kite-RRD-PASSION.html
There will be no "test/2" or "test/3" SEO URLs.
When I delete the oxseo url with the type category "test/", then no other url is callable, because the shop can't find it anymore. This counts for
That is, because the page number is grabbed from the request url, extracted from the string and handled separately: https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/Core/SeoDecoder.php#L70
After the page number was extracted the shop has two variables: $seoUrl and $pageNumber. The variable $seoUrl does not hold any kind of page navigation information stuff. It's a page number less string which then gets MD5 hashed and searched for in the database.
As long as there are no page numbers in the table oxseohistory, the system works. Of course: When I add manually the string /2 to my seo url in the database test/ (=test/2/) and I call the page (test/2/3) then it will not work and I will receive a 404 page. But when I click on a link of the category (https://localhost/test/2 [remember, this is the root seo url for the category test, as I changed it manually in the table oxseo]) then it works. It works because the shop does this: http://localhost/test/2/?pgNr=4
As you can see, the shop adds itself the GET parameter pgNr, when it generates the link. So the shop understands both ways: the pgNr parameter and a simply integer at the end of the url. But both needs a working Encoder class underneath it, which creates SEO URLs by ignoring / without a page number.
The table field oxparams can hold different things. When an article from a category is saved, then the category oxid is saved into the field oxparams, for example.
I hope this made it more clear. I recommend to check if the shop has any customization to handle SEO URLs. Maybe the Locator was adapted to not use the GET parameter, but only integers.
Thanks for the explanation,
The problem was really related to a module, which still used the old logic of storing SEO URLs with page numbers.
This issue can now be closed.