View Issue Details

Jump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0007174OXID eShop (all versions)4.09. SEO, SEO URLpublic2020-09-11 11:032020-09-14 14:02
ReporterHelmut L. Assigned To 
PrioritynormalSeverityminorReproducibilityunable to reproduce
Status closedResolutionopen 
Product Version6.2.2 
Summary0007174: wrong SEO URLs for pages if first page has no SEO URL
DescriptionIf 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 ReproduceI'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 InformationTo solve this the check for $sParams in /vendor/oxid-esales/oxideshop-ce/source/Core/SeoEncoder.php on line 534 must be removed.
TagsNo tags attached.
ThemeNot defined
BrowserNot defined
PHP VersionNot defined
Database VersionNot defined

Activities

QA

2020-09-11 12:07

administrator   ~0013290

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

Best regards

QA - SG -

Helmut L.

2020-09-11 12:53

reporter   ~0013291

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.

QA

2020-09-11 14:25

administrator   ~0013292

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?

Best regards

QA - SG -

Helmut L.

2020-09-11 14:40

reporter   ~0013293

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.

michael_keiluweit

2020-09-14 12:38

administrator   ~0013295

Hello Helmut,

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
- https://localhost/test
- https://localhost/test/
- https://localhost/test/3
- https://localhost/test/7
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.

Greetings
Michael (QA)

Helmut L.

2020-09-14 13:55

reporter   ~0013296

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.