Wuschel

Das Modul Internetmarke ist doch seit mehr als 2 Jahren Geschichte und kann nicht mehr aktualisiert oder verwendet werden. Das Modul DHL von Silbersaiten funktioniert zwar auch nicht richtig, aber es funktioniert wenigstens trotz seiner Macken. Ich kann da allerdings nur für den Postbereich sprechen (und für PS 1.6), da wir die Paketfunktion nicht nutzen. Die kann bei uns nicht auf die Portokasse zugreifen. Silbersaiten scheint an Fehlerbehebungen nicht interessiert zu sein und reagiert nicht. Sie haben in den letzten 2 Jahren nicht mal gemerkt, dass das Backend-Demo auf ihrer Homepage nicht funktioniert und sich statt dessen in einer Endlosschleife verliert. Muss man noch mehr sagen?

Wozu der ganze Aufwand? Eolias neues 1.6-Upgrade (derzeit Version 1.6.2.3) läuft problemlos unter PHP 8.2: https://www.prestashop.com/forums/topic/464197-prestashop-16130-demoshop/ Upgrade auf diese Version ist sogar von Prestashop 1.5 möglich. Probleme bei 1.6 unter PHP 8 können da höchstens Drittanbieter-Themes oder veraltete Module sein, die man nachträglich anpassen müsste.

Das Problem wird mit dem nächsten Release 1.6.2.2 behoben sein. Allerdings empfiehlt es sich sowieso, ein Backup von Files und DB manuell zu machen und nicht über den Upgrade-Prozess. Das kann dauern und geht auch oft schief. Das war auch früher schon so. Das derzeit verfügbare autoupgrade-Modul wird gerade auch nochmal überarbeitet.

Das mag so wirken, aber ich glaube nicht, dass es so ist. Sie sehen dieses Problem tatsächlich nicht. Das war schon bei den Programmierern von 1.6 so, da musste man sich den Mund fusselig reden, um durchzudringen. Schon um AEUC durchzudrücken, bedurfte es einiger Anstrengungen. Und die Leute, die es damals irgendwann begriffen hatten, gehören längst nicht mehr zum Entwicklerteam. Das Missverständnis haben wir hier doch schon oft diskutiert. Open Source hat nichts mit Gratismentalität zu tun. Prestashop war immer ein Geschäftsmodell, und dazu gehören Lizenzvergaben, der ganze Addons-Markt und vieles mehr. Das gilt aber für alle erfolgreichen Open-Source-Modelle. Ich glaube, das ist diese Version bereits, denn @Eolia und @doekia, die hier beteiligt sind, gehören seit Jahren zu den herausragenden Prestashop-Entwicklern in Frankreich. Sie haben sich nie von Prestashop vereinnahmen lassen, auch nicht in den Glanzzeiten dieses Forums, die ja längst vorbei sind. Wenn Du also was zu Gelingen in Deutschland beitragen willst, dann steht es Dir frei, das zu tun. Es ist alles Open Source. 😉

Vor ein paar Jahren habe ich tatsächlich mit dem Gedanken gespielt, aber dann hat @Traumflug TB fast an die Wand gefahren, auf jeden Fall in die Inkompatibilität mit Prestashop hineinprogrammiert, obwohl Michael Dekker schon damit angefangen hatte (u.a. Umwandlung etlicher Variablen von snake [my_Variable] zu camel case [myVariable]). Seinen Nachfolger @DataKick finde ich zwar herausragend, und er hält das Projekt schon bemerkenswert lang am Laufen, doch ich glaube nicht, dass es als One-Man-Show auf Dauer bestehen kann. Auch nach Jahren praktisch immer noch keine Fremdmodule, und jedes Theme muss aufwendig angepasst werden, weil die Prestashop-Welt den neueren Versionen von TB seit Version 1.1 zunehmend verschlossen bleibt. Als Entwickler überlegt man es sich halt zweimal, ob es sich lohnt, für einen eng begrenzten Markt wie TB-Nutzer seine Projekte eigens umzustricken, damit sie unter TB lauffähig sind. Und mittlerweile glaube ich, dass die Chancen schlecht stehen, dass sich daran noch was ändern wird.

Na ja, zig Jahre ist ja ein büschen übertrieben, oder? Die letzte Version, die man von Whileys Seite downloaden konnte, war von 2019. Eolia hat allerdings eine (leicht modifizierte?) Uraltversion aus dem Jahre 2015 beigefügt. Und die steckt voller Fehler. Version 2.0.2 war übrigens auch nicht viel besser und m.W. die letzte offizielle Version mit deutschen "Vorfahren", danach kam die grottige französische Eigenentwicklung PS_Legalcompliance mit Prestashop 1.7. Da dieser Irrweg Prestashop 1.7, vor dem ich schon im Januar 2017 gewarnt habe (hier die späte "Abbitte" des Chefprogrammierers), ja jetzt mit 8.0 endgültig verlassen werden soll, kam wohl wieder mal alles auf den Prüfstand - auch das Rechtssicherheitsmodul. AEUC scheint außer in Deutschland sowieso niemanden zu interessieren, denn die entsprechenden EU-Auflagen sind wohl eher auf Deutschlands Mist gewachsen und werden nur bei uns von der Abmahnmafia akribisch geprüft. In Frankreich wird AEUC praktisch nicht eingesetzt. Die Kunden wissen auch so, dass im Brutopreis die MwSt enthalten ist und dass es so was wie Versandkosten gibt. Niemand braucht da die Einblendung nahe bei Produktpreis. Deswegen können auch die aktuellen Programmierer von 1.7.8 und 8.0 mit AEUC bzw. PS_Legalcompliance nichts anfangen und haben die Entwicklung dieses Nachfolger ganz eingestellt. Ich bin jedenfalls heilfroh, dass es mit 1.6 noch ein Weilchen weitergeht.

Hallo Whiley, Kooperativ im Rahmen des normalen Supports, ja, aber meist eher unwillig, wenn es darum ging, ein nicht für die jeweilige PHP-Version vorgesehenes Theme an selbige anzupassen. Außerdem scheint es Konsens in diesem Unternehmen darüber zu geben, dass man dem Kunden auf keinen Fall verrät, was man auf dessen Server (denn die Jungs wollen immer gleich den Zugang) angestellt hat, um das Theme zum Laufen zu bringen. Ich habe aber noch ein anderes Problem. Mag vielleicht serverabhängig sein, aber ich bekomme zu viele Smarty-Fehlermeldungen bei 1.6.1.30 von @Eolia. Er arbeitet ja noch mit einer - ich vermute mal: angepassten - Version 3.1.33, die eigentlich kein PHP 8 beherrscht. Das ist erst bei Smarty 4 der Fall, daher wird diese Version auch bei TB eingesetzt. Gut, mit ein paar Tricks kann man sie auch in 1.6.1.30 einsetzen, wie ich heute herausgefunden habe, aber auch das geht nicht ohne Fehlermeldungen ab, die sich dann aber im Rahmen halten. Dann wäre da noch die Sache mit den Overrides. Wie die bei @Eolia funktionieren (denn das tun sie!), weiß ich wirklich nicht, da er diesen Bereich wohl umprogrammiert hat. So gibt es - was unweigerlich zu Unverträglichkeiten mit Fremdmodulen wie z.B. dem nützlich gc_clearcache von @Gurkcity führen dürfte, die nicht damit umgehen können, dass es bei Eolia keine class_index.php mehr gibt, dafür aber ein neues Smarty-Cache-Verzeichnis classes. Darin übernimmt die index.php anscheinend die Aufgabe der class_index.php. Wo allerdings gespeichert wird, ob und wo es Overrides gibt, habe ich noch nicht herausfinden können. Erst dann könnte ich mir die Fragen beantworten, ob die Fehlermeldungen, die ich gelegentlich bekomme, teilweise von einem falschen Handling von Overrides herrühren oder andere Ursachen haben. Viele Grüße Wuschel

Danke für das Upgrade auf 1.6.1.30 und das erneute Anpinnen @Whiley. Wie ich bemerkt habe, verfügst Du anscheinend auch über eine PHP8-taugliche Version von AdvancedEUCompliance. Das Hauptproblem scheint mir aber zu sein, dass außer dem mitgelieferten Default Boostrap (und dem eleganteren, aber leider ganz und gar nicht mit PS 1.6 kompatiblen NIARA Theme on TB) anscheinend kein Theme für 1.6 auf PHP 8 vorbereitet ist. Die meisten schaffen es ja nicht mal unter PHP 7.4 ohne Fehlermeldungen. Eine absolute Katastrophe sind hier für mich die beliebten Themes Transformer und Panda von ST Themes. Da hangelt man sich von einem Fix zum nächsten, weil die total viele Module mitbringen, die sich alle in der Datenbank ausbreiten. Und das Standard-Theme von PS mag ich nicht.

Salve Quintili Vare, annon haec postum praecedere omnes alias postes? Et maneat supra. Sicut hodie dicitur: 'confixi'.

Es haperte noch hier und da im BO, so dass noch Bugfixes nötig waren, aber die Version 1.6.2 läuft inzwischen stabil unter PHP 8 und wird in Kürze von Eolia zum Download freigegeben. Mit der mitgelieferten Version des autoupgrade-Moduls dürfte dann das Upgrade auf dieses Release problemlos möglich sein. Für frühe Versionen von 1.6.1 wäre vermutlich ein Zwischenupdate erforderlich, bei Prestashop 1.5 bleibt nur die sukzessive manuelle Übertragung der Datenbank nach vorherigem genauen Vergleich der Felder und Indizes nach dem Motto "Zäh nährt sich das Eichhörnchen". Mit einigermaßen guten SQL-Kenntnissen geht das aber auch. Bei TB bin ich inzwischen doch etwas skeptisch, denn es gibt zwar inzwischen die Version 1.4, aber weiterhin kaum Themes und Module von Fremdanbietern für diesen Fork.

Das scheint tatsächlich wieder der alte Bug zu sein. Man muss sich einfach daran gewöhnen, dass jede neue Generation von Prestashop-Entwicklern dazu neigt, die Fehler der vorhergehenden zu wiederholen. Mein damaliger Fix für die classes/Tools.php von 1.7.5, auf den du hier verlinkt hast, wird selbst für die neueste Developer-Version von PS 8.0 benötigt.

Die Anfrage funktioniert zwar, gibt aber vom zweiten Tag nur die Bestellungen bis Tagesbeginn 00:00 Uhr aus, also praktisch keine einzige. Außerdem erschließt sich mir nicht, wieso ein Bearbeitungsdatum im Kundendatensatz das Bestelldatum ersetzen soll.

Das Einfachste ist eine SQL-Abfrage der ps_order_cart_rule. Wer hier nach der Gutscheinbezeichnung im Feld name sucht, wird fündig. Wem es dann nicht reicht, nur die id_order ausgeworfen zu bekommen und den Kunden selbst der Bestellung zuzuordnen, der müsste die Abfrage halt um die Tabellen ps_order und ps_customer erweitern.

Nochmal zum Modul von Silbersaiten: Obwohl es als das "offizielle" DHL/DP-Modul sowohl von Silbersaiten als auch von DHL angepriesen wird, hat Silbersaiten es anscheinend immer noch nicht geschafft, die Warenpost an die neuen Versandbedingungen von DHL anzupassen. Immer noch werben sie mit der Portokasse der DP, obwohl sich die Versandformen komplett am 1.7.22 geändert haben und die übliche (internationale) Warenpost gar nicht mehr von der DP versandt wird, sondern auf DHL übergegangen ist. Daher lassen sich die Versandarten im Modulteil Deutsche Post auch gar nicht mehr aktualisieren. Das Modul halte ich z.Z. für völlig nutzlos. Anfragen nach Updates werden anscheinend von Silbersaiten ignoriert. Zu den verschlechterten Rahmenbedingungen gesellt sich nun auch noch eine saumselige Softwarefirma. Ärgerlich!

In PHPMyAdmin deine Prestashop-Datenbank laden. Oben im Menü SQL anklicken Im Fenster den folgenden Befehl eingeben: TRUNCATE TABLE `ps_specific_price`; Das Präfix ps_ ist der Standard, wenn Du da etwas geändert hast, muss das Tabellepräfix im Befehl natürlich angepasst werden. Beim Befehl TRUNCATE bleibt die leere Tabelle mit allen Feldern erhalten.