gelöst.
Ich hatte seinerzeit für die Buttonlösung das Whitepaper http://www.shopbetreiber-blog.de/wp-content/upl…estellseite.pdf umgesetzt und Elemente umpositioniert.
Dabei hatte ich übersehen, dass die FORM-ACTION nun doppelt war, was aber NUR bei den COMMENTS einen Effekt zeigte.
Nein, noch nicht gelöst. Bin zusammen mit dem Support noch dran und poste die Lösung, wenn es gefunden wurde
Ich bräuchte die Info, wie bzw. wo die COMMENTS in die Datenbank gespeichert werden, finde es nicht
Also wenn ich mir den Sourcecode auf der Seite checkout_confirmation ansehe, so steht ganz oben:
<form id="checkout" action="https://www.futterdepot24.de/checkout_process.php" method="post" onSubmit="return checkout();">
und etwas weiter unten:
<div class="checkout_comments">
<div class="checkout_title border_top_radius_6" onclick="slideInOrOut('comments');"><strong>Feld für Mitteilungen an uns</strong> <div class="right" id="btn_comments">-</div></div>
<div class="checkout_content border_bottom_radius_6" id="chkt_comments"><textarea name="comments" id="comments" cols="60" rows="4" style="width:99.8%"></textarea>
<input type="hidden" id="comments_added" name="comments_added" value="YES" /></div>
</div>
<div class="checkout_spacer"> </div>
</form>
also, alles ok.
Wie oben erwähnt, habe ich ja versucht, mir den geposteten Inhalt der Variablen und Session anzeigen zu lassen und da eben scheint die Variable $COMMENTS, welche in der Mailvorlage "Bestellbestätigung" verwendet wird, leer zu sein.
Also der POST geht ja auf checkout_process.php
comments_added in der Form enthält "YES", also sollte $_POST['comments'] in die Session geschrieben werden (bei mir Zeile 44).
checkout_xajax steht auf 1, so dass auch Zeile 96 greift -> $_SESSION['comments'] = strip_tags($_POST['comments']);
Weiter unten, also wenn das SQL-Statement "zusammengebaut" wird, steht dann aber (Zeile 200 und 240)
... 'comments' => $order->info['comments'],
comments wird also zunächst in die Session geschrieben, SQL nutzt aber das order-Objekt. Ist das vielleicht der Bug?
Habe auch das getestet, also die Session verwendet, kein Effekt. Es wird nichts in "comments" in der tabelle orders geschrieben.
Weiterer Test:
habe mir in der checkout_process per var_dump das order objekt anzeigen lassen und zwar kurz bevor das sql_data_array gebaut wird. Dort ist "comments" NULL
Weiterer Test:
An dieser Stelle gibt es auch in der Session keine comments
Hallo,
diese Antwort ist leider wenig hilfreich...
Denn, natürlich ist das Kommentarfeld vorhanden und natürlich habe ich das auch selbst getestet, in dem ich bei einer Testbestellung Text eingegeben hatte.
Wie erwähnt erscheint der Text weder in der Mail, noch wird er in die DB gespeichert.
Hallo,
weiss jemand, woran es liegen kann bzw. wo man nachsehen muss, wenn die Kommentare, die ein Kunde im 1-Page-Checkout ins Kommentarfeld eingibt, nicht in der Bestätigungsmail erscheinen?
$COMMENTS in der Mailvorlage scheint leer zu sein und auch in der Datenbanktabelle orders wird in die Spalte comments nichts gespeichert.
PS: 2.1CE
Danke für Deine Antworten, auch zu den anderen Themen, klar, es gibt keinen Support mehr, dennoch wäre es schon toll, wenn man erfahren könnte, wie es zu dem Fehler kommt, bei dem manche Browser einen falschen Pfad bei css oder js dateien suchen.
Vielleicht ist hier ja eine Lösung bekannt, den es sich nicht nur die Bots, die evtl. das BASE HREF ignorieren, habe auch immer wieder "normale" Zugriffe, die nicht auf /cache oder /templates/.../cache/ gehen, sondern auf die SEO-Url und dort dann den Cache-Ordner suchen, z.B. /kategorie/produkt/cache/123456789.css statt /cache/123456789.css ...
Vielen Dank für die Antwort.
Natürich würde ich gerne wechseln, uanhängig von den Kosten. Es ist bei mir als "Allein-Shopbetreiber" einfach ein Zeitproblem...
Deshalb würde ich gerne bis zum Wechsel o.a. Weg gehen, lediglich die "Stelle", wo ich das mit den dynamischen HTML-Dateien durchführen müsste, habe ich noch nicht gefunden, wobei das größte vor allem ja die js/css sind...
Ich habe versucht, meinen Pagespeed-Wert zu verbessern.
Hierbei fallen insbesondere die sehr großen js-Dateien und css-files auf.
Mein Ansatz war, von den cache-files gezippte gz-Dateien "on the fly" zu erstellen. Von den statischen css- und js-dateien habe ich bereits gz-Archive von Hand erstellt.
In der SourceMerger.Class.php
private function setFileContent($sFileName, $sFileContent){
$fileHandler = fopen($sFileName, "w+");
if($fileHandler === false)
return false;
$ret = fwrite($fileHandler, $sFileContent);
fclose($fileHandler);
$fpgz = gzopen ($sFileName.'.gz', 'w6'); // w9 == highest compression
gzwrite ($fpgz, $sFileContent);
gzclose($fpgz);
return !($ret === FALSE);
}
und in der css_styler.php
$fp = fopen($css_cache_datei, 'w+');
fwrite($fp, $output);
$fpgz = gzopen ($css_cache_datei.'.gz', 'w6'); // w9 == highest compression
gzwrite ($fpgz, file_get_contents($css_cache_datei));
gzclose($fpgz);
Zusätzlich in der root-htacces und in den htacces der cache-Ordner:
<IfModule mod_rewrite.c>
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_URI} \.(js|css|html)$
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]
</IfModule>
Die Freude war nur kurz, der Pagespeed ging von 79-80 rauf auf 88, beim nächsten Aufruf aber wieder runter.
Es erscheint für die css- und js-Dateien wieder der Hinweis "Komprimierung aktivieren"
Ferner "Browser-Caching nutzen" für die cseo_css_img.php und das js-cache-file...
Die html-Dateien scheinen auch nicht komprimiert zu werden.
Hallo,
ja, ich weiss, es gibt neuere Versionen, aber ich hab nunmal die 2.1er CE und momentan keine Kapazität frei für ein UpDate / UpGrade.
Bin dennoch auf der Suche nach einem funktionierenden Mobile-Template.
Einige habe ich schon ausprobiert, bekomme sie aber nicht zum Laufen.
Gibt es hier evtl. was Neues?
Hallo Leute,
da es ja für die 2.1. CE leider keinen Support mehr gibt und auch schon vorher noch keine Lösung gefunden werden konnte, woher die oft sehr vielen 404-Fehler in der Statistik herkommen könnten, habe ich mich selbst auf die Fehlersuche begeben.
Ich habe hierzu in der commerce_seo_url.php ganz unten, also dort, wo auf die 404-Seite weitergeleitet wird, den Referer angehängt:
...
else
header('Location: '.HTTP_SERVER.DIR_WS_CATALOG.'404.php?error=404&ref='.$_SERVER['REQUEST_URI']);
} elseif(!empty($_GET['error']))
header('Location: '.HTTP_SERVER.DIR_WS_CATALOG.'404.php?error=404&ref='.$_SERVER['REQUEST_URI']);
Wenn ich nun im Adminbereich beobachte, wer online ist, fallen mir folgende Fehler auf:
1. Ein Thumbnail-Image wird manchmal im Pfad der aktuellen Kategorie gesucht
/404.php?error=404&ref=/Kategorie1/Kategorie2/Kategorie3/Kategorie4/images/product_images/thumbnail_images/Artikel_12345.jpg
Richtig wäre /images/product_images/thumbnail_images/Artikel_12345.jpg
2. Gleiches passiert manchmal bei den Cache-Dateien:
/404.php?error=404&ref=/Kategorie1/Kategorie2/Kategorie3/Kategorie4/Kategorie5/cache/js2cf8a71c990e3e10aee8f622071bf6ff.css
Richtig wäre /cache/js2cf8a71c990e3e10aee8f622071bf6ff.css
Ich habe eine Vermutung, die mir vielleicht jemand hier aus dem Forum bestätigen kann:
Kann es sein, dass der eine oder andere Browser oder Bot das "base href" ignoriert?
Denn dann wäre dies eine Erklärung für zumindest einige 404er, da dann
<link rel="stylesheet" href="cache/..."
<link rel="stylesheet" type="text/css" href="templates/cseo-css-v2/cache/..."
und <script src="cache/..." evtl. nicht stimmen könnten...
Im Grunde genommen dachte ich, es könnte ausreichen, in der includes/javascript/cseo_java.php
Zeile ca. 182ff..
$template_css->setUrl('templates/'.CURRENT_TEMPLATE.'/cache');
$template_css->setSourcePath('templates/'.CURRENT_TEMPLATE.'/css');
$template_css->setCachePath('templates/'.CURRENT_TEMPLATE.'/cache');
und z.B. Zeile ca. 218ff
$js_css->setUrl('cache');
$js_css->setSourcePath('includes/javascript/css');
$js_css->setCachePath('cache');
jeweils einen Slash voranzustellen, was aber nicht 100% funktioniert.
Würde mich sehr freuen, wenn hierzu jemand schreiben würde, jemand einen Lösungsansatz hat.
Ferner würde mich für die PageSpeed-Optimierung interessieren, ob man die js und css Dateien in den cache-Ordnern gzippen kann... wo?
Mir ist jetzt erst dieser "Fehler" aufgefallen (2.1 CE)
Gibt es keine andere Lösung als den Smarty-Replace (der nicht funktioniert)?
Die letzte Frage, wie man das ?n1=1... am Ende losbekommt, blieb ja unbeantwortet...
vielen Dank... aber...
function xtcGetDC($price,$dc) {$dc = ($price)/100*$dc;$dc = round($price, 2);return $dc;}
müsste doch dann heissen
function xtcGetDC($price,$dc) {
$dc = ($price)/100*$dc;
$dc = round($dc, 2);
return $dc;
}So, bin ein klein wenig weiter.
Wenn ich in der XtcPrice.php die
function xtcGetDC($price,$dc) { $dc = ($price)/100*$dc; return $dc; }
ändere in
function xtcGetDC($price,$dc) { $dc = ($price+0.0001)/100*$dc; return $dc; }
habe ich in der Shopping-Cart-Box und auf der Warenkorb-Seite den korrekt gerundeten Rabatt.
Ferner in der ot_discount.php
vor:
$this->output[] = array('title' => $this->title, 'text' => $xtPrice->xtcFormat($discount_price,true), 'value' => $discount_price);
eingefügt:
$discount_price = round($discount_price-0.0001,2);Danke,
ich habe, wie allgemein empfohlen, 4 Nachkommastellen eingestellt und Brutto im Admin.
Vielen Dank Mario,
naja, ob Brutto oder Netto... entscheidend ist doch, dass aus 1.255 EUR Rabatt 1.25 EUR gemacht werden und ich einfach nur gerne wüsste, wo, d.h. in welcher Datei ich suchen muss...
Also, darf ich ehrlich sein...
Scheinbar scheint hier in der 2.1er CE keiner der Admins / Entwickler mehr reinzuschauen...
Auch wenn es nun nur mehr die 2.2 er und damit kostenpflichtige Version gibt... lässt man uns nun im Regen stehen... liest hier keiner mehr???
Schweigen... damit gekauft wird?
da war ich nach Recherchen hier im forum und bei google schon, steht auf 4 Stellen, wie empfohlen
Dennoch danke