Die 3.1.2 enthält den Fix für die Umstellung am 3.12. von SSL auf TSL sowie einige andere Änderungen.
Um für den 3.12. gewappnet zu sein, reicht also die Anpassung der cURL Option.
Gruß
Die 3.1.2 enthält den Fix für die Umstellung am 3.12. von SSL auf TSL sowie einige andere Änderungen.
Um für den 3.12. gewappnet zu sein, reicht also die Anpassung der cURL Option.
Gruß
ok, getestet mit ein paar Hindernissen, aber es funktioniert. war ja leichter als gedacht ohne das update. einfach nur eine zahl ändern, that’s it. lustig danke an alle
Hallo,
Ich versuche gerade das neue PayPal Modul in unseren Shop zu integrieren.
Also alles so gemacht wie in dem Handbuch beschrieben.
Oxid CE 4.5.7
PHP 5.3.x
Seite läuft noch - ABER:
Beim Checkout wurde angezeigt: [B]URL to call is not valid[/B]
Also hier im Forum recherchiert: http://forum.oxid-esales.com/showthread.php?t=24913
Ok - Update auf PHP 5.4.30
Paypal bringt keinen Fehler mehr - dafür:
Jetzt bricht der Bestellvorgang bei Versand & Zahlungsart ab.
Weiße Seite mit:
[I]1. Warenkorb übersicht
2. Adressen wählen
3. Versand & Zahlungsart
4. überprüfen & absenden
Fertig!
Der Versand erfolgt mit:
Zahlungsart [/I]
Also PHP Error Log angeschaut - Die Tro.net Sofort Überweisung Schnittstelle macht nimmer mit. Errorlog: PHP Fatal error: Incompatible file format: The encoded file has format major ID 3, whereas the Loader expects 5 in /html/shop/modules/trosofortueberweisung/trosuoxorder.php on line 0
Tja, was nu? Ich bin echt für jede Antwort Dankbar.
Grüße Artur
Servus,
der Fehler /html/shop/modules/trosofortueberweisung/trosuoxorder.php zeigt an, dass die wohl verschlüsselte Datei vom Tronet SÜ Modul für die PHP Version 4.3 verschlüsselt worden ist.
Danke für die Antwort!
Jetzt lief das Ding auf PHP 5.3 ohne Probleme, unter 5.4 nicht.
Ich hab also jetzt die Möglichkeit entweder auf PayPal oder SÜ zu verzichten.
PayPal läuft nur unter PHP 5.4. Und für SÜ gibt es nur für Oxid CE 4.7.x ein neues Modul.
Kann es an dem Zend Guard Loader liegen?
Und wenn Ja - welche Version braucht das Modul?
Installiert ist Zend Guard Loader 3.3 und IonCube 4.4.1
Laut Dokumentation sollte das Paypal Modul ab PHP 5.2 laufen - aber is wohl nicht so…
das PayPal-Modul bzw. alle ZEND-verschlüsselten Module müssen für die entsprechend eingesetzte PHP-Version verschlüsselt werden - und man benötigt dann auch den passenden ent-schlüssler
Kann leider das neue Standalone Modul 3.2.1 für 4.9x CE nicht herunterladen.
Der Link in der Bestellübersicht funktioniert nicht.
Hat noch jemand das Problem?
und was soll da nicht funktionieren? grad probiert
[QUOTE=Hebsacker;153343]das PayPal-Modul bzw. alle ZEND-verschlüsselten Module müssen für die entsprechend eingesetzte PHP-Version verschlüsselt werden - und man benötigt dann auch den passenden ent-schlüssler[/QUOTE]
Ray, das PayPal-Modul ist nicht Zend-codiert, offensichtlich aber SÜ. Meines Wissens gibt es noch keine Zend Ver- und Entschlüsselung für PHP 5.4.
Gruß
ach so, klar - das Standalone-Module natürlich nicht
[QUOTE=domino;153424]und was soll da nicht funktionieren? grad probiert[/QUOTE]
bekomme eine Zip-Datei mit 130kB (sollte eigentlich 1300kB und entpacken nicht möglich). Mit eine, anderen Browser kommt gleich die Meldung, dass die Datei nicht verfügbar ist.
-> Jetzt ging es… Posting hat sich damit erledigt.
Wünsche einen schönen 1. Advent
Hallo zusammen,
ich hoffe ich poste hier im richtigen thread.
Habe Probleme mit der Installation von oepaypal_3.2.1_for_oxid_4.6.
Ich habe einen OXID Shop Version 4.6.5
PHP Version aktuell 5.2.17. Kann aber umschalten auf 5.3.28, 5.4.26 oder 5.5.10
Jedoch alles ohne Erfolg.
In der Zip Datei des Moduls ist ja eine Anleitung in deutsch.
Ich habe wirklich alles exakt befolgt. (Auch den Punkt vorheriges Modul 2.1. entfernen, obwohl ich vorher 2.0 hatte.)
Ich kann den Moduladapter sehen und habe unter dem Punkt Module verwalten den Pfad oe/oeadapter eingetragen.
Mein (im Moment noch einziges) Problem ist, daß ich beim Klick auf Module einrichten die Startseite des Shops sehe. Somit kann ich die Installation nicht abschließen.
Aktuell kann ich den Warenkorb zwar aufrufen, wenn ich aber zur Kasse gehe zum Punkt Zahlungsart, springt er wieder auf die Startseite.
Wie kann ich das fixen? Würde mich über eine schnelle Lösung echt freuen.
Viele Grüße ;o)
Schau am besten mal ins EXCEPTION_LOG, dort wird der Fehler aufgeführt, der die Ursache für die Umleitung auf die Startseite ist. Falsch ist aber auf jeden Fall der Eintrag “oe/oeadapter” beim Moduladapter. Dort muss “oe/oepaypal” eingetragen werden, weil erst dann das PayPal Modul im Punkt “Module einrichten” auftaucht.
Ich habe aber auch ein Problem mit dem PayPal Modul mit einem OXID Shop v4.6.8. Alles nach Anleitung eingerichtet und den Eintrag beim Punkt “Module verwalten” gemacht. Der PayPal Moduleintrag taucht auch auf, es konnte eingerichtet werden, aber für die Aktivierung ist der Pfad dazu falsch. Dort steht “/www/htdocs/***/shop/module[U]s//o[/U]e/oeadapter/modules/oe/oepaypal/metadata.php” -> siehe unterstrichener Bereich.
Wenn ich nun auf “aktivieren” klicke erscheint die Fehlermeldung “Module kann nicht geladen werden”.
Irgendwas ist an dem Modul total verquer. Da wird bei der “Einrichtung” (Klick auf den Button “Modul einrichten”) ein Verzeichnis “oepaypal” direkt im “modules” Verzeichnis des Shops erstellt, obwohl früher das Modul immer in “oe” lag. Zwar wird dann der Button “Modul aktivieren” angezeigt, aber aktiviert werden kann es eben dennoch nicht, weil die Meldung “Modul kann nicht geladen werden” erscheint.
Selbst manuelles kopieren des Ordners “oepaypal” aus dem “modules” Ordner in das Verzeichnis “oe” hilft nicht. Es kann nicht aktiviert werden.
Ärgerlich ist jedoch am meisten, dass der Hinweis “Modul kann nicht geladen werden” überhaupt keine Anmerkungen beinhaltet, warum es nicht geladen werden kann. Wenn hier wenigstens irgendwo stehen würde, was das Problem ist. So sucht man die Nadel im Heuhaufen.
Es ist zwar Sonntag, doch es wäre genial, wenn jemand eine Lösung für das Problem hat.
[QUOTE=TheDriver;153458]Schau am besten mal ins EXCEPTION_LOG, dort wird der Fehler aufgeführt, der die Ursache für die Umleitung auf die Startseite ist. Falsch ist aber auf jeden Fall der Eintrag “oe/oeadapter” beim Moduladapter. Dort muss “oe/oepaypal” eingetragen werden, weil erst dann das PayPal Modul im Punkt “Module einrichten” auftaucht…[/QUOTE]
Vielen Dank für Deine Antwort. Ich habe doch “oe/oepaypal” stehen. Hatte mich im Post nur verschrieben.
Wo finde ich denn die EXCEPTION_LOG? In welchem Verzeichnis?
[B]UPDATE:[/B] Sorry, hab die Datei EXCEPTION_LOG.txt im Verzeichnis “log” gefunden. Jedoch werde ich aus den Einträgen nicht schlau. Die neusten Einträge stehen ganz unten, oder? Kann ich die Datei bedenkenlos leeren? Damit ich eine neue saubere Datei habe die übersichtlicher ist?
Jedenfalls bin ich nicht der einzige mit diesem Problem hier im Forum. Aber eine Lösung hat noch keiner. Bin auch bereit Geld auszugeben. 50-100 Euro. Aber es muß eine schnelle Lösung her. Auch ein Modul von einem anderen Hersteller, bin ich nicht abgeneigt, wurde hier ja mehrmals empfohlen. Allerdings wird die IONCUBE LOADER benötigt. Wie kann ich feststellen, ob der bei mir bereits installiert ist? Mit phpinfo() ?
Hallo nochmal,
habe nun die EXCEPTION_LOG.txt geleert und im Adminbereich nochmal “Module einrichten” geklickt. Nach wie vor wird die Startseite im Frame angezeigt und der letzte Eintrag im LOG lautet: “Faulty component --> oeadapteroxconfig”
Kann jemand was damit anfangen?
Du kannst Du Datei bedenkenlos leeren, sind keine Einträge drin, die in irgendeiner Weise die Shopfunktionalität beeinflussen. Kannst aber natürlich auch die Datei einfach umbenennen, eine neue wird automatisch erstellt.
Mein Problem, dass das Modul nicht geladen werden kann, ist behoben. Hatte nichts mit dem Modul direkt zu tun sondern ist ein Problem im OXID, das seit eh und je existiert - Module mit gleichem Namen, die schonmal installiert waren, können Probleme verursachen, wenn sie deaktiviert und deinstalliert wurden und eine neue Version davon installiert werden soll. Es muss eine andere Modul-ID genutzt werden.
Was mich jetzt aber noch wundert: Mal wird Express-Checkout mit einer modernen PayPal Seite angezeigt obwohl ExpressCheckout komplett deaktiviert ist, und mal wird die alte, herkömmliche Seite bei PayPal gezeigt. Das verwirrt mich doch stark. Liegt das an PayPal oder hat das mit dem Modul zu tun?
Freut mich für Dich daß Dein Problem behoben wurde. Wie und wo hast Du die Modul-ID geändert? Vielleicht hilf das auch bei mir.
Hast Du meinen letzten Post gelesen? In der LOG Datei stand: “Faulty component --> oeadapteroxconfig”
Die Modul-ID habe ich in der metadata.php geändert und musste sie natürlich auch zum Teil in den Templates anpassen, weil dort exakt auf die ID zugegriffen wird, die ursprünglich vorgesehen war.
Bezüglich Deiner letzten Fehlermeldung, klingt danach, als wären nicht alle Dateien hochgeladen worden oder die Dateien sind fehlerhaft, weswegen gewisse Methoden nicht gefunden werden können.
Hoi,
[QUOTE=TheDriver;153500]
Bezüglich Deiner letzten Fehlermeldung, klingt danach, als wären nicht alle Dateien hochgeladen worden oder die Dateien sind fehlerhaft, weswegen gewisse Methoden nicht gefunden werden können.[/QUOTE]
Klingt mir nach angepassten Template-Dateien im Original ohne Benutzung eines Child-Themes. Lass da am besten mal eine oxchkversion über die Installation laufen um zu sehen, wo es kracht.
[QUOTE=TheDriver;153500]
Mein Problem, dass das Modul nicht geladen werden kann, ist behoben. Hatte nichts mit dem Modul direkt zu tun sondern ist ein Problem im OXID, das seit eh und je existiert - Module mit gleichem Namen, die schonmal installiert waren, können Probleme verursachen, wenn sie deaktiviert und deinstalliert wurden und eine neue Version davon installiert werden soll. Es muss eine andere Modul-ID genutzt werden.[/QUOTE]
Das ist in der Datenbank, in den Moduloptionen, festgeschrieben. Es handelt sich auch nicht um ein Problem in dem Sinne, weil es nicht einleuchtend ist, alle Moduloptionen zu löschen, wenn man nur ein Update des Moduls macht. Insofern wäre es ein Quark, diese Einträge einfach automatisch zu löschen. Wenn sich das neue Modul mit o.g. Fehlermeldung gar nicht installieren lässt, wäre statt der ID-Änderung der bessere Weg, die Moduloptionen vorher in der Datenbank zu bereinigen. Hier im Forum gibt es irgendwo eine SQL-Anweisung dafür.
Gruß