Falscher Link bei Artikelliste in CMS-Seite

Hallo!

Ich habe eine CMS-Seite als Kategorie eingerichtet.
In dieser CMS-Seite rufe ich eine Artikelliste auf:

[{include file="widget/product/list.tpl" type="grid" listId="productList" products=$oView->getTop5ArticleList()}] 

Wenn ich diese Seite nun aufrufe, erscheint auch die Produktsliste, aber ein Klick auf “In den Warenkorb” ruft die Startseite auf.

Wenn ich statt dessen den Listtype “line” auswähle, erscheint die Impressumseite.

Hat das Problem schon jemand gesehen? Gibt’s n Fix?

Landet der Artikel denn überhaupt im Warenkorb? Gibt es Fehlermeldungen im Exception-Log?

Ja, der Artikel landet im Warenkorb.
Nein, es gibt keine Fehlermeldungen im Exception-Log.

Komisch. Steht beim Aufruf der Startseite dann redirected=1 in der URL?
Die Impressumseite wird angezeigt, falls der content-Controller ohne oxloadid aufgerufen wurde: https://github.com/OXID-eSales/oxideshop_ce/blob/v4.9.3/source/application/controllers/content.php#L300

Nein, kein “redirected=1”.

Das Problem war/ist, dass in diesem Konstrukt (Produktliste in CMS-Seite), die Funktion

$oView->getLink()

den Parameter “cl” nicht setzt. Der ist zwar vorhanden, aber leer.

Beim Listtype “line” wird der Controller-Parameter korrekt gesetzt, dafür aber die “oxloadid” nicht…

Ich habe mir nun so beholfen, das ich in der Listenansicht prüfe, ob der aktuelle Controller “content” ist und in diesem Fall den Parameter “oxloadid” setze.

[{if $oViewConf->getActiveClassName() == 'content'}]
  [{*}] Wir sind auf einer CMS-Seite, hier muss die oxloadid übergeben werden! [{*}]
  <input type="hidden" name="oxloadid" value="[{$oContent->oxcontents__oxloadid->value}]" />
[{else}]
  [{*}] Wir sind auf normalen Artikelliste, hier muss die anid (?) übergeben werden! [{*}]
  <input type="hidden" name="anid" value="[{if $altproduct}][{$altproduct}][{else}][{$product->oxarticles__oxnid->value}][{/if}]">
[{/if}]

Für die Gridansicht habe ich den Warenkorb-Link durch ein Formular ersetzt, welches ebenfalls nach dem o.g. Prinzip arbeitet.

Dabei habe ich mich auch gefragt, wieso die Aktion “In den Warenkorb” eigentlich ein normaler Link ist. Dadurch folgt doch Google allen Warenkorblinks auf allen Produktlisten und legt fröhlich Artikel in den Warenkorb… :confused:

Dass Robots Artikel in den Warenkorb legen, sollte eigentlich nicht passieren. Dafür sind im Shop extra Abfragen vorhanden:


/**
     * Basket content update controller.
     * Before adding article - check if client is not a search engine. If
     * yes - exits method by returning false. If no - executes
     * oxcmp_basket::_addItems() and puts article to basket.
     * Returns position where to redirect user browser.
     *
     * @param string $sProductId Product ID (default null)
     * @param double $dAmount    Product amount (default null)
     * @param array  $aSel       (default null)
     * @param array  $aPersParam (default null)
     * @param bool   $blOverride If true means increase amount of chosen article (default false)
     *
     * @return mixed
     */
    public function tobasket($sProductId = null, $dAmount = null, $aSel = null, $aPersParam = null, $blOverride = false)
    {
        // adding to basket is not allowed ?
        $myConfig = $this->getConfig();
        if (oxRegistry::getUtils()->isSearchEngine()) {
            return;
        }

@martin.wegele:

if (oxRegistry::getUtils()->isSearchEngine()) {
return;
}

funktioniert nur bedingt. Z.B. wird ‘ShopWiki’ nicht erkannt oder ‘feedlybot’ oder noch schlimmer die crawler, die sich nicht zu erkennen geben!
M.E. darf der Warenkorb niemals über GET gefüllt werden

[QUOTE=patchwork.de;157879]M.E. darf der Warenkorb niemals über GET gefüllt werden[/QUOTE]

Ausserdem ist Browsersniffing nicht wirklich updatefreundlich.
Was passiert, wenn der Googlebot seinen Useragent ändert?

Der Fix ist ja nun auch nicht wirklich komplex.

Und das funktioniert? Wenn ich den Code in eine CMS Seite eingebe, passiert rein gar nichts.
Schade, da hätte ich grundlegend Interesse dran.