MODUL: Neuer Attribute Price Updater

[Viol]

Hat schon mal jemand versucht das Modul für die 3.0.2 und das Template tpl_nova oder tpl_neo anzupassen?
Im Prinzip funktioniert die Preisanpassung, allerdings wird der originale Preis nicht geändert.
Nun gibt es in den oben genanten Templates .pd_summary nicht mehr. Ich habe in der /includes/extra/application_bottom/web0null_attribute_price_updater.php die Klasse ".pd_summarybox" testweise durch ".pd_offer" und auch "pd_puprice" ersetzt, aber hatte damit leider keinen Erfolg.
Habe dann, diese Klasse weggelassen. Hier der entsprechende Passus aus der Datei:

Code: PHP  [Auswählen]

 if (updateOrgPrice) {
        <?php if (strpos(CURRENT_TEMPLATE, 'tpl_modified') !== false) { ?>
        $('.pd_price .standard_price').html(symbolLeft + newPrice + symbolRight);
        $('.pd_price .new_price').html(data.onlytext + symbolLeft + newPrice + symbolRight);
        $('.pd_price .old_price').html(data.insteadtext + symbolLeft + oldPrice + symbolRight);
                //$('.pd_offer .pd_price .old_price').html(data.anstatttext + symbolLeft + oldPrice + symbolRight);
        if (data.vpevalue !== false) {
          $('.pd_vpe').html(symbolLeft + newVpePrice + symbolRight + data.protext + data.vpetext);
        }
                $('.pd_price meta[itemprop="price"]').attr("content", newPrice.replace(",", "."));                                                                                               
        <?php } else { ?>
        $('.productprice .standard_price').html(symbolLeft + newPrice + symbolRight);
        $('.productprice .productNewPrice').html(data.onlytext + symbolLeft + newPrice + symbolRight);
        $('.productprice .productOldPrice').html(data.insteadtext + symbolLeft + oldPrice + symbolRight);
                //$('.productprice .productOldPrice').html(data.anstatttext + symbolLeft + oldPrice + symbolRight);
        if (data.vpevalue !== false) {
          $('#productVpePrice').html(symbolLeft + newVpePrice + symbolRight + data.protext + data.vpetext);
        }
        $('.pd_price meta[itemprop="price"]').attr("content", newPrice.replace(",", "."));
        <?php } ?>
      }
    },

Damit funktioniert z.B. das tpl_modified_responsive auch tadellos.
EDIT: ist gelöst.

Code: Javascript  [Auswählen]

<?php if (strpos(CURRENT_TEMPLATE, 'tpl_modified') !== false)

Dort muss das richtige Template eingetragen werden, damit es funktioniert. Und die Klasse pd_summerybox kann man weglassen.

[demoncleaner]

Ich bräuchte da mal bitte Hilfe.
Hat jemand das Modul in einem mind. 2.0.7.2 Shop laufen und es werden Attributspreise auch korrekt geupdated wenn das Produkt ein Sonderangebot ist?
Ich hab bei mir das Problem, dass bei Attributartikeln mit Sonderangeboten immer wieder der Standardpreis angezeigt wird statt des rabattierten Preises.

Ich arbeite mit prefix "=".
Daher verstehe ich diese Zeile nicht:

Code: PHP  [Auswählen]

else if (data.prefix == '=') {
              summe += data.aprice - data.gprice;
            }

Das ergibt also die Differenz vom Sonderangebotspreis zum Normalen Preis.

Dann wird aber direkt danach newPrice so berechnet, dass die Differenz wieder mit dem Sonderangebotspreis addiert wird:

Code: PHP  [Auswählen]

 var newPrice = (Math.round((summe + data.gprice) * 100) / 100).toFixed(2).toString().replace(/[.]/, ',');

So dass man dann natürlich als newPrice wieder auf den Standardpreis kommt und nicht auf den normalen Preis.
Das funktioniert bei Attributartikeln ohne Sonderangebot wunderbar. Wenn es ein Sonderangebot gibt wird dieses irgendwie nicht berücksichtigt. Daher zunächst mal meine Frage, ob das ein Bug ist oder bei mir was falsch läuft. Ich blicke da leider nicht so ganz durch.

[Viol]

Läuft bei mir (3.0.2) auch mit Sonderangeboten.

[demoncleaner]

Danke Viol für die schnelle Antwort. Hätte mir fast gewünscht es wär ein Bug.
Aber hast du auch "=" als Prefix ?

Wenn ich die original "/includes/extras/application_bottom/web0null_price_updater.php" verwende, dann updated sich bei mir der Preis leider auch auf den nicht-rabattierten Preis. schon beim Laden der Seite. Ich habe 2.0.7.2, glaube aber, dass die Shopversion hier keine Rolle spielt. Zumindest nicht ob diese oder 3.0.2.

[Karl1]

Hallo demoncleaner,
es könnte dein Template umbenannt oder verändert sein, dann stimmen die Selektoren nicht mehr, oder ein anderer JavaScript-Fehler blockiert die Ausführung des Skripts.

Ohne Link zum Problem wird man dir nicht weiterhelfen können.

Gruß Karl

[demoncleaner]

Danke Karl, aber die Selektoren sind es nicht. Ich stecke da schon etwas tiefer im Thema.
Der Javascript Fehler ist auch ein sinnvoller Hinweis, aber bei mir ist nichts blockiert. Das Script wird ausgeführt.
Ich bin da schon die Ganze Zeit am debuggen. Daher wollte ich vorher sicher gehen, dass der Fehler auch wirklich bei mir liegt. Meine Vermutung war, dass es mit der Kombination Prefix = und Sonderangebot und Attributartikel generell nicht klappen kann.

Daher mein o.g. Verweis auf die Code-Stelle. Die mir nicht so recht einleuchtet.
Da der Fehler bei mir trotz korrekter Template Angabe bzw. korrekten Selektoren und mit dem Original Script so auftaucht, ging ich davon aus, dass es nicht an mir liegen kann. Aber ich werde alles nochmal genauestens kontrollieren und dann Rückmeldung geben. Gut wäre zu wissen, ob es unter den o.g. Konditionen tatsächlich fehlerfrei laufen sollte.

[Karl1]

Kann es sein, dass du einen Denkfehler machst?

Wenn du den Prefix "=" verwendest, dann werden nur die Ist-Gleich-Preise des Attributes als Artikelpreis genutzt.
Die Preisangaben beim Grundartikel werden durch das Addieren und wieder Subtrahieren immer 0, also nicht berücksichtigt.
Hast du einen Sonderpreis, dann musst du diesen im Attribut angeben.

Vielleicht ist das mit ein Grund, warum "=" nicht Standard im Shop ist.

Gruß Karl

[demoncleaner]

Danke Karl für den Denkanstoß.
Ich bin da jetzt mal rangegangen, weil ich dachte, dass man das doch irgendwie per Modul lösen können muss.
Ist vermutlich nicht der schönste Weg. Ich will es nur als möglichen Ansatz zur Lösung mal in den Raum schmeißen.

Zunächst habe ich die /includes/extras/modules/products_attributes_data/web0null_attribute_price_updater.php
folgendermaßen angepasst:

Code: PHP  [Auswählen]

if (defined('MODULE_WEB0NULL_ATTRIBUTE_PRICE_UPDATER_STATUS') && MODULE_WEB0NULL_ATTRIBUTE_PRICE_UPDATER_STATUS == 'true') {


  // nur für Lesbarkeit
  $oldprice = $xtPrice->xtcFormat($xtPrice->xtcAddTax($xtPrice->getPprice((int)$product->data['products_id']), $xtPrice->TAX[$product->data['products_tax_class_id']]), false);
  // Rabatt in Prozent
  if($oldprice>0) {
  $rabatt_multiplikator = (100-((($oldprice-$products_price)/$oldprice)*100))/100;
  }
 
  $products_options_data[$row]['DATA'][$col]['JSON_ATTRDATA'] = str_replace(
    '"', '&quot;', json_encode(
      [
        'pid'          => (int)$product->data['products_id'],
        'gprice'       => $products_price,
        'oprice'       => $oldprice,
        // Ergänzung damit auch bei Attributen mit prefix Modul = die Sonderangebots-Ersparnis anhand des oprice (Old price) des Attributes und nicht nur des Hauptartikels berechnet werden kann.
        'oaprice'      => $xtPrice->xtcFormat($attr_price, false),
        'rabatt'       => $rabatt_multiplikator,
        // EO
        'cleft'        => $xtPrice->currencies[$_SESSION['currency']]['symbol_left'],
        'cright'       => $xtPrice->currencies[$_SESSION['currency']]['symbol_right'],
        'prefix'       => $products_options['price_prefix'],
        'han'          => $products_options['attributes_manufacturers_model'],
        'gtin'         => $products_options['attributes_model'],
        'aprice'       => $xtPrice->xtcFormat($price, false),
        'vpetext'      => encode_htmlentities(($json_vpetext = xtc_get_vpe_name($product->data['products_vpe'])) ? $json_vpetext : TEXT_PRODUCTS_VPE),
        'vpevalue'     => (($product->data['products_vpe_status'] && (double)$product->data['products_vpe_value']) ? (double)$product->data['products_vpe_value'] : false),
        'attrvpevalue' => (($product->data['products_vpe_status'] && (double)$products_options['attributes_vpe_value']) ? (double)$products_options['attributes_vpe_value'] : false),
        'onlytext'     => $json_onlytext ? TXT_ONLY : TXT_ONLY,
        'protext'      => $json_protext ? TXT_PER : TXT_PER,
        'insteadtext'  => $json_insteadtext ? TXT_INSTEAD : TXT_INSTEAD,
      ]
    )
  );
}

Damit steht mir dann in der /includes/extra/application_bottom/web0null_attribute_price_updater.php der generell Rabatt (bzw. direkt der Faktor für die Multiplikation) zur Verfügung. Ebenso steht mir der jeweilige Attributs-Normalpreis zu Verfügung. (Vermutlich kann man das auch noch weitere vereinfachen in dem man das an der Stelle direkt verrechnet.)

Die /includes/extra/application_bottom/web0null_attribute_price_updater.php habe ich dann in der if-Abfrage function calculate folgendermaßen geändert:

Code: PHP  [Auswählen]

if (data.aprice != 0) {
            if (data.prefix == '-') {
              summe -= data.aprice;
            } else if (data.prefix == '+') {
              summe += data.aprice;
            } else if (data.prefix == '=') {
             
              // Wenn Rabatt und Attribute vorliegen
              if ($('div[id^="optionen"]').length && data.gprice != data.oprice){
                summe += (data.oaprice*data.rabatt);
                data.gprice = 0;
              } else {
                summe += data.aprice - data.gprice;
              }

            }
          }

Vielleicht ist das Problem sehr spezifisch weil keiner wie ich das Modul mit = prefix nutzt oder ihr den Rabatt dann manuell bei den Attributen eintragt. Vielleicht habt ihr ja trotzdem eine Meinung dazu. Ich finde den Rabatt manuell eintragen nicht komfortabel. Man hat ja auch dann die Vorteile nicht, dass man den zeitgesteuert auslaufen lassen kann etc.

Besten Dank auf jeden Fall Karl für den Schubs in die richtige Richtung!

[DerNachbar]

[...]
Hast du einen Sonderpreis, dann musst du diesen im Attribut angeben.
[...]

seit wann das denn? An den Attributen fummelt man doch nichts rum, ausser Attribute haben unterschiedliche Preise je Ausfuehrung. Damit kann man doch gar nicht sinnvoll Sonderpreise gestalten oder gar deklarieren...

[Karl1]

Hallo DerNachbar,
du zitierst hier eine Zeile ohne den dafür wichtigen Zusammenhang.

Hast du eigentlich gelesen, dass es sich um den Prefix "=" handelt, der nicht Standard bei Attributen ist?

[Timm]

[...] Ich finde den Rabatt manuell eintragen nicht komfortabel. Man hat ja auch dann die Vorteile nicht, dass man den zeitgesteuert auslaufen lassen kann etc.
[...]

Moin

Gibt ein Kaufmodul von Timo Paul dafür, wo man nur den Sonderpreis einträgt und das dann automatisch auf die Attribute vererbt wird im Verhältnis Artikelpreis zu Sonderpreis. Ist aber noch nicht für 3.0.2 angepasst.

Gruß Timm

[demoncleaner]

Moin Timm, danke für die Info.
Jetzt bin ich grad unsicher. Ist das nicht sowieso so?
Ist hier nicht nur das Prefix der Knackpunkt bzw. der Preis-Updater - wie von Karl beschrieben?

Mit meinem oben beschriebenen Umbau klappt das jetzt eigentlich wunderbar.
In meinem speziellen Fall ist es so, dass der Preisupdater nicht nur den Hauptpreis, den Streichpreis, die HAN und die VPE Value updated, sondern initial auch die (mit =Prefix) angegebenen Attributpreise.

[Timm]

Im Standard wird nur der Artikelpreis gesenkt. Die Attributsufpreise bleiben gleich. Dadurch werden die Rabatte immer kleiner je höher die Attributaufschläge sind.

Bei dem Modul hat man immer den gleichen prozentualen Rabatt. Dachte das wäre gemeint, weil du geschrieben hattest, dass der Rabatt bei jedem Attribut eingearbeitet werden muss und du dir diese Arbeit sparen möchtest.

Gruß Timm

[noRiddle (revilonetz)]

Half off topic:

[...]
Gibt ein Kaufmodul von Timo Paul dafür, wo man nur den Sonderpreis einträgt und das dann automatisch auf die Attribute vererbt wird im Verhältnis Artikelpreis zu Sonderpreis. Ist aber noch nicht für 3.0.2 angepasst.
[...]

Ich weiß, daß andere es ebenso sehen, meine Wenigkeit
- die bekannt dafür ist das Blatt vor dem Mund seit langem verloren und nicht wiedergefunden zu haben -
möchte jetzt mal öffentlich kritisieren, daß du, Timm ständig einen bestimmten Dienstleister hier pusht.
Das finde ich nicht nur nicht in Ordnung, sondern bin der Meinung, daß das entschieden zu weit geht.
Sicherheitshalber sei gesagt: Meine Ansicht hat mit dem Dienstleister selbst nichts zu tun. Er mag gute Erweiterungen anbieten. Das tun andere jedoch auch.

Wenn hier bei manchen offene Werbung toleriert wird fällt mir dazu auch etwas ein, und nicht nur mir.
Man kann ja mit dem Zaunpfahl winken, weil es manchal nicht anders geht. Dazu reicht jedoch dann z.B. der Hinweis die Suchmaschine seines Vertrauens mit bestimmten Suchbegriffen füttern zu können/sollen.

Gruß,
noRiddle

[Timm]

Wieviele Entwickler kennst du, die zu diesem Thema ein passendes Modul haben? Ich vermute es sind nur 2. Der andere ist Web-Looks. Stimmt, hab ich nicht genannt. Da finde ich es aber suspekt, dass man nicht im Vorhinein einen Preis genannt bekommt. Das Modul von Timo hat ein Freund von mir und ist bis 2.0.7.2 damit zufrieden. Warum soll ich das dann nicht empfehlen? Wenn es das von 10 Entwicklern geben würde, dann würde ich mich dazu nicht äußern.

Dass ich Timo hier oft empfohlen hab, liegt daran, dass ich viele Module von ihm im Einsatz habe. Das beschränkt sich aber auch auf diese. Ich empfehle keine nicht von mir genutzten Module von ihm, außer ich wüsste, dass er der einzige ist, der das anbietet.

Zur Wahrheit gehört aber auch, dass ich bis 2.0.7.2 zufrieden war und nun seit Ewigkeiten auf Anpassungen für die neueste Shopversion warte, um updaten zu können.

Gruß Timm

P.S. Ich finde es ist ein Unterschied, ob man unbezahlt Werbung für etwas macht, dass man selbst nutzt, gut findet und daraus keinen monetären Vorteil zieht, oder ob man aus Eigeninteresse seine eigenen Module bewirbt. Obwohl ich persönlich mit zweitem auch kein Problem hätte. Auch in Verbindung mit einer PM Funktion im Forum, die es mal gab. Marktwirtschaft halt.