Fatal error bei Modules -> Zahlungsoptionen

[-edk-]

Hallo Community,
Modified Version: 1.06
Webserver-Installation: Automatisch durch Provider all-inkl.com

Beim Aufruf von Administrator → Modules → Zahlungsoptionen öffnet sich folgende Seite:

Zahlungsweisen

Modules

Fatal error: Cannot redeclare class klarna_SpecCamp in /www/..../shop/includes/modules/payment/klarna_speccamp.php on line 202

Module /Modulname (für internen Gebrauch) / Sortierreihenfolge / Aktion 


(Anzeige bleibt leer) → kann keine Module installieren

In den letzten Tagen habe ich viel Zeit damit verbracht, den Fehler zu lokalisieren, u.a:

Dateirechte geprüft;
Dateien aus der funktionierende lokalen Installation neu hochgeladen;
Dutzende von php-Scripts durchforstet, um einen Hinweis auf die Ursache zu finden;
Versuchsweise alles, was mit Klarna zu tun hat, gelöscht;
In der Datenbank Zahlungsmodule als „installiert“ eingetragen,

..alles ohne Erfolg.

Meine Vermutung ist: Irgendwo in der DB passt ein Eintrag nicht, oder fehlt. Aber wo?

Antworten auf folgende Fragen könnten mir evtl. helfen, einen „Workaround“ für das Problem zu finden...:

- Welches Script erzeugt die Liste der verfügbaren Zahlungsmethoden?
- Kann ich dort nicht benötigte Module (z.B. Klarna) entfernen, um dem Fehler auszuweichen?

- Wo in der DB befinden sich zu Zahlungsmodulen gehörige Daten? (Außer PAYMENT_MODULES_INSTALLED)
- Können Zahlungsmodule „von Hand“ installiert/aktiviert werden? Wie?

Der Shop soll nächste Woche in den live-Test gehen (funktioniert natürlich nicht ohne Zahlungsmöglichkeiten ausser Barzahlung)

Für jede Hilfe wäre ich sehr dankbar.
edk


Linkback: https://www.modified-shop.org/forum/index.php?topic=27751.0

[Alfred]

http://www.php-faq.de/q-fehler-class-redeclare.html

[web28]

Die Module werden automatisch dynamisch aus dem Order includes/modules/payment eingelesen.

Genauer die sich dort befindenen php Dateien! Dateien kann hier also entfernen oder die Dateiendung auf z.B phpdek ändern. Diese Dateien werden dann nicht mehr berücksichtigt.

Häufiger Fehler: Eine Datei wird kopiert und Original und Kopie sind noch im Verzeichnis. Das führt zu dem Cannot redeclare class Fehler, da in beiden Dateien die identischen Klassen geladen werden sollen.

Gruss web28

[-edk-]

http://www.php-faq.de/q-fehler-class-redeclare.html

Danke, das ist schon mal ein Hinweis. Aber: Heisst das nicht auch, dass in Modified (öfters? immer?) INCLUDE statt korrekt INCLUDE_ONCE und REQUIRE statt REQUIRE_ONCE verwendet wird?

Könnte doch leicht geändert werden, oder? 
Dann mach' ich mich halt mal auf die Suche...

Gruss,
edk

[-edk-]

Bitte nicht mehr lange herumsuchen (oder doch? Z.B. Antworten auf meine Fragen?) - das Problem hat sich gelöst.

Eure Hinweise brachten mich auf den richtigen Weg - danke!

Als "Schuldige" habe ich vorerst ausgemacht:
1) mich selbst
2) all.inkl.com
3) die PHP-Entwickler, und (nur zu einem kleinen Teil)
4) die Modified-Entwickler.

Natürlich muss ich jetzt erstmal den Shop online bringen, erst danach kann ich eine genaue Beschreibung des Problems und der Lösung liefern (falls das überhaupt jemand interessiert)
,weil mit einigem Aufwand verbunden.

Dazu brauche ich auch noch Antworten von all.inkl und von der PHP-Community.

Eiinen schönen Sonntag noch, und vielen Dank,
edk

[DokuMan]

Ist das Thema damit erledigt? Konntest du es im Demoshop nachstellen?

[-edk-]

Hallo Dokuman,
ja - wie schon geschrieben - das Problem ist gelöst. Und ebenso: Falls Interesse besteht, kann ich bei Gelegenheit (momentan fehlt mir die Zeit) eine kleine Analyse beisteuern...

Gruß,
edk

[jannemann]

Hallo -edk-,

danke für deine Rückmeldung!
An einer Analyse sind wir auf jeden Fall interessiert
Das Thema habe ich damit auf gelöst gesetzt.

Schöne Grüße,
Jan

[-edk-]

Hallo Jan,
Analyse folgt asap.
Erste Hilfe für das Modified Team:

Sorgt bitte dafür, dass in Eurer Distribution keine Dateien mit GrossBuchstAben im Namen enthalten sind! (gibts einige in /includes, und viele in /includes/payment)

Grüße,
-edk-

[web28]

Das mit den Grossbuchstaben ist überhaupt kein Problem, jedes vernüftige FTP Programm kann damit umgehen.

Gruss Web28

[-edk-]

Das mit den Grossbuchstaben ist überhaupt kein Problem, jedes vernüftige FTP Programm kann damit umgehen.

Hallo,
Deine Aussage ist zwar formal korrekt, aber semantisch falsch. Sie widerspricht einem meiner seit über 40 Jahren gepredigten Prinzipien der korrekten Software-Entwicklung:

"Fehlerquellen müssen soweit wie möglich ausgeschlossen werden"

Dass Grossbuchstaben in Dateinamen eine potentielle Fehlerquelle darstellen, ist schon durch meine Anfrage bewiesen(!)

Die grösste Fehlerquelle ist natürlich nach wie vor der Benutzer. Nachdem dieser nicht eliminiert werden kann , sollte er möglichst vor folgenreichen Fehlern geschützt werden.
- Nicht alle Benutzer besitzen ein "vernünftiges FTP-Programm";
- Nicht alle Benutzer können damit so umgehen, wie es sich ein Experte vorstellt.
- Auch Experten machen Fehler. Z.B. kopiert das Installationsscript von all-inkl alle Dateien, einschliesslich Grossbuchstaben "as is" auf den Webserver (das wird sich hoffentlich demnächst ändern)

Um die genannte Fehlerquelle zu eliminieren, wäre wahrscheinlich weniger Aufwand nötig als eine Antwort zu schreiben

Und weil ich schon dabei bin...
- Warum kann der Installer nicht auf Datei-Duplikate prüfen und entsprechende Warnmeldungen ausgeben?
- Warum kann der Installer nicht gleich die Zahlungsmethode "Cash" und die Standard-Versandmethode (z.B Deutsche Post für DE) aktivieren?. Dann fällt schon mal eine Warnmeldung beim Erststart weg...
-Warum kann der Installer nicht selbständig das install-Verzeichnis löschen und die Rechte  bei den configure-Dateien auf 444 setzen? (Noch eine Warnmeldung, die wegfällt)

Für all dies gilt: Wenig Aufwand, (möglicherweise) grosse Wirkung - z- B. weniger Supportanfragen...

Ich hoffe, das kling nicht allzu dozierend -mit fast 50 Jahren Erfahrung in der Software-Entwicklung habe ich halt so meine Ansichten

Freundliche Grüße,
-edk-

[web28]

Diese Software gibt es mittelerweise auch schon 10 Jahre und mit der Grossschreibung gibt es überraschenderweise kaum Forumsmeldungen.

Außerdem haben wir mittlerweise sehr viele Module von Fremdanbietren in der Software, Auch Kalrne gehört dazu. Auch in diesen Modulen wir mit Grossbuchstaben im den Dateinamen gearbeitet. Es also gar nicht möglich alles auf Kleinbuschstaben umzuwandeln.

Jedes FTP Programm überträgt automatisch Gross/Keinschreibung, Ausnahme TotalCommander, hier muss man eine Einstellung ändern.

Warum kann der Installer nicht selbständig das install-Verzeichnis löschen und die Rechte  bei den configure-Dateien auf 444 setzen? (Noch eine Warnmeldung, die wegfällt)

Weil das nicht auf jeden Server funktioniert, im schlimmsten Fall kann man die configure Datein per FTP nicht mehr bearbeiten.

Warum kann der Installer nicht gleich die Zahlungsmethode "Cash" und die Standard-Versandmethode (z.B Deutsche Post für DE) aktivieren?. Dann fällt schon mal eine Warnmeldung beim Erststart weg...

Das wäre eine Überlegung wert, allerdings sehe ich mit dem jetzigen Zustand keine Überforderung des Shopbetreibers.

Das ist auch keine Fix&Fertig Software, bis zum Shopstart sind einige Einstellungen und Änderungen(Design, Emailvorlagen...) notwendig.

Die Stärke dieser Softwäre ist die vollständige individuelle Anpassbarkeit.

Gruss Web28

[GTB]

Ich frage mich nur, warum du so um den heissen Brei herum redest, anstatt auf den Punkt zu kommen und die Lösung zu deinem Problem schreibst :

Gruss Gerhard

[thd]

Ich hatte vermutlich ungefähr dasselbe Problem wie derjenige, der den Thread gestartet hat. Und auch bei mir lag es an einem Mischmasch aus korrekt groß/klein-geschriebenen Dateinamen und versehentlich durchgehend kleingeschriebenen. Lösung war, das von der Fehlermeldung genannte Verzeichnis mit den doppelten Dateien zu löschen und komplett neu zu übertragen (includes/modules/payment).

Reingeraten sind diese Dubletten, weil ich beim letzten Upgrade das gewohnte FTP-Programm nicht verwenden konnte und auf ein uraltes zurückgriff. Da war noch eine längst vergessene Option aktiv: "Force Lowercase Remote Names". Als im Shop dann nichts mehr richtig funktionierte, habe ich die Dateien nochmal korrekt übertragen, und es schien auch alles zu funktionieren -- bis ich eben (wg SEPA) das Lastschriftmodul deaktivieren wollte und die zunächst rätselhafte Fehlermeldung kam, ich könne da online nichts ändern (und nach Offline-Schalten des Shops übrigens auch nicht).

Da war ich natürlich froh, als ich den Thread hier las und mir den Rest denken konnte. Ist aber natürlich auch ein Indiz dafür, dass nicht jeder, der ein Problem mit Groß/Kleinschreibung bei den Dateinamen hat, gleich das Forum bemüht.

Gruß,

Thomas