Da habe ich mal ne Frage. Bezahlst Du auch Trinkgeld? Wenn ja, auch mit Karte?
Ja. In meinem Beispiel, zahle Ich ein bisschen mehr als der Friseur Besuch kostet (mit Karte). Das "Zuviel" bekomme ich dann Bar auf die Kralle und gebe das Trinkgeld dann an den Friseur der mich bedient hatte.
Auch ich bin Freund vom bargeldlosen Bezahlen. Ich habe nur noch Münzen in meiner Geldbörse, um bspw. ein Parkschein am Automaten zu ziehen (wobei manche ja auch schon mit Karte funktionieren). Aber ansonsten bezahle ich nur noch mit Karte.
Also ich habe in einem Stripclub auch schon 80 Euro für Getränke und nicht für einen Lapdance bezahlt 🥸
ob ich da günstiger raus käme? Gibt's da essen?
Deine Bank kann nicht Mal Instant SEPA.
SEPA tztztz
Wir nutzen hier Vipps
Vipps
Schluckauf? 
Ich habe nur noch Münzen in meiner Geldbörse, um bspw. ein Parkschein am Automaten zu ziehen (wobei manche ja auch schon mit Karte funktionieren). Aber ansonsten bezahle ich nur noch mit Karte.
Parken ist hier bis auf die Ausnahme der Parkhäuser per App sekundengenau zahlbar.
Genauso DB und ÖPNV Tickets.
Carsharing geht sowieso per Lastschrift.
Bäcker und Supermarkt unterstützen bargeldlos.
Wenn man nicht erst fasziniert feststellt, dass man zur Kartenzahlung auch eine Karte braucht, sondern die vor dem Bezahlvorgang zur Hand hat (inklusive PIN), ist eine Kartenzahlung auch schneller als die ewige Bargeldsucherei. Die Karte ist gleich schnell, egal welchen Betrag du zahlen musst. Noch schlimmer sind nur die, die dann unbedingt auf den Cent genau zahlen müssen, weil sie haben ja irgendwo noch die zwei Cent - oder auch nicht.
Doch, es handelt sich dabei um die PHP-Extension zur Kommunikation mit MySQL/MariaDB.
Je nach Control Panel gilt aber:
- Falls nd_pdo_mysql verfügbar ist, dann diese Extension verwenden.
- Ansonsten pdo_mysql.
Darf man fragen was nd_pdo_mysql im Vergleich zum normalen Modul anders? 
Darf man fragen was nd_pdo_mysql im Vergleich zum normalen Modul anders?
Grüße gehen raus an die Vollpfosten des Control Panel-Herstellers, die sich diesen Unsinn ausgedacht haben.
Es gibt bei PHP zwei MySQL-Bibliotheken:
Und dank einiger Control Panel-Hersteller hat man nun also das Problem, dass pdo_mysql entweder richtig ist oder eben eine in Software gegossene Tretmine.
Einziger Lichtblick: Die libmysqlclient-Variante wird ab PHP 8.2 aus der mysqli-Extension entfernt. Langfristig wird diese Altlast also von der Bildschirmfläche verschwinden.
tl;dr: Du willst immer den MySQL Native Driver, aber es wird dir durch so einen Unsinn als Nutzer unnötig schwer gemacht.
Display MoreGrüße gehen raus an die Vollpfosten des Control Panel-Herstellers, die sich diesen Unsinn ausgedacht haben.
Es gibt bei PHP zwei MySQL-Bibliotheken:
- libmysqlclient - Die alte Bibliothek, stammt von MySQL und ist ziemlicher Dreck (Beispiel: Rückgabetypen sind immer Strings).
- mysqlnd bzw. "MySQL Native Driver" - Seit PHP 5.4 die Standardbibliothek für den Zugriff auf MySQL, stammt von den PHP-Entwicklern und ist die bessere Bibliothek inklusive der Unterstützung von Datentypen (Beispiel: Ein Int in der Datenbank ist auch ein Int im Result).
Und dank einiger Control Panel-Hersteller hat man nun also das Problem, dass pdo_mysql entweder richtig ist oder eben eine in Software gegossene Tretmine.
Einziger Lichtblick: Die libmysqlclient-Variante wird ab PHP 8.2 aus der mysqli-Extension entfernt. Langfristig wird diese Altlast also von der Bildschirmfläche verschwinden.
tl;dr: Du willst immer den MySQL Native Driver, aber es wird dir durch so einen Unsinn als Nutzer unnötig schwer gemacht.
Da kann man ja nur froh sein kein Control Panel zu verwenden .
Nur denke ich Mal, bis Kraut und Rüben Webhoster auf PHP 8.2 gehen, wird wieder viel Zeit vergehen, und die meisten die ja Plesk und Co verwenden sind da nicht anders.
Bin für meinen Teil aber Mal gespannt, ob am Laptop heute Abend Composer wieder richtig funktioniert. Meckerte am PC gestern von keine Schreibrechte 
Ich freue mich schon auf die anderen Überraschungen in PHP 8.2. Aka: Was alles kaputtgehen wird an vorhandener Software. (wie in 8.1)
Was alles kaputtgehen wird an vorhandener Software.
Bisher ist es harmlos: https://php.watch/versions/8.2
Das haben sie bei 8.1 auch gesagt KEKW
Aber danke für den Link 
Also Software die da Probleme bekommt, dürfte dann auch schon älter sein und deren produktiv Einsatz fragwürdig.
Also Software die da Probleme bekommt, dürfte dann auch schon älter sein und deren produktiv Einsatz fragwürdig.
Ja, beispielsweise die WoltLab Suite.
beispielsweise die WoltLab Suite.
Die WoltLab Suite ist jetzt auch nichts, das man als PHP-technisch up to date, modern, innovativ oder wie man es nennen will nennen kann. WSC 5.4 basiert auf 7.2.24.
WSC 5.4 basiert auf 7.2.24.
Mein Wunsch wäre ja, dass die aktuellste WSC Version auch immer die aktuellste PHP-Version voraussetzt
Aber gut die Diskussion hatten wir glaube schon zu oft.
Wunsch
Ja.
Der Packagesniffer basiert inzwischen vollständig auf Language Level 8.1. Der Paketserver wird PHP 8.0+ erfordern, das Gästebuch ebenfalls, der Friedhof wird im nächsten Upgrade ebenfalls 8.0 voraussetzen, wenn nicht 8.1 - hier ist noch kein Release geplant.
Ja.
Zumindest wäre der Ausschluss von nicht mehr supporteten PHP-Versionen wünschenswert. Das würde es auch bei der Plugin-Entwicklung vereinfachen.
Ihr dürft nicht vergessen, dass die Software vorwiegend für die Masse entwickelt wird und die Masse häufig auf das Wohlwollen des Hosters angewiesen ist, weil nur ein vergleichsweise geringer Anteil der Kunden einen eigenen Server betreibt. Und viele Massen-Hoster sind halt etwas rückständig, was die PHP-Unterstützung betrifft. So gibt es halt noch einige Hoster, die aus Gründen zwar PHP 7.4, aber noch kein 8.0+ anbieten (können). Und (potenzielle) Kunden dazu zu zwingen, sich einen anderen Hoster zu suchen, ist halt wenig geschäftsfördernd. Da ist es halt nur sinnvoll, bei Möglichkeit auch ältere PHP/MySQL-Versionen zu unterstützen, so lange es geht, bzw. so lange es sinnvoll ist.
IMHO gibt es auch nichts, oder zumindest nicht viel, was den Betrieb von PHP 8 (zumindest im WoltLab-Kontext) zwingend erforderlich macht. Ich würde es sogar als Schikane sehen, wenn Plugin-Entwickler ihre Plugins zum aktuellen Zeitpunkt so bauen, dass PHP 8 erforderlich ist.
Da muss ich SoftCreatR zustimmen. Ein Produkt das auf Endkunden zugeschnitten ist, muss eben auch hier und da einige Sachen beachten.
Ich für meinen Teil freue mich zu beobachten das gerade das WCF (äh WSC) sich mehr in die Richtung begibt wie man es von anderen PHP Frameworks gewohnt ist vom Funktionsaufbau, klar ist das an vielen Orten nicht Mal einfach so möglich.
Von dem was man hier so im Forum liest, denke ich daß es mit 5.7/6.0 (je nachdem was zuerst kommt) Richtung Minimum PHP 8.0 geht. Da ja langsam die Webhoster anfangen zu upgraden, muss aber auch gestehen, ich habe das nicht so wirklich im Blick.
Don’t have an account yet? Register yourself now and be a part of our community!
