Ich doktor jetzt schon seit einiger Zeit an der Preisumstellung der Varianten, wenn der Preis des Vaterartikels zu einem bestimmten Zeitpunkt geändert wird: Admin Backend -> Erweitert - > “Preis zur festgesetzten Zeit aktualisieren”. Ich habe mir jetzt bei den betroffenen Artikeln mit Auswahllisten beholfen. Gibt es noch einen anderen Weg den Varianten mitzuteilen, das der Preis des Vaterartikels sich geändert hat?
Vielen Dank für die Hilfe!
Kann man die Sig nicht mehr anhängen? Hier meine Oxid-Version: 4.10.6 und Flow
Variantenpreise auf 0 setzen
Marat, hab ich gemacht. Dann werden die Variantenpreise im Frontend mit “0” angezeigt.
komisch, das sollte nicht sein. In der Regel übernehmen die Varianten den Preis vom Vater, wenn deren Preis 0 ist. Kann man im Demoshop sehen.
Hast Du irgendwelche Module, die in Preisberechnung eingreifen?
Oder A, B, C Preise?
Das Varianten-Modul von Web-Grips, Zunderweb Fix Baseprice, Zunderweb individueller Staffelpreis und das bestlife TPrice von Dir.
könntest Du probeweise mal baseprice fix und Varianten-Modul von Web-Grips deaktivieren, tmp/ leeren und nochmal gucken?
Beim Baseprice gibt es keinen Unterschied. Ich meld mich wieder nach dem nächsten Versuch.
Hm, es scheint das Web-Grips Modul zu sein. Ich hab mal alle möglichen Konstellationen und auch die Reihenfolge der Modulaktivierung geändert. Jedes mal das TMP gelöscht. Alles läuft korrekt, bis das Varianten-Modul aktiviert wird. Gerde das soll doch die Daten vom Vater holen, wenn keine Angaben gemacht werden.
Ich werd mich da mal melden. Danke Dir trotzdem Marat.
Im Azure Theme das gleiche. Gewicht und Preis werden nicht übernommen. Wir hatten vor ca. einem halben Jahr schon recht unerfreulichen Kontakt mit Web-Grips. Da lief das Modul in Roxive auch nicht komplett (Ich sprach dort das fehlende Gewicht an). Man bot uns kurz nach Kauf des Moduls kostenpflichtigen Support an, ohne einmal einen Blick auf die Situation geworfen zu haben, mit dem Hinweis nicht alle Themes können getestet werden. Jetzt stellen wir fest, das im Standard Theme das Modul auch nicht vollständig läuft. Ich bin langsam am platzen. Vielleicht melden sich die Damen und Herren von Web-Grips ja hier und fixen die Probleme im Modul.
Die Schuld liegt nicht notwendigerweise bei Web-Grips.
Man müsste gucken, was in der Datenbank steht, denn Werte wie 0 oder leerer String “” (die vielleicht durch andere Module oder beim Import erzeugt wurden) sind durchaus gültige Daten und könnten in diesem Zusammenhang daher nicht durch vererbte Daten vom Vaterartikel ersetzt werden.
Auf deren Webseite habe ich gesehen, dass die Dateien unverschlüsselt sind. Du müsstest nur herausfinden, welche Datei die Klasse oxarticles überschreibt und dort drin die Funktion zum Abrufen / Vererben der Preise ausfindig machen. Den Rest kann man ganz einfach testen und beheben.
Die Schuld liegt nicht notwendigerweise bei Web-Grips.
Sicher nicht zwingend Marat. Aber einen Blick drauf werfen ist doch wohl drin und die Lösung für einen Entwicklung einfacher als für mich, der nur verkaufen kann. Ich schaue heute Nacht mal drüber und berichte dann. Danke Dir vorerst!
Das hab ich in der “article_variant_listitem.tpl” gefunden:
…
<input type=“text” class=“editinput” size=“10” maxlength=“[{$listitem->oxarticles__oxartnum->fldmax_length}]” name=“editval[[{ $listitem->oxarticles__oxid->value}]][oxarticles__oxartnum]” value=“[{$listitem->oxarticles__oxartnum->value}]” [{ $readonly }]>
<input type=“text” class=“editinput” size=“7” maxlength=“[{$listitem->oxarticles__oxprice->fldmax_length}]” name=“editval[[{ $listitem->oxarticles__oxid->value}]][oxarticles__oxprice]” value=“[{$listitem->oxarticles__oxprice->value}]” [{ $readonly }]>
<input type=“text” class=“editinput” size=“7” maxlength=“[{$listitem->oxarticles__oxsort->fldmax_length}]” name=“editval[[{ $listitem->oxarticles__oxid->value}]][oxarticles__oxsort]” value=“[{$listitem->oxarticles__oxsort->value}]” [{ $readonly }]>
<input type=“text” class=“editinput” size=“7” maxlength=“[{$listitem->oxarticles__oxstock->fldmax_length}]” name=“editval[[{ $listitem->oxarticles__oxid->value}]][oxarticles__oxstock]” value=“[{$listitem->oxarticles__oxstock->value}]” [{ $readonly }]>
…
Bin ich hier richtig?
In der Datenbank steht bei “OXPRICE” eine “0” als Standard.
oxprice ist das Feld in der Tabelle oxarticles, in dem der Preis steht, ja.
Sofern jetzt beim Vater nicht 0 steht, wird der Preis vom Vater geladen. Was ja auch funktioniert, wenn das Modul aus ist.
Such mal in dem Modul nach den Funktionen getBasePrice(), _getAmountPrice(),_getPrice() oder _getVarMinPrice()
Dort wird der Preis geladen und berechnet
Diese Funktionen gibt es nicht, aber ähnliches: Hier ein Auszug
…{if (!$oBasket){$oBasket = $this->getSession()->getBasket();}if ($oBasket){$dAmount = 0;foreach ($oBasket->getContents()as $item){if ($item->getArticle()->getParentId()== $oParent->getId()){$dAmount += $item->getAmount();}}}}return parent::getBasketPrice($dAmount, $aSelList, $oBasket);}}
und
getTPrice
findet sich da auch. Ich will nicht den ganzen Code hier posten.
Ich hab heute Nacht noch einmal meinen Testshop Version 4.10.6 komplett neu aufgesetzt. Dann den Total Flow Fix von foxido kopiert. Dann das Varianten Modul installiert. Hier stellt sich die Lage jetzt so da, das manchmal nach dem Löschen des Cache/TMPs die Preise angezeigt werden, manchmal nicht. Sowohl unter Azure und Flow. Dabei habe ich das Neuladen der Seite im Browser forciert.
Es lässt sich leider nicht regelmäßig reproduzieren.
Fasse ich die TMPs nicht an und lösche diese nicht, werden scheinbar die Preise stabil in den Artikeln geladen. Konnte ich testen, wenn ich beim Vater den Preis geändert habe. Das ganze habe ich mit einem Browser getestet, der keine Offline Dateien speichert. Zusätzlich habe diesen Browser immer wieder komplett geschlossen, vor dem nächsten Test. Als Bestätigung habe ich zusätzlich das ganze mit einem 2. Browser getestet. Alles unter OSX. Parallel dazu Windows in einer VM, mit Edge und mit einem Tablet mit separaten Mobilzugang getestet.
Das Gewicht wird in den Varianten überhaupt nicht übernommen.
Ich teste jetzt noch die zeitliche Preisaktualisierung.
Gerade ist es wieder passiert. In einem Artikel habe ich die Preise (die Gewichte nicht) in den Varianten gelöscht, nur im Vater nicht.
/**
* Assign condition setter. In case article assignment is skipped ($_blSkipAssign = true), it does not perform additional
*
* @param bool $blSkipAssign Whether to skip assign process for the article
*/
Geraten: Wird eventuell “_assignParentFieldValues” nicht ausgeführt?
Das kann sein. Ich bin gerade dabei die Geschichte mit der “force_sid” durchzuarbeiten. Denn manchmal taucht das Problem auf, wenn eine “force_sid” hinten dran hängt.
Das kannst evtl. so testen:
public function assign($aRecord)
{
startProfile(‘articleAssign’);
// load object from database
parent::assign($aRecord);
$this->oxarticles__oxnid = $this->oxarticles__oxid;
// check for simple article.
if ($this->_blSkipAssign) {
return;
}
$this->_assignParentFieldValues();
$this->_assignNotBuyableParent();
$this->_assignStock();
$this->_assignPersistentParam();
$this->_assignDynImageDir();
$this->_assignComparisonListFlag();
stopProfile('articleAssign');
}
=>
public function assign($aRecord)
{
startProfile('articleAssign');
// load object from database
parent::assign($aRecord);
$this->oxarticles__oxnid = $this->oxarticles__oxid;
// check for simple article.
if ($this->_blSkipAssign) {
//return;
}
$this->_assignParentFieldValues();
$this->_assignNotBuyableParent();
$this->_assignStock();
$this->_assignPersistentParam();
$this->_assignDynImageDir();
$this->_assignComparisonListFlag();
stopProfile('articleAssign');
}
Wo muß ich da hin rubbercut? Ich bin leider kein Programmierer.
