Hallo zusammen, Heute gibt es eine neue Beta-Version des MobileCandy-Templates. Die Pakete sind für die Versionsreihen 3.0.x.x bzw. 3.1.x.x und diejenigen, die lieber ihr eigenes Template bzw. EyeCandy und MobileCandy statt dem neuen Honeygrid verwenden wollen: Geändert in 3.1.x: [#48094] Heidelpay aktualisieren [#48095] MobileCandy wird nicht angzeigt, wenn ein Socket für die Datenbankverbindung verwendet wird. [#48091] Cookie-Bar wird im MobileCandy nicht angezeigt [#48232] Checkbox für Datenschutzbestimmungen Geändert in 3.0.x: [#48232] Checkbox für Datenschutzbestimmungen [#48094] Heidelpay aktualisieren WICHTIG: Es handelt sich hierbei ausdrücklich um eine BETA-VERSION! Es wird empfohlen Tests ausschließlich in einem Testshop durchzuführen und nicht in Live-Systemen! Wir freuen uns auf eure Rückmeldungen und wünschen Happy Testing!
@Gambio, MobileCandy Update von 1.2.13 auf 1.2.14 BETA1 im Testshop (Link nur für registrierte Nutzer sichtbar.) Version 3.1.x.x und MobileCandy Update von 1.2.13 auf 1.2.14 BETA1 im Testshop (Link nur für registrierte Nutzer sichtbar.) Version 3.0.x.x fehlerfrei durchgelaufen. Keine Probleme entdeckt. Kleiner Schönheitsfehler: Nach Aufruf des Updaters wird die Version 2x angezeigt
Guten Tag, leider muss ich feststellen, dass unser Problem damit weiterhin ungelöst bleibt. Im Supportticket #100361892 hieß es, dass das im nächsten Update berücksichtigt würde...
Die finalen Versionen von allem kommen, wenn eine Mehrheit nickt, das hängt an vielen Punkten. Wir müssen zum Beispiel morgen nochmal das Problem von Michael Freund bewerten, das könnte Einfluss haben.
Hallo Michael, das ist kein Problem des MobileCandy sondern vielmehr ein Problem mit Sonderzeichen-Encodings. Das von dir im Ticket beschriebene %E4 ist ein ISO 8859-1 encodiertes Sonderzeichen. Das dem MobileCandy zu Grunde legende jQuery-Mobile 1.4.5 versteht aber nur UTF-8 encodierte Sonderzeichen. Wir setzen für MobileCandy auch explizit das Charset auf UTF-8, weshalb ich das ganze nicht für einen Bug seitens MobileCandy halte. Es ist vielmehr ein Bug des im Ticket angesprochenen Billpay-Moduls, welches die falsch encodierten Sonderzeichen in die URL schreibt.