Neu JJTL Shop 5.1.5 unter PHP 8.1 ???

[sebjo82]

Wäre allgemein ziemlich praktisch eine minimum.iso für den JTL Shop zu bekommen, inkl. der relevanten PHP Module - sei es jetzt auf Ubuntu Server oder RHEL. Damit wäre es dann nicht so eine große Hürde sich einen eigenen Shop zu hosten für den Fall, dass der bisherige Hoster etwaigen Ansprüchen nicht genügt

 

[css-umsetzung]

Wenn das für Euch bei JTL so ein Problem ist, dann gebt den Pluginentwicklern doch ganz klar vor, dass IonCube ab der neuen Shopversion nicht mehr von JTL zugelassen wird und zeigt in Eurem eigenen Extension-Store bitte Warnhinweise, wenn ein angebotenes Plugin IonCube voraussetzt. Wenn Ihr das aber nicht macht (wovon ich ausgehe), dann hört endlich auf, den schwarzen Peter an die SP zu schieben.

Das ist der falsche Weg. Zum ersten ist der um den es hier vermutlich gerade geht kein SP, was bedeutet das JTL Ihm "theoretisch" gar nichts zu sagen hat aber darum geht es gerade nicht.

Es geht ja eigentlich um Ioncube und darum das es nicht für PHP 8.0 funktioniert und Ihr stellt euch jetzt hin und schimpft auf JTL ... Im Grunde seid Ihr selbst schuld denn so lange ein Programmierer seine Ioncube verschlüsselten Plugins wie geschnitten Brot verkauft, sieht er sich mit dieser Art der Verschlüsselung bestätigt.

Ich mache mich gerade bei meiner Geschäftsführung zum Vollhonk, weil ich mit viel Druck erreicht habe, dass wir einen laufenden Shopware-Shop (Umsatz siebenstellig) zu JTL Shop migrieren.

Wenn ich dann so etwas lese, dann frage ich mich warum Ihr wenn Ihr soviel Umsatz macht euch das nicht von einem anderem Programmierer Entwickeln lasst, bzw. warum Ihr dann nicht eh einen eigenen Server habt?
Ein Pfandsystem ist kein Hexenwerk Themeart hat soweit ich weiß auch ein Plugin für Pfand und verschlüsselt ohne Ioncube (denke ich)

Ihr seid die Zielgruppe für diese Plugins und wenn Ihr diese kauft obwohl Ihr wisst das Ioncube eine Problematische Verschlüsselung ist, dann beschwert euch beim Programmierer und nicht bei JTL.

PS: R. K. kennt meine Meinung zu Ioncube, wir hatten deswegen schon mehrere Gespräche, daher kann er mit dem was ich hier geschrieben habe mit Sicherheit umgehen, es wäre eventuell auch viel besser Ihn mit einzubeziehen als gegen JTL Stimmung zu machen.

Ich werde Ihn mal anpingen....

 

[301Moved]

Das ist der falsche Weg. Zum ersten ist der um den es hier vermutlich gerade geht kein SP, was bedeutet das JTL Ihm "theoretisch" gar nichts zu sagen hat

Wenn ich gemeint war, nein, kein offizieller Servicepartner, also nicht gelistet

Es geht ja eigentlich um Ioncube und darum das es nicht für PHP 8.0 funktioniert und Ihr stellt euch jetzt hin und schimpft auf JTL ... Im Grunde seid Ihr selbst schuld denn so lange ein Programmierer seine Ioncube verschlüsselten Plugins wie geschnitten Brot verkauft, sieht er sich mit dieser Art der Verschlüsselung bestätigt.

Das ist halt der komplett falsche Fokus, mMn und eben - auch unabsichtlich - auch nur ein Schuld verschieben. Schuld ist aber dabei völlig irrelevant.

Ein Shopbetreiber interessiert sich nicht dafür, warum wieso weshalb. Das soll einfach laufen. Und auch wenn man Ioncube nicht mag, so gehört es aktuell zum Shop-Universum und es gibt da aus Käufer/Nutzersicht keine offiziellen Einschränkungen, warum man Plugin xyz nicht kaufen sollte. Und hier kann man auch nicht von allen vollständig technisches Wissen voraussetzen.
Das genannte Themeart Plugin als Alternative müsste übrigens bspw. erst einmal finden, weil nicht im Extensionstore (gerade geguckt, aber das ist ein anderes Thema), aber warum sollte ein Shopbetreiber auch ein neues kaufen/entwickeln lassen, wenn er bereits eines hat. Auch auf der Seite muss man auf die Kosten achten. Nur weil man auch Geld verdient, haut es ja nicht einfach raus.

Wie auch schon von anderen geschrieben wurde: Man muss sich halt Shopbetreiber oder Serviceparter auch nach den Wünschen seiner Kunden ausrichten. Das sollte auch als Shopanbieter so sein (und ist hier ausdrücklich keine Unterstellung, bevor man wieder missverstanden wurde).

Dazu gehört für mich auch ein verlässlicher Fahrplan. Wie bspw. im Nov. endet PHP 7.4, es gibt offensichtlich ein - wie auch immer wo gelagertes Problem - und PHP 8.0 läuft dann auch aus dem aktiven Support. Dann fände ich es gut, wenn es hieße: Am 01.10. kommt die neue Version, freigegeben für PHP 8.1, alle Servicepartner/Shopbetreiber haben ausreichend Zeit das zu testen und live zu nehmen.

Bei der Geoblocking-Verordnung bspw. 2018 kam es ein paar Tage vor Inkrafttreten, einmal als Beispiel. Das ist dann zu kurzfristig, gerade, wenn man bspw. auf damit verbundene Plugin-Updates oder Template-Updates dafür angewiesen ist. Man reißt also rechtlich verbindliche Termine. Und wie eigentlich immer bei diesen Terminen, sind sie weit im voraus bekannt.
Die UGW Novelle hat offensichtlich für Bedarf bei Shopbetreibern gesorgt - und auch, wenn man bspw. ein Update als Anbieter für übertrieben hielte oder nicht notwendig, wäre da vielleicht bei vielen ein Bedarf gewesen (ob nun faktisch gerechtfertigt oder nicht).

Pfand - ist ein schön Beispiel, wenn es schon aufkommt. Eines der meistgewünschten Themen im Issue-Tracker - seit 2017 dort gelistet, gewünscht aber schon viel länger. Gibt es mittlerweile - für POS. Im Shop? Fehlanzeige. Also braucht dafür Plugins, auf ausdrücklichen Hinweis hier. Wenn es "kein Hexenwerk ist", warum gibt es das dann nicht einfach und gut?
Sucht im Extension-Store, findet man bspw. das genannten Ioncube-verschlüsselte. Dass die Anzeige dort nicht optimal ist, wurde von einem anderen langjährigen Nutzer ja auch schon angeregt (vor ca. einem halben Jahr?) und das Thema ist dann versandet? Woher also soll ein Shopbetreiber die Info/Konsequenzen nehmen. Wer - mit nicht fachlichem Fokus - weiß schon, dass es Ioncube nicht für PHP 8.0 gibt. Wenn ich ein Pumuckelpuppenfachgeschäft habe, dann kenne ich mich vielleicht mit Stoffen aus, aber nicht zwingend mit Webtechnologien. Und Plugin ist Plug&Play.

Und für mich persönlich ist das problematisch, beispielhaft, das muss ausdrücklich kein anderer so empfinden.

Der Rat, dass es auch mit PHP 8.1 laufen würde, ist sicherlich gut gemeint und wird dem ein oder anderen hier auch helfen, nichtsdestotrotz ist es (bisher) nicht offiziell freigegeben und man steht im Zweifel mit der Nutzung auf verlorenem Posten, wenn man in seinem Unternehmen überhaupt die Freigabe dafür bekäme. Es gibt viele Umgebungen, da dürfen die Betreuenden das dann auch nicht einsetzen. Also kann das nicht die Lösung sein.

Persönlicher Natur bin ich kein Freund des 5er, schon durch Seitenleiste/Grunddesign, aber im Zweifel ist das erstmal vollkommen irrelevant.

Mich persönlich stört die - aus meiner Sicht vermeintliche - Entwicklung hin zu einer Software für Ein-Themen-Shops (das wurde hier schon thematisiert, will ich jetzt nicht ausführen). Da finde ich, bei großen Sortimenten wird es immer schwieriger im Handling. Auch finde ich, dass bspw. der Konfigurator unnötigerweise verändert wurde, um jetzt wieder zurückgeändert zu werden. Andere Beispiele, wie die Verfügbarkeit auszubauen als Artikelsortierung, um sie dann per Plugin wieder nachzuliefern (trotzdem danke dafür), damit aber die Sortierung der besonderen Kategorien zu zerschießen oder dem Shop still und leise um die Möglichkeit der Filter im Content und Seitenleiste parallel anzuzeigen zu berauben (die Benennung aber nicht durchzuziehen und die Einstellung in der Templatekonfiguration zu verstecken), um sie evtl. in der 5.4 wieder einzubauen lt. Issue-Tracker, gelinde gesagt schwierig und für Shopbetreiber oft wenig nachvollziehbar, mindestens aber erklärungsbedürftig und das landet dann meist vom Shopbetreiber beim Shopersteller, nicht beim Hersteller.

Denn das sind Themen, die aus Entwicklersicht (auch ohne Unterstellung), vielleicht lapidar sind, aber im Leben eines Shopbetreibers pain in the ass. Schlimmer sind natürlich Probleme mit den Zahlungsarten, die auch im Issue-Tracker und hier im Forum konstant herum schwirren. Doppelbestellungen bspw. mit gleicher Zahlungsreferenz - ich möchte gar nicht wissen, wie viele Shop-Betreiber die doppelten stornieren und erstatten.

Das sind für mich Dinge, die mit äußerster Konsequenz behoben gehören (wieder keine Unterstellung, weil mir der Einblick fehlt, ich sehe nur das öffentliche Resultat), so wie ich meinen Kunden eine möglichst fehlerfreie Leistung übergeben möchte. Ein Shop-Kunde, der mit Doppelbestellungen oder fehlgeschlagener Zahlung Erfahrungen macht, war im Zweifel mein Shop-Kunde und damit hab ich als Shopbetreiber mein wichtigstes Asset verloren: Gewinn.

Denn es geht - immer in diesem Kontext hier - ums Geld verdienen. Wenn ich das nicht fehlerfrei kann, dann ist das ein mächtiges Problem. Egal, wie nichtig ein Problem erst einmal scheinen mag.

Wenn ich nun - um das Thema zurück zu bringen - nun am 28.11. da stehe und mir die Frage stellen muss: Was mache ich? Dann fragt sich der Shop-Betreiber das ja nicht aus Lust und Laune, sondern er möchte sein Geschäft sicher stellen. Das sollte das aller verständlichste hier sein, denn das dürfte die eine Motivation für alle hier sein.

Und wenn ich dann sage, dass es mir (und damit meine ich mich alleine) schwer fällt, Shop 5 als Grundlage für ein Business zu empfehlen, dann ist das meine persönliche Wertung und Einschätzung und die ist erstmal wertfrei und da sollte in der Tat keine Beleidung rausgelesen werden. Der eine mag Ford, der andere Audi, d.h. aber erstmal nicht, dass das eine schlecht(er) ist, meist ist es eher eine persönliche Präferenz auf Grundlage verschiedene Aspekte.

Ich hab auch geschrieben, es ist anderswo nicht alles Gold was glänzt, aber oben genannte Themen hab ich in anderen Systemen so noch nicht kennengelernt (aber es mag sie auch dort geben). Am Ende ist es sowieso irrelevant, ob ich JTL Shop, Magento, Shopware, Woocommerce oder was auch immer einsetze, auch wenn das keiner gerne hört. Wichtig ist nur ganz klar eines: Es muss für den Shopbetreiber einfach laufen und die Funktionen, die ich mir erkaufe, müssen funktionieren und wenn sie das nicht tun, behoben werden.


Das nur, weil der Thread gerade an mich rangetragen wurde.

Meine Schlussbemerkung: Ich bin nicht nur ein für JTL durch Softwareverkauf Geld bringender User, sondern hier im Forum auch einer (gewesen), der - im einträglichen Sinne für JTL - kostenfrei anderen oft auch (hoffentlich) hilft (ob gut oder schlecht, wer weiß) und nicht irgendein User in irgendeinem einem Fussball-Forum oder ähnliches, wo man den Leuten vielleicht so über den Mund fahren kann.

Und auch mein Eindruck ist, dass kritische Stimmen nicht gewünscht sind (so ist hier nun mal mein Eindruck über die letzten Jahre geworden). Und es ist nun einmal ganz grundlegend keine Schuld-Frage, warum wieso etwas problematisch für einen Shopbetreiber ist. Wenn es problematisch ist, dann gehört es wie auch immer behoben, das sollte der Fokus sein - zumindest ist das meine ganz persönliche Auffassung.

Falls es jmd gelesen, danke.

 

[mh1]

Und alles nur, weil @liquid gefragt hat, wie er ihn nach dem Supportende von 7.4 seinem Shop weiter betreiben kann

...aber ich muss zugegebe, es würd mich schon interessieren, wie er das Problem jetzt für sich gelöst hat.

 

[Verkäuferlein]

Das ist der falsche Weg. Zum ersten ist der um den es hier vermutlich gerade geht kein SP, was bedeutet das JTL Ihm "theoretisch" gar nichts zu sagen hat aber darum geht es gerade nicht.

Es wird ja aber über den offiziellen Extension-Store vertrieben. Warum sagt JTL dann nicht einfach, IonCube ist ein Ausschlusskriterium für den Extension-Store?

Es geht ja eigentlich um Ioncube und darum das es nicht für PHP 8.0 funktioniert und Ihr stellt euch jetzt hin und schimpft auf JTL ... Im Grunde seid Ihr selbst schuld denn so lange ein Programmierer seine Ioncube verschlüsselten Plugins wie geschnitten Brot verkauft, sieht er sich mit dieser Art der Verschlüsselung bestätigt.

Es geht in erster Linie um die PHP 8.1-Kompatibilität (siehe Thread-Titel) des JTL Shops. Des Weiteren hat der TE ja scheinbar die betreffenden Plugin-Entwickler angeschrieben und diese haben für Ihre Plugins scheinbar eine PHP 8.1-Kompatibilität bestätigt.
Insofern schimpft hier keiner auf JTL sondern es steht die legitime Frage im Raum, ab wann der JTL- Shop kompatibel mit PHP 8.1 ist. Dass darauf dann nur eine Version benannt wird und kein Datum und der Nutzer sich dann Sorgen macht, dass damit dann sein Shop-Setup baden geht, ist doch verständlich und eben in der Versionspolitik von JTL und den gemachten Erfahrungen vieler Nutzer mit Updates und Entwicklungsthematiken begründet. Der Zeithorizont ist also vollkommen offen.

Ihr seid die Zielgruppe für diese Plugins und wenn Ihr diese kauft obwohl Ihr wisst das Ioncube eine Problematische Verschlüsselung ist, dann beschwert euch beim Programmierer und nicht bei JTL.

Und da sind wir wieder beim 1. Punkt, wenn JTL weiß, dass Ioncube problematisch ist, warum wird es dann über den offiziellen Extension-Store als kompatibles Plugin angeboten? Zusätzlich wäre es ja aus Deiner Argumentationskette heraus dann in 2 Monaten nicht mehr kompatibel. Für ein Unternehmen mit dem Umsatz von JTL (7-8 stellig), dürfte es dann ja erst recht kein Problem sein, zumindest die Kompatibilität der Plug-Ins zu überwachen, wenn @liquid nicht auf die Plug-Ins aus dem Extension Store vertrauen darf, sondern lieber in eine Individual-Programmierung investieren soll.

Klar kann man dann die Verantwortung wieder an den Nutzer abschieben, aber auch da ist die Ursache wieder die Umfeld-Veränderung, nämlich das Support-Ende von PHP 7.4 und die Erfordernis, dass dann auch der JTL-Shop mit PHP 8.1 kompatibel sein müsste.

Und warum das immer so verstanden wird, dass auf JTL geschimpft wird, wenn eine berechtigte Kritik angebracht wird, verstehe ich ehrlich gesagt auch nicht. Dass daraus Ärger resultiert, sollte doch eigentlich jedem klar sein.

 

[css-umsetzung]

Im Store wird das Plugin als kompatibel für shop 5.1 angeboten, in sofern ist alles richtig,

Warum sollte jtl da jetzt eingreifen?
Hier in dem Thread schimpfen alle auf Ioncube verschlüsselte Plugins, in sofern trifft meine Kernaussage zu.

Der 5.2er hat soviel Änderungen, das viele Plugins nicht sofort funktionieren würden wenn er heute veröffentlicht werden würde.

Also immer mit der Ruhe, wir brauchen auch etwas Zeit um Anpassungen vorzunehmen.

 

[Verkäuferlein]

Im Store wird das Plugin als kompatibel für shop 5.1 angeboten, in sofern ist alles richtig,

Warum sollte jtl da jetzt eingreifen?

Von 5.1-Kompatibilität habe ich jetzt nichts gesehen.

Als Systemvoraussetzungen nur:
Jtl-Shop 5
Ioncube
PHP 7.2-7.4

Und wie gesagt die Aussage von @liquid bezüglich seiner Anfrage nach PHP 8(.1) hier im Thread.

Aber der Vorschlag von @FMoche war, Druck gegen den Einsatz von Ioncube aufzubauen, um das Problem zu lösen. Genau den Druck könnte JTL aufbauen, indem im Extension-Store Plugins mit Ioncube nicht vertrieben werden.
Ansonsten ist Ioncube ja nicht das Problem dieses Threads, sondern die Kompatibilität mit PHP 8.1, die - nach den Informationen aus diesem Thread - vom Modul gegeben ist, vom JTL-Shop aber noch (ohne Termin) aussteht.

Hier in dem Thread schimpfen alle auf Ioncube verschlüsselte Plugins, in sofern trifft meine Kernaussage zu.

Wer schimpft denn? Es gibt halt scheinbar das Problem, dass Ioncube verschlüsselte Plugins nur bis PHP 7.4 und ab PHP 8.1 eingesetzt werden können und dementsprechend nach aktuellem Stand in ca. 2 Monaten nicht mehr mit dem JTL-Shop kompatibel sind, wenn dieser bis dahin nicht in der 5.2 released wurde und das entsprechende Plugin an die 5.2 angepasst wurde (die Zeit wird also langsam knapp und es gibt keinerlei Aussage, dass das genau innerhalb dieses Zeitraums gelöst wird).

Der 5.2er hat soviel Änderungen, das viele Plugins nicht sofort funktionieren würden wenn er heute veröffentlicht werden würde.

Also immer mit der Ruhe, wir brauchen auch etwas Zeit um Anpassungen vorzunehmen.

Und genau diese Aussage (bzw. eine terminliche Zusage der rechtzeitigen Kompatibilität) wäre doch von JTL schön, anstatt dann die Verantwortung an den Nutzer abzuschieben und dem Nutzer zu erzählen, dass der Fehler bei ihm liegt, weil er ein Ioncube verschlüsseltes Plugin gekauft hat (während man selber genau diese Plugins über den Extension Store promotet).

Auch ein Shopbetreiber möchte nicht am Tag der PHP 7.4 Abschaltung / Support-Ende erst wissen, ob alles weiter funtkioniert und braucht ggf. Zeit für Anpassungen.

 

[hula1499]

Wir sind doch nicht relevant, JTL geht halt den einfachsten Weg, 0 Support, 0 Hilfe -> Meldet euch beim SP, wir geben ja sowieso keine Daten bekannt wann wie 5.2 mit 8.1 kommt und alles andere ist uns egal.

Auch mein Post vom Mai, dass zumind. mal die Infos im Extension angepasst/erweitert werden sollten hat ja wiedermal 0 gebracht -> nat. nichts davon umgesetzt.
Wir sollen lieber Mails an SP schicken....

Ich mein:
https://www.jtl-software.de/extension-store/affiliate-programm-jtl-shop-5

Systemvoraussetzungen
JTL- Shop 5
MySQL 5.6

Natürlich ist jetzt der SP "schuld"...aber wer verkauft mir das Plugin im Extension und ist damit verantwortlich?

Auch ein Shopbetreiber möchte nicht am Tag der PHP 7.4 Abschaltung / Support-Ende erst wissen, ob alles weiter funtkioniert und braucht ggf. Zeit für Anpassungen.

Ja, man mag es ja nicht glauben, aber auch Shopbetreiber möchten Ihren Kunden ein uneingeschränktes, optimiertes und angenehmes Kauferlebnis bieten.
Dazu müssen schon mal Shop/Pluginversionen anständig und vollumfänglich getestet werden - was bei manchen halt nicht in 1h geht....

(während man selber genau diese Plugins über den Extension Store promotet).

Man kassiert ja auch Provision dafür...

 

[liquid]

Und alles nur, weil @liquid gefragt hat, wie er ihn nach dem Supportende von 7.4 seinem Shop weiter betreiben kann

...aber ich muss zugegebe, es würd mich schon interessieren, wie er das Problem jetzt für sich gelöst hat.

Ich habe das Problem jetzt zumnindest "teilweise" gelöst, damit ich überhaupt weiterkomme:

- Die Migration von Shopware zu JTL Shop (ich nenne das Projekt jetzt mal unseren "Hauptshop", weil er der größte Umsatztreiber im Onlinegeschäft für uns ist) hat noch vor seinem go-live einen Umzug von Hosteurope zu Hetzner bekommen (jeweils eigener Managed Server). Der Vorteil bei Hetzner ist, dass man noch deutlich länger mit EOL-PHP agieren kann. PHP 7.4 wird dort noch mindestens ein halbes Jahr laufen, eher noch länger (hat man mir beim Support bestätigt). So kann ich (hoffentlich) die Zeit überbrücken, bis irgendwann mal JTL Shop 5.2 veröffentlicht ist und die ganzen Pluginhersteller ihre Anpassungen vorgenommen haben.

- Zwei weitere JTL-Shops, die bereits länger im Live-Betrieb sind, verbleiben erstmal bei Hosteurope. Grund dafür: Es läuft lediglich ein wirklich relevantes Plugin mit Ioncube dort (Zusatzartikel/Pfand von Netzdinge) und der Entwickler hat mir fest zugesagt, bis November eine PHP 8.1-Kompatibilität zu haben. Wir sind im engen Austausch und schon ziemlich weit. Der Risikoauslöser liegt hier jedoch bei JTL, denn der Shop 5.1.5 ist bekannterweise nicht ´von JTL für PHP 8.1 freigegeben, läuft aber im Testbetrieb unter 8.1 bislang vollkommen problemlos. Sollte sich herausstellen, dass es doch Probleme gibt, dann muss ich mit den beiden Shops gezwungenermaßen auch umziehen. Dann hätte ich bei den Shops einen halben Tag Ausfall und viel Arbeit, was natürlich mehr als ärgerlich wäre.

Ansonsten ist es schon sehr interessant, was man hier alles so lesen darf, auch von anderen SP. Jetzt sind wir User also schon selbst schuld, wenn wir im offiziellen Extension-Store ein Plugin erwerben, das mit Ioncube läuft. Erst denken, dann schreiben, das hilft manchmal. Denn viele Shopbetreiber wissen nicht einmal, was Ioncube überhaupt ist. Sie brauchen eine Funktionalität, die JTL Shop nicht von Haus aus liefert. Sie schauen im "offiziellen" Extension-Store und finden genau diese Funktionalität, kompatibel zum aktuellen Online-Shop und kaufen das Plugin dann. Da ist es sowas von sch...egal, ob der Umsatz 100.000 EUR oder 5 Mio EUR beträgt. Problem vorhanden, Problemlösung vorhanden, installieren, testen, kaufen, fertig! Individuelle Lösungen gebe ich immer erst dann in Auftrag, wenn ich im Extension Store KEINE Lösung für das Problem finde. Und das PHP 7.4 bald EOL ist, wird vielen auch erst bewusst geworden sein, nachdem sie diesen Thread gelesen haben.

Gruß aus dem Norden
Ingo

 

[mh1]

@liquid
Danke für die Rückmeldung deiner Lösungen.
Ich bin ehrlich überrascht, dass Hetzner die Managed Server weiterhin auf der 7.4. läßt. Ist für dich jetzt aber mal eine gute Lösung

 

[ergowebshop]

Als Shopbetreiber und auch als Programmierer habe ich mich jetzt durch diesen Thread gelesen, erst aus Neugier, dann huiuiui trotzdem was dazu gelernt und ein bisschen Senf gesammelt zum dazu geben:

Zu erst einmal habe ich unseren Hoster Mittwald kontaktiert, die sagten:
"Eine Abschaltung der PHP Version 7.4 ist bei uns nicht geplant.
Sollten wir eine Abschaltung planen, melden wir uns 3-6 Monate im voraus per E-Mail.
Da wir sogar noch sehr alte 5.6 PHP Versionen unterstützen und 7.4 von den meisten Kunden genutzt wird, (u.s.w.)"...

Das klingt doch mal planbar und die Antwort kam trotz Freitag Nachmittag nach nur 5 Minuten.

Das soll keine Wertung sein über Sicherheitsaspekte alter Versionen oder was wer supporten sollte, einfach nur so falls noch jemand einen Hoster sucht, es gibt also die 7.4 nicht nur bei Hetzner weiterhin.
Darüber fand ich auch zufällig heraus, dass wir ionCube beim Hoster gar nicht aktiviert haben, somit also alle Plugins, die wir einsetzen, nicht darauf angewiesen sind. Wieder was gelernt.

---

Es wird ja aber über den offiziellen Extension-Store vertrieben. Warum sagt JTL dann nicht einfach, IonCube ist ein Ausschlusskriterium für den Extension-Store?

Und dazu fällt mir glatt ein aktuelles Beispiel ein:
Gerade heute waren wir auf der Suche nach einer besseren Suchfunktion für den Shop, so mit autocomplete, bisschen fehlertolerant, "meinten Sie?" und so.

Erstes Ergebnis: "JTL-Search", kostenfrei steht da..., ja ne nix da, das gilt nur für die Testversion (wer weiß ob so eine Angabe nach o.g. Omnibus-Richtlinie zulässig ist, das nur nebenbei).
Bei unseren ~7.000 Artikeln kostet das 29,99, aber pro Monat.

Weiter gesucht und "Live Ajax Suche" von NetzDinge gefunden, passt auch für unsere Anforderungen, kostet 130€, aber im Jahr.

Warum erwähne ich das jetzt?
Der Anbieter weist auf seiner Homepage korrekterweise darauf hin, dass man es unbedingt vor dem Kauf testen soll.
Im Extension Store steht unter dem Tab Dokumentation, dass ionCube benötigt wird, auch löblich, aber liest auch nicht jeder gleich.
Ich denke das meinte hula bereits, solche Anforderungen könnten prominenter dargestellt werden, z.B. zwischen Preis und auschecken, da wo z.B. auch steht "dieses Plugin gibt's auch für v4" oder so.

Gut ich hatte eh vor es zu testen, gesagt, getan. Im Plug-In Manager: bäm, Problem, benötigt ionCube. Denn auch ich habe die o.g. Hinweise erst danach gesehen.

Nun weiß ich zwar mittlerweile, dass es bei meinem Hoster bei der 7.4 bleibt und ich Ion nur anschalten müsste, aber wenn man nicht dreimal genau guckt und es vorher testet, nun ja was soll ich sagen, manch einer hätte vielleicht 130€ auf 12 Monate verbraten für etwas, was in dessen Umgebung in 2 Monaten die Hufe hochgerissen hätte.
Und stellt euch vor es gäbe da keinen Fallback auf die normale Suche (weiß nicht ob es so ist) und euer Shop steht eines morgens ganz ohne Suchfunktion da. Ja Prost, dann auf nimmer-wiedersehen liebe Interessenten.

Hat jetzt auch so einen faden Beigeschmack für uns, wir sind intern unschlüssig ob wir uns nun das Plugin kaufen sollten, nicht dass dann noch irgendwas ist was man noch nicht weiß (schon klar, 100% sicher gibt's nicht).
Blöd jetzt auch für den Plugin Anbieter, ein Interessent möglicherweise vergrault ob der Umstände.

Ist jetzt alles nur ein Beispiel von unzähligen Szenarien.

Nun zu der zitierten Frage von Verkäuferlein:
Das selbe Ajax Suche Plugin für 130€ gibt es auf der Homepage des Anbieters für 99€

Es könnte also den Schluss nahelegen, dass JTL ordentlich mitverdient am Verkauf von Drittanbieter-Plugins.
Ist ja auch legitim, sie übernehmen die Abrechnung und für die Anbieter ist es dann halt prominente Werbung statt gar nicht gefunden zu werden.
Noch Fragen warum man nicht einfach IonCube als Ausschlusskriterium deklariert?
Klingt vielleicht blöd, ist aber womöglich genau so (unter anderem).

In dem Sinne: schönes langes Wochenende.

 

[mh1]

(...)falls noch jemand einen Hoster sucht, es gibt also die 7.4 nicht nur bei Hetzner weiterhin.

Ionos und Strato bieten ja generell immer an, PHP Version mit ausgelaufenem Community Support in einem speziellen Tarifmodell weiterlaufen zu lassen.

 

[SebiW]

Soweit mir bekannt supportet Debian die 7.4 noch weiter und pflegt Bugfixes nach. Debian ist im Serverumfeld jetzt ja nicht unbedingt ne kleine Nummer - ich vermute da einen passenden, dann auch sicheren Hoster zu finden sollte kein großes Problem sein.

 

[MP1]

Ähnliches Problem... der JTL Connector für Shopware 5 ist leider auch nur bis PHP 8.0 kompatibel. Auf unsere Nachfrage, wann ein Update des Connectors mit Unterstützung für 8.1 verfügbar sei, erhielten wir die Antwort: "... ist in Planung...". Bedeutet für uns, dass wir ebenfalls ab 14.11. (da 8.1 mit Ioncube benötigt wird) nicht mehr mit JTL als Wawi arbeiten können! Hurra!