OXID-Bug bei Bestellung

Habe bei OXID ein Problem entdeckt, und im Debugger nachvollzogen.

Das Problem tritt auf, wenn man ein Produkt mit Lagerbestand „1“ in den Warenkorb legt und bestellt.

Die Bestellung wird dann ganz normal ausgeführt, da das Produkt ja verfügbar ist.

Dann kommt OXID aber bei „Thankyou“ in‘s schleudern, weil dort geprüft wird, ob das Produkt noch kaufbar ist (um evtl. den Admin zu benachrichtigen, dass der Artikel nicht mehr da ist).

Was er jetzt aber nicht mehr ist, da der Lagerbestand mittlerweile “Null” ist.

Und dann schaltet OXID (eigentlich ohne Not!) den Shop einfach offline (Verzweigung auf “offline.html”)…

Diesen Zustand könnte der Shop aber einfach ignorieren, dann wäre das Produkt [COLOR=Red]künftig einfach nicht mehr bestellbar….

[/COLOR]Das ist der Ablauf, der zum Problem führt:
(Leider wird an der Stelle das “Exception-Log” nicht gefüllt, so dass ich hier den Inhalt es “Exception-Objects” im Debugger zeigen muss.)

 Object
(
    [_sArticleNr:protected] => 8370e67b7e2ef46be18a2292ad3f9032
    [_sFileName:protected] => EXCEPTION_LOG.txt
    [_blRenderer:protected] => 
    [_blNotCaught:protected] => 
    [message:protected] => EXCEPTION_ARTICLE_ARTICELNOTBUYABLE
    [string:private] => 
    [code:protected] => 0
    [file:protected] => H:\Apache Group\Apache\htdocs\oxid\core\oxutilsobject.php
    [line:protected] => 127
    [trace:private] => Array
        (
            [0] => Array
                (
                    [file] => H:\Apache Group\Apache\htdocs\oxid\core\oxfunctions.php
                    [line] => 267
                    [function] => oxNew
                    [class] => oxUtilsObject
                    [type] => ->
                    [args] => Array
                        (
                            [0] => 
                            [1] => 
                        )

                )

            [1] => Array
                (
                    [file] => H:\Apache Group\Apache\htdocs\oxid\core\oxbasketitem.php
                    [line] => 419
                    [function] => oxNew
                )

            [2] => Array
                (
                    [file] => H:\Apache Group\Apache\htdocs\oxid\core\oxemail.php
                    [line] => 951
                    [function] => getArticle
                    [class] => oxBasketItem
                    [type] => ->
                    [args] => Array
                        (
                            [0] => 
                        )

                )

            [3] => Array
                (
                    [file] => H:\Apache Group\Apache\htdocs\oxid\views	hankyou.php
                    [line] => 160
                    [function] => sendStockReminder
                    [class] => oxEmail
                    [type] => ->
                    [args] => Array
                        (
                        )

                )

            [4] => Array
                (
                    [file] => H:\Apache Group\Apache\htdocs\oxid\views\oxshopcontrol.php
                    [line] => 262
                    [function] => render
                    [class] => Thankyou
                    [type] => ->
                    [args] => Array

Das Problem entsteht in “oxbasketitem” in dieser Routine:

    public function getArticle( $sProductId = null )
    {
        if ( $this->_oArticle === null ) {
            $sProductId = $sProductId ? $sProductId : $this->_sProductId;
            if ( !$sProductId ) {
                //this excpetion may not be caught, anyhow this is a critical exception
                $oEx = oxNew( 'oxArticleException' );
                $oEx->setMessage( 'EXCEPTION_ARTICLE_NOPRODUCTID' );
                throw $oEx;
            }

            $this->_oArticle = oxNew( 'oxarticle' );

            // performance:
            // - skipping variants loading
            // - skipping 'ab' price info
            // - load parent field
            $this->_oArticle->setNoVariantLoading( true );
            $this->_oArticle->setSkipAbPrice( true );
            $this->_oArticle->setLoadParentData( true );
            if ( !$this->_oArticle->load( $sProductId ) ) {
                $oEx = oxNew( 'oxNoArticleException' );
                $oEx->setMessage( 'EXCEPTION_ARTICLE_ARTICELDOESNOTEXIST' );
                $oEx->setArticleNr( $sProductId );
                throw $oEx;
            }

            // cant put not buyable product to basket
            if ( !$this->_oArticle->isBuyable() ) {
                $oEx = oxNew( 'oxArticleInputException' );
                $oEx->setMessage( 'EXCEPTION_ARTICLE_ARTICELNOTBUYABLE' );
                $oEx->setArticleNr( $sProductId );
                throw $oEx;
            }
        }

        return $this->_oArticle;
    }

Für diese beiden Situationen darin muss eine bessere Lösung gefunden werden, als einfach aufzuhören, indem eine “Exception” erzwungen wird, die dann den Shop auf “offline” schaltet…

        if ( !$this->_oArticle->load( $sProductId ) ) {
            $oEx = oxNew( 'oxNoArticleException' );
            $oEx->setMessage( 'EXCEPTION_ARTICLE_ARTICELDOESNOTEXIST' );
            $oEx->setArticleNr( $sProductId );
            throw $oEx;
        }
        // cant put not buyable product to basket
        if ( !$this->_oArticle->isBuyable() ) {
            $oEx = oxNew( 'oxArticleInputException' );
            $oEx->setMessage( 'EXCEPTION_ARTICLE_ARTICELNOTBUYABLE' );
            $oEx->setArticleNr( $sProductId );
            throw $oEx;
        }

https://bugs.oxid-esales.com/view.php?id=1276
Ist eigentlich schon gefixt.
https://bugs.oxid-esales.com/changelog_page.php

Hatte auch damit Probleme, seit den Update gehts.

[QUOTE=MBa;15860]https://bugs.oxid-esales.com/view.php?id=1276
Ist eigentlich schon gefixt.
https://bugs.oxid-esales.com/changelog_page.php

Hatte auch damit Probleme, seit den Update gehts.[/QUOTE]
Prima, 4.1.6 hat das dann wohl nicht mehr…

Mal schauen, wie das gelöst ist…

Auszug aus 4.1.6:

            if ( $blCheckProduct && !$this->_oArticle->isVisible() ) {
                $oEx = oxNew( 'oxNoArticleException' );
                $oLang = oxLang::getInstance();
                $oEx->setMessage( sprintf($oLang->translateString( 'EXCEPTION_ARTICLE_ARTICELDOESNOTEXIST', $oLang->getBaseLanguage() ), $this->_oArticle->oxarticles__oxartnum->value) );
                $oEx->setArticleNr( $sProductId );
                $oEx->setProductId( $sProductId );
                throw $oEx;
            }

            // cant put not buyable product to basket
            if ( $blCheckProduct && !$this->_oArticle->isBuyable() ) {
                $oEx = oxNew( 'oxArticleInputException' );
                $oEx->setMessage( 'EXCEPTION_ARTICLE_ARTICELNOTBUYABLE' );
                $oEx->setArticleNr( $sProductId );
                $oEx->setProductId( $sProductId );
                throw $oEx;
            }

Na ja, für diesen Fall scheint das ja gelöst zu sein, indem man die Prüfung einfach überspringt.

Aber wenn der Zustand in anderem Zusammenhang auftritt, wird der Shop immer noch kommentarlos (ohne ohne Log-Eintrag) “offline” geschaltet.

Diese Situationen muss man m.E. sauberer abfangen, z.B. mit einer Fehlermeldung im Shop wie z.B. “Produkt nicht bestellbar”.

Einfach “offline” aufrufen, ist zwar bequem, hilft aber keinem so recht weiter…

Weil man keinen Anhaltspunkt hat, was geschieht.

Vor allem sollte auch in dieser Situation das “Exception-Log” geschrieben werden, damit man auch ohne Debugger sieht, was anliegt…

Professional Edition 4.4.8_34028

EXCEPTION_LOG.txt
oxNoArticleException-oxArticleException—!–NOT CAUGHT–!--oxException (time: 2011-08-29 12:58:14): [0]: Der Artikel “13367.bg.Ein.” ist leider nicht mehr verfügbar

Der Shop landet bevor er auf die thankyou weitergleitet wird auf der offline-Seite, die Bestellung wird aber korrekt erfasst! Komischerweise konnte ich den Fehler wie in #0001328 und #0001276 beschrieben (Lagerbestand=1), nicht reproduzieren! Die Fehlermeldung ist jedoch identisch …

Dieser Fehler tritt auf seit dem das creditPass-Portlet aktiviert wurde.

Hat jemand ein vergleichbares Problem? :confused: