Kein Bug, aber ein mir verständlicher Einwand. Wir überlegen mal drüber ob das schöner geht ohne alles zum wackeln zu bringen.
Ich denke nicht, dass das in der Serverkonfiguration fehlt, der Shop läuft ja in Version 2.0.17, nur beim Update hapert es dann. Naja, mal sehen wie deren Antwort ausfällt. Melde mich.
Core Errors sind immer und ausnahmslos Hostersache. Die kommen aus den Untiefen der PHP Installation, die ist absolut sicher kaputt.
Problem gelöst. Der Provider hat die "custom php.ini" gelöscht oder deaktiviert. Danach funktionierte alles wie am Schnürchen.
Habe gerade auf 2.1.3.2 upgedated und bekomme nun die Meldung "Das Datenbankupdate zu Ihrer Shopversion wurde noch nicht ausgeführt. Bitte führen Sie dies gemäß der Installationsanleitung durch." - wenn ich auf Datenbankupdate klicke, kommt die Meldung dass das Update bereits durchgeführt wurde. Was tun?
Hallo Claudia, dann hast du vermutlich noch ein einen alten Updater in deinem Shop, der nun die Fehlermeldung wirft. Bitte gehe per FTP in das Hauptverzeichnis deines Shops und prüfe, ob dort eine gm_updater.php und eine gm_updater_sql.php liegt. Die beiden Dateien entfernen und dann sollte die Meldung im Adminbereich weg sein.
hallo, wir haben vor drei tagen das Masterupdate eingespielt und so ist auch alles im grünen bereich. leider stellen wir heute fest, das unsere kunden im einkaufsprozess ab checkout_payment folgende Fehlermeldung erhalten: FATAL ERROR(1): "Call to a member function assign() on a non-object"Information: <script type="text/javascript" src="http://www.luettefoerdekieker.de/includes/billpay/templates/js/billpay.js"></script><link type="text/css" rel="stylesheet" href="http://www.luettefoerdekieker.de/includes/billpay/templates/css/billpay.css"/> Fatal error: Call to a member function assign() on a non-object in /var/www/web1168/html/includes/modules/payment/billpaydebit.php on line 81 ..wir haben gerade ein Ticket eröffnet, aber vielleicht hat ja hier jemand eine idee?
Danke für deine Hilfe! wir haben auch schon mit dem Billpay suport gesprochen und es gibt eine neue Anpassung. Leider können wir diese jedoch nicht durchführen, da bei uns im Adminbereich unter Module Zahlungsweisen folgende Fehlermeldung angezeigt wird: COMPILE ERROR(64): "require_once(): Failed opening required 'sofort_general.php' (include_path='.:/usr/share/php:/usr/share/pear')" ..haben nun zweites Ticket eröffnet.
Ich schreibe mal hier ran, da ich glaube dass das mit 2.1 geändert wurde. Es ist kein richtiger Bug, aber ein "Schönheitsfehler". In der css wurde aus dd{ background-image: url(backgrounds/separator-dotted-hori.png); background-position: -1px bottom; } .details .inside dd{ background-image: url(backgrounds/separator-dotted-hori.png); background-position: -1px top; } Dadurch hat meine eine Punkt-Zeile über der Artikelnummer (nur dd) und der Übergang von dt zu dd ist unsauber. Browser ist Chrome ist mit in mehreren Shops aufgefallen. Das kann man zwar in der eigenen css-Datei ändern, aber mit dem Style-Ding legt man sich die Karten.
Hallo Barbara, hier eine kurze Anleitung: Ändere mittels StyleEdit, CSSMonitor oder USERMOD vom Selektor "dt" folgenden Style PHP: background-position: bottom; in PHP: background-position: top; um. Fix kommt mit v2.1.4.0...
Bug in der v.2.1.3.3 Hallo Gambio, es gibt einige Bugs im Bezug auf die UTF-8 Version. Multibyte-Sprachen mit "new DOMDocument()" werden falsch dargestellt. shop\admin\print_intraship_label.php (1 hit) Line 23: $doc = new DOMDocument(); shop\includes\classes\hermes.php (1 hit) Line 1175: $dom = new DOMDocument(); shop\system\classes\PopupContentContentView.inc.php (1 hit) Line 1175: $t_dom_document = new DOMDocument(); Fix: 1. alle diese Dateien +shop/popup_content.php als UTF-8 ohne BOM abspeichern 2. den Code so anpassen: $t_dom_document = new DOMDocument('1.0', 'UTF-8'); $t_dom_document->substituteEntities = TRUE; $t_dom_document->loadHTML('<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />' . $this->content_data_array['content_text']);
Hallo Gambio, ich habe noch zwei Bugs für euch. 1. Falsche MwSt.-Anzeige im Checkout (siehe Grafik im Anhang) 2. im Zahlungsweisen->SEPA-Modul fehlen zwei Konstanten(sind undefiniert): MODULE_PAYMENT_SEPA_COMMUNICATE_SEPARATELY_TITLE MODULE_PAYMENT_SEPA_COMMUNICATE_SEPARATELY_DESC
Wenn du mit deiner etwas knappen Beschreibung die Art meinst, wie Kundennummern im Shop für Käufer ohne Benutzerkonto zusammengesetzt werden nein. Von unserer Seite aus betrachten wir das jetzige Verfahren nicht als Bug im Sinne eines Defekts, es sei denn jemand sagt uns warum das anders gemacht werden muss mit Verweis auf etwas, was so nicht funktioniert. Wir haben bisher keinerlei konkrete Vorschläge erhalten, wie sich jemand das anders vorstellt.
Ich denke die meisten wären schon glücklich wenn in dem Fall einfach die nächste Kundennummer aus dem normalen Nummernkreis des Shops genommen werden würde. Zumindest in der 2.0er Reihe ist das bei Bestellungen ohne Registrierung über den PP-Warenkorbbutton und paypalng ja auch der Fall. Ob nun eine "echte" Kundennummer mehr oder weniger verwendet wird spielt im Normalfall keine Rolle.