Vorerst konnte ich nun klären.
Es lag nicht an den Umlauten oder am Buchstaben "ß", sondern an einem Apostroph in der Firmenbezeichnung.
Dieses Apostroph wird von der SECUPAY-API nicht akzeptiert.
Da soll einer rauf kommen...
Ich habe aber SECUPAY noch einmal gefragt, warum ein Apostroph nicht verarbeitet wird...
Warte nun wieder auf Antwort.
Hallo jotest,
ja, diesen blöden Buchstabe "ß", welchen es wohl nur in der deutschen Sprache bzw. Rechtschreibung gibt, sollten wir abschaffen!
Der macht nur Probleme...
Ich vermute, dass das SECUPAY-Zahlungsmodul Schwierigkeiten hat, diesen richtig zu interpretieren. Mit "ä", "ü" und "ö" scheint das Modul klar zu kommen.
Ich bin schon im Kontakt mit SECUPAY. Mal sehen, was die antworten bzw. welche Lösung sie parat haben.
Ich melde mich wieder, wenn ich etwas von denen gehört habe.
Bis dahin wünsche ich Dir ebenfalls einen Guten Rutsch ins Neue Jahr!
Ich habe mittlerweile festgestellt, dass nicht Umlaute Probleme machen, sondern nur der Buchstabe "ß".
Hat jemand dafür eine Erklärung?
Ich habe mittlerweile festgestellt, dass es an den Umlauten in der Rechnungsanschrift liegt.
Wenn die Rechnungsanschrift keine Umlaute hat, wird alles sauber an Secupay übergeben und die Bestellungen laufen ordnungsgemäß durch.
Hat jemand eine Idee?
Hallo,
ich habe das Zahlungsmodul von Secupay am Laufen.
Nach dem letzten Stepp "Zahlungspflichtig bestellen" bekomme ich folgende Fehler Meldung „Sie haben nicht zulssigeZeichen bertragen“ und es findet keine Transaktion statt, sondern es wird wieder zurückgesprungen zur Seite, wo die Zahlungsarten ausgewählt werden können.
Woran kann dies liegen?
Hallo admin,
im normalen Checkout läuft das Modul problemlos.
Ich habe die jetzt mal angeschrieben und gebeten zu schauen, wie das Modul für den 1PageCheckout modifiziert werden. In 1 - 2 Tagen soll ich ein Antwort erhalten...
Schauen wir mal...
Ich melde mich wieder, wenn ich etwas belastbares in Erfahrung gebracht habe.
Guten Morgen Andreas,
wieder so spät noch aktiv... 
Kein Problem. Wollte es erst mal nur testen. Die Bestellung lässt sich trotz der Tatsache, dass das Speichern nicht funktioniert, abschließen.
Nur wenn ich einmal bitpay als Zahlungsweise ausgewählt habe, lässt es sich nicht mehr zurück auf eine andere Zahlungsweise wechseln.
Überhaupt klemmt es, wenn das Modul installiert ist. Selbst wenn es auf "false" steht, lassen sich zwar die anderen Zahlungsweisen auswählen und speichern, aber nicht die Versandarten.
Erst wenn ich das Modul wieder komplett deinstalliere, lassen sich auch die Versandarten wieder speichern
Ich habe festgestellt, dass dies mit dem AJAX Checkout Prozess zusammenhängt. Wenn dieser deaktiviert ist, läuft es problemlos durch...
Habe die Version v2.6.1 laufen und das Zahlungsmodul von bitpay.com installiert, so dass auch mit Bitcoins bezahlt werden kann.
Das funktioniert auch soweit, nur das im Checkout, wenn ich die Zahlungsweise dann auswähle, die Speicherung nicht klappt.
Der Speicherbutton blinkt ständig und ich kann dann auch nicht zurück auf eine andere Zahlungsweise wechseln.
Die Dateien, welche eingespielt wurden, sind hier zu finden:
https://github.com/bitpay/commerce-seo-plugin
Wo kann der Fehler liegen? Hat jemand eine Idee?
Billsafe wird zwar zur Auswahl angezeigt und kann auch ausgewählt werden.
Es wird aber kein Logo mehr angezeigt, obwohl der hinterlegte Link stimmt.
Wo oder was kann hier die Ursache sein?
Shopversion ist v2next 2.6.1
Wenn ich ein Kundenkonto erstellen möchte, erfolgt leider nur die folgende Anzeige:
Kundenkonto erstellen
* notwendige Informationen
Ihre persönlichen Daten
Vorname:
Nachname:
E-Mail-Adresse:
Ihre Adresse
Strasse/Nr.:
Postleitzahl - Ort:
Ihre Kontaktinformationen
Telefonnummer:
Sichern Sie Ihr Kundenkonto mit einem Passwort.
Ihr Passwort:
Passwort bestätigen
Passwort-Sicherheit:
Newsletter
Ich möchte den Newsletter abonnieren (Abmeldung jederzeit möglich).
Es fehlen alle Eingabefelder. Woran kann dies liegen?
Die Ursache lag beim Server.
Die folgende Antwort bekam ich von meinem Hoster auf erneute Anfrage:
Auf Ihrem derzeitigen Server fehlte tatsächlich das serverseitige Sprachpaket für die Funktion strftime().
Vorher:setlocale(LC_TIME, 'de_DE.UTF-8', 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'German');
strftime("%A %e %b %Y", mktime(13,58,30, 18, 10, 2016));
ergab: Tuesday 18 Oct 2016
Nachher:Dienstag 18 Okt 2016
Normalerweise werden diese Sprachvarianten in PHP selbst realisiert, um die Shopsoftware unabhängig vom verwendeten System zu machen.
Das Thema ist damit für mich erledigt.
Die Ursache lag doch beim Server. Die folgende Antwort bekam ich von meinem Hoster auf erneute Anfrage:
Auf Ihrem derzeitigen Server fehlte tatsächlich das serverseitige Sprachpaket für die Funktion strftime().
Vorher:
setlocale(LC_TIME, 'de_DE.UTF-8', 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'German');
strftime("%A %e %b %Y", mktime(13,58,30, 18, 10, 2016));
ergab: Tuesday 18 Oct 2016
Nachher:
Dienstag 18 Okt 2016
Normalerweise werden diese Sprachvarianten in PHP selbst realisiert, um die Shopsoftware unabhängig vom verwendeten System zu machen.
Das Thema ist damit für mich erledigt...
@pegtor: Vielleicht hilft Dir die Antwort ja auch weiter, falls es bis dato noch keine Lösung gab.
Dann natürlich besten Dank auch an Herr Kausch...
Ich habe die Shop-Version 2.6.1 und php-Version 5.6.26.
Mein Hoster sagt zu dem Thema:
"bitte wenden Sie sich an den Support für Ihre Shopsoftware. Dies ist kein Problem des Servers. Es ist Aufgabe des Shops die Ausgabe entsprechend zu formatieren."
In der Bestätigungsmail steht das Bestelldatum in folgendem Format: Friday, 07. October 2016
In habe es noch nicht geschafft, das Datum zu ändern in Freitag, 07. Oktober 2016
In der send_order.php steht der Wert "xtc_date_long". Wenn ich diesen ändere in "xtc-date-short" erscheint zumindest: 07.10.2016.
In der german.php im Verzeichnung html/lang/german/ steht folgendes:
define('HTML_PARAMS','dir="ltr" xml:lang="de" lang="de"');
@setlocale(LC_TIME, 'de_DE.UTF-8', 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'German');
define('DATE_FORMAT_SHORT', '%d.%m.%Y'); // this is used for strftime()
define('DATE_FORMAT_LONG', '%A, %d. %B %Y'); // this is used for strftime()
define('DATE_FORMAT', 'd.m.Y'); // this is used for strftime()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . '%H:%M:%S');
define('DOB_FORMAT_STRING', 'tt.mm.jjjj');
$monate = array(
1=>"Januar",
2=>"Februar",
3=>"März",
4=>"April",
5=>"Mai",
6=>"Juni",
7=>"Juli",
8=>"August",
9=>"September",
10=>"Oktober",
11=>"November",
12=>"Dezember");
Liegt hier eventuell ein Problem vor, das der Wochentag und der Monat nicht in deutsch angezeigt werden?
Oder gibt es noch woanders Einstellungsmöglichkeiten, z.B. beim Server?
Noch immer habe ich das Poblem, dass in Bestellbestätigungen das Datum nicht im deutschen Format angezeigt wird?
Wo kann hier die Urasche liegen?
Fehler wurde durch Herr Kirsten gefunden. Hatte ich selbst verschuldet... 
Hatte die configure.php - Dateien verwechselt beim Hochladen...
Ja, irgendwie ist beim updaten ein ungewollter Loop rein gekommen, welcher zweimal auf mein Verzeichnis springt...
Vielleicht kann sich ja der admin mal bei mir melden, um bei mir zu schauen, wo der Fehler entstanden ist und wie er behoben werden kann.
Wäre nett. Danke vorab.
Habe nun das Update 2.6 eingespielt und bekomme folgende Fehlermeldung, wenn ich mich als admin einloggen möchte.
Die Anmeldung funktioniert zwar, aber wenn ich auf Admin klicke, kommt eine lerre Seite mit "HTTP ERROR 500".
[12-Oct-2016 19:42:38 Europe/Berlin] PHP Fatal error: require(): Failed opening required '/var/www/cn2480912/html//var/www/cn2480912/html/includes/functions/compatibility.php' (include_path='.:/usr/local/php56/lib/php') in /var/www/cn2480912/html/admin/includes/application_top.php on line 127
Was kann hierfür die Ursache sein? Derzeit lässt sich der Shop durch den Fehler nicht mehr administrieren...
Habe den Fehler gefunden.
Den Ordner admin mit der Datei billsafe_print_order.html gab es im template file v2next_gray_day_2 gar nicht, warum auch immer...
Habe den Ornder admin dort erst mal erstellt und dann die Datei billsafe_print_order.html, welche ganz woanders lag, hinzugefügt.
Und siehe da, nun funktioniert es... 
Danke an jotest für Deine Unterstützung!
