Beiträge von faro

    Habe mal gerade eine Testbestellung bei dir gemacht (Versucht). Ich denke dass dein Problen in den Zahlungsmodulen selbst liegt. Irgendeine Einstellung ist falsch oder nicht gesetzt, sodaß dein Fehler:

    "Bitte wählen Sie eine Zahlungsmethode

    Entschuldigung, keine der Zahlungsarten passt zu den Eigenschaften Ihrer Bestellung. Bitte."

    angezeigt wird.

    Deine angelegten Zahlungsarten passen nicht zu Deutschland und meiner Lieferadresse. Das würde ich mal überprüfen.

    Dann habe ich alle Virtuemart Datenbanktabellen (Vers 3.6.10) exportiert und in dei XAMPP Installation importiert.

    Das ist keine gute Idee, dadurch hast den Fehler aus deinem Projekt in die XAMPP Installation mit importiert.


    Ich würde an deiner Stelle mit dem Full- Installer einen Testshop einrichten und in diesem die Zahlungsmodule neu anlegen. Klappt es in diesem, dann ist in der Tat in deiner Live-Installation etwas "Vermurkst"

    Hallo,


    auch dir ein gesundes neues Jahr 2020. Die meisten hier im Forum antworten, wenn sie eine Lösung bzw. einen Lösungshinweis kennen. Anders herum wäre es kontraproduktiv wenn viele schreiben würden, "Das weiß ich nicht".

    Womöglich liegt es auch daran, dass die Feiertage erst ihren finalen Abschluss finden müssen. Daher rate ich noch zu etwas Geduld. :)

    Hallo Andreas,


    da ist mir nichts bekannt. Auch mein Shop (Asche auf mein Haupt) war mal ein VM 1.0 unter Joomla 1.5, und wurde zusammen mit Joomla über 2.5 und VM 2.0 bis hin zu Joomla 3.x und letztendlich VM 3.x Upgedatet. Dieser läuft bis heute Stabil.


    Joomla selbst ist hier auch nicht das Problem denke ich. Jedoch gab es mal beim Wechsel VM von 2.x auf 3.0 eine Datenbanknpassung welche mit den VM Systemwerkzeugen oder so ähnlich gemacht werden musste. Was jedoch genau, weiß ich ich nicht mehr. Dazu ist es zulange her, wo ich das gemacht habe.


    Aus der ferne ist dein Problem denke ich nicht zu lösen. Da sollte ein Profi sich das mal genauer im Backend ansehen. Nach dem Motto, repariert werden kann alles! :)

    habe alles noch einmal auf einem Testsystem überspielt. Fehler verschwindet, wenn ich auf PHP 7.1 zurückgehe.

    Hallo Andreas,


    das einzige was ich dir sagen kann ist, dass es nicht am Joomla- Core und an VM liegt. Ich selbst nutze zur Zeit PHP 7.3 ohne Probleme.

    Was ich mir aber denken kann ist, dass es mit irgend einer Erweiterung bei dir zu tun haben muss. Hierbei kann es sich um eine Komponente, Modul oder Plugin handeln, welches nicht mehr ab PHP 7.2 kompatibel ist, und daher bei dir diesen Fehler verursacht. Das gilt es nun heraus zu bekommen.


    Das erklärt dann auch, dass wenn Du auf PHP 7.1 zurück gehst, wieder alles funktioniert.


    Welchen Hoster nutzt Du?

    Hm, ich versuche mich gerade in dieses Modul hineinzudenken, in wie weit es Veränderungen in den einzelnen Produkten vornehemen kann?


    Ich kann dir daher momentan leider nicht weiterhelfen. Bestimmt schaut der Stefan hier heute nochmal vorbei. Er hat in solchen Dingen den besseren Durchblick.

    Hallo losrofolos,


    über die Kategorien habe ich es bisher noch nie gesteuert. Oder habe ich da was übersehen?

    Bisher habe ich bei mir jedem Produkt ein bestimmtes Gewicht zugeordnet. Diese wiederum greifen auf meine DHL-Versandarten mit mehreren Versanstufen zu. Demnach werden die Vesandkosten von kleinen bis großen Produkten automatisch errechenet und zum Warenkorb hinzugefügt.


    das ist natürlich bei der erstellung der Versandarten erst einmal ewas Fummelarbeit.

    Hallo Stefan,


    dafür habe ich das mit den 30 Sekunden Timeaout überlesen. :D


    Noch mal kurz für kheber92 zur Hilfe bei der Überlegung, den Ratschlag vom Stefan zu beherzigen, was das Hosting bei Michael Schulze betrifft.


    Ich hatte vor gut einem Jahr bei einem bekannten geholfen, VM nach langer Ruhepause wieder zu Beleben. Dazu wurden alle Bezahlmodule, Versandmodule bis hin zu AmazonPay überarbeitet. Wir waren bei den Testbestellungen in den Sandboxen dem Wahnsinn nah. Maximal die hauseigene VM per Vorkasse ging sauber durch. Da ich nur im Backend und per FTP rumfummelte, erfuhr ich viel zu spät, dass wir auf einem Hosting von T-Online saßen. Nicht einmal SEO funktionierte Problemlos.


    Daher gehe ich was 1&1 betrifft sogar noch einen Schritt weiter und sage, dass selbst ein teureres Paket hier nicht empfehlenswert ist. Schau dich wie der Stefan es hier schon schrieb, nach einem Hoster um, welcher VM unterstützt, bzw. den Anforderungen an Schopsystemen entspricht. Auch von "0" EUR Hostern, welche ihre Dienste erst einmal zum Testen anbieten, kann ich aus eigener Erfahrung nur abraten. In diesen angeboten sind die Serverkonfigurationen seitens des Hosters dermaßen zurückgedreht, dass schon die installation eiens Shop's große Probleme bereiten kann.


    Nicht ohne Grund wird hier im Forum neben den Versionen immer der Hoster mit erfragt.


    Schönes Wochenende!

    Hm, was das execution time Problem betrifft, bleibt die Frage, ob die Weiße Seite sofort erscheint oder erst nach einer bestimmten Zeit.

    Der Datenbaktyp sollte jedenfalls auf MySQLi geändert werden. Wurde auch hier mal irgendwo besprochen. MySQLi läuft zumindest stabiler ab PHP 7.


    Es wird schwer, aus der Ferne das Problem zu bearbeiten. Es kann aber auch das Template oder Framework die Ursache sein. Welches wird denn verwendet?

    Gibt es n Link zum Shop?


    Edit: Lief der Shop vorher Problemlos? Oder traten die Fehler erst nach einer gewissen Zeit oder auch nach einem Update einer anderen Koponete auf?

    Ich persönlich habe immer etwas Magenschmerzen beim Hoster 1&1. Für ne kleine Webseite mag es ja ok sein. Aber für n Shop? Ich weiß nicht recht, ist nur so ein privates Gefühl.

    Hallo,


    es kommt halt drauf an, wieviele Artikel der Shop anbietet. da die DB in den wenigsten fällen ebenfalls duch den Hack in Mitleidenschaft gezogen wird, könnte man diese sichern, um mit dieser Local den Shop zu Migrieren.


    Bei den Image- Ordnern kann es bei einem Hack schon problematischer werden, da Bilddateien ebenfalls kompromitiert sein können. Diese müssten daher genauer unter die Lupe genommen werden.


    Nun jedoch reden wir hier über J1.5. Eine Migration einer so alten Version ginge nur über viele Zwischenschritte. Zuerst auf J2.5 danach zu J3.3 und danach ebenfalls nur duch weitere Zwischenschritte letztendlich zur J3.9.13


    Da aber diese sehr alte gehackte J1.5 Installation generell erst einmal auf localer Ebene professionell bereinigt werden müsste, bevor sie dann die nötigen Zwischenschritte erhält, würde ich den ganzen Kram an den Kunden zurückgeben und ihm ein Angebot für eine Neuinstalltion unterbreiten.


    Über das Thema FAHRLÄSSIGKEIT (J1.5 und Shop) seitens des Shopbetreibers und die dazugehörigen eventuellen rechtlichen Probleme, mit so einem alten System Online zu Handeln, möchte ich hier erst gar nicht Reden.