Aus aktuellem Anlaß muß ich mich wieder mit PHP-Programmierung befassen - Grund: Der vom Provider "verordnete" Umstieg von Ver. 7.4 auf 8.0. Ergebniss: Meine rfe-Datenbank -> Beitrag "rfe-Datenbank - OnLine", bzw. direkt -> http://www.ps-blnkd.de/rfeDB/rfeSuchFormular.htm funktioniert nicht mehr! Das Reparieren mit Try&Error macht nun wirklich keinen Spaß, deshalb habe ich mich nach einer IDE für PHP umgesehen. Aber auch das ist nicht so einfach wie angenommen - freie, dafür geeignete Software habe ich nicht gefunden. Mit einer Ausnahme: phpDesigner von mpsoftware.dk. Nun konnte ich zwar eine Demoversion davon testen, aber ob die PHP 8.0 und Mysql 7.4 unterstützen, konnte ich aus der Doku nicht entnehmen. Eine diesbezüglich Anfrage beim Hersteller läuft ... Habt Ihr evtl. noch einen anderen Tip für mich? Grüsse aus Berlin PSblnkd
Keine Tipps aber fast das gleiche ungelöste Problem, daher Solidarität und Hoffnung auf nützliche Antworten.
Bei einer schnell zusammen gehackten Tabelle hatte ich das auch. Ich weiss schon nicht mehr, was es war, nur dass ich irgendwo noch einen check dazutun wurde, weil PHP irgendwo etwas strenger geworden war, und es nicht mehr ignorierte. Da muss man effektiv das Programm nochmal durchgehen und durchdenken, um zu sehen, was da neu nicht mehr läuft / btw. wie das vorher überhaupt ging. Es gibt noch so statische Analysetools, wie z.B. phpstan. Aber das wird vermutlich viel mehr anmekkern, als nur das was du suchst, und das womöglich nicht einmal. Ist aber trotzdem gut, wenn man sich das mal anschaut, manchmal ist da sogar was gutes dabei.
Peter S. schrieb: > Das Reparieren mit Try&Error macht nun wirklich keinen Spaß Ist auch nicht nötig, ist ja alles schön dokumentiert: https://www.php.net/manual/en/migration80.php
Als IDE für PHP kann ich nur JetBrains PhpStorm empfehlen. Ist allerdings nicht gratis, aber für nur temporär mal konvertieren reicht ggf. auch die 30-Tage-Testphase...
phpstorm + xdebug + lokale entwicklungsumgebung einrichten. bluppdidupp schrieb: > Als IDE für PHP kann ich nur JetBrains PhpStorm empfehlen. > Ist allerdings nicht gratis, aber für nur temporär mal konvertieren > reicht ggf. auch die 30-Tage-Testphase... da war/ist die 2020 Version noch recht "gutmütig", da hilft ggf ein cronjob über die 30 Tage ;-) was der da zu suchen hat bleibt dem geneigten "Entdecker" überlassen...
Peter S. schrieb: > Grund: Der vom Provider "verordnete" Umstieg von Ver. 7.4 auf 8.0. Strato ? HostEurope ? :( Bei Hetzner kannst Du die PHP-Version einstellen, ggf. bis 5.6 runter. :)
Hab erst von 7.4 auf 8 gemacht ... schaust halt mal in die Error-Logs, da steht was nicht mehr passt.
Danke für Eure Antworten. @Jonny B. Diese Zusammenstellung hatte ich mir im Vorfeld schon angeschaut - bei den gefühlt 1000 Änderungen da die richtige rauszufinden ist eben "Try&Error". @bluppdidupp JetBrains ist vielleicht für einen Profi-Programmierer "preiswert" und dann müßte man auch erst mal die PHP8.0-Unterstützung erkunden. @php Ja, ersterer. Auch da läst sich im Prinzip die PHP-Version einstellen, nur daß die für <8.0 zusätzliche Kosten (???) für die Administration geltend machen. @ Weingut P. So habe ich das bisher gemacht, nur daß die Aktualisierung der Error-Log nicht zeitnah zur Verfügung steht, oft erst am nächsten Tag. Das meinte ich mit Try&Error! - Es ist sehr mühsam ... Aus Dänemark habe ich noch keine Mitteilung. Hat denn noch niemand die recht umfangreiche, mehrsprachige IDE "PHP-Designer" getestet? Grüsse aus Berlin PSblnkd
Was genau versteht Du denn unter einer 8.0 Unterstützung? Für eine so kleine Seite: - XAMPP in einer VM installieren - Notepad++ für den Quellcode Was fehlt dir denn dabei? Bei dem bisschen wirst Du ja kaum hunderte Funktionen (usw.) überblicken müssen die in xxx verschiedenen Dateien verstreit sind.
Mit "php -S" kann man übrigens einen kleinen webserver starten, ist noch praktisch um schnell was zu testen, ohne einen ganzen nginx apache docker einzurichten. Und zum Schnittstellen auszuprobieren habe ich neulich noch dieses Skript geschrieben: https://github.com/Daniel-Abrecht/ActivityPubPHP/blob/dfe0dc52f2dfabd2034eb39422ab61b5a501059a/script/phps Das ruft "php -S" auf, lässt es einen zufälligen Port wählen, dann ein benutzerdefiniertes Kommando, und nachdem das gelaufen ist, killt es den PHP prozess wieder. Besonders schön ist es nicht, aber funktioniert. Da kann man dann so Sachen machen wie z.B.:
1 | phps myfile.php curl '{}/foo?abc=123'
|
2 | phps myfile.php wget -O - '{}/foo?abc=123'
|
Viel wichtiger als irgendeine IDE ist mir: https://www.php.net/manual/de/ Dann reicht mir auch für größere Projekte ein Text-Editor. Setzt aber auch voraus, dass man den Code gut in Klassen strukturiert hat. Und wie andere schon geschrieben haben an das error.log rankommt. Da steht dann oft genau drin wo es hängt. Meist ist es dass PHP 8 kritischer mit uninitialisierten Variablen ist. https://www.php.net/manual/de/migration80.php Da sind in den Unterseiten auch ein paar inkompatible Konstruktionen. Und Achtung: es kann sich das Verhalten syntaktisch unveränderter Konstrukte geändert haben, was man natürlich ebenfalls im Verhalten einer Webseite sieht: https://www.php.net/manual/de/migration80.incompatible.php
So langsam nervt mich das bei PHP auch, daß es da mit rasant steigendem Tempo immer neue Versionen gibt, die mit den "alten" nicht mehr kompatibel sind. Kommt mir so vor als ob viele Köche den Brei verderben oder Angst um ihre Jobs haben, so daß sie sich immer neue Arbeit beim Migrieren ihrer Scripte machen. Meine Erfahrung war bisher, daß die meisten alten Scripte auch auf neueren Versionen laufen, abgesehen von "aus Sicherheitsgründen" eingestellten Extensions wie MySQL->MySQLi. Aber wenn man sich das so einfach macht und das alte Script einfach auf der neuen Version betreibt und anschließend auftretende Fehler behebt, kann das bei umfangreichen Projekten schnell der Anfang einer unendlichen Geschichte sein. Man findet niemals selbst alle möglichen inkompatiblen Stellen und es ist immer ärgerlich wenn seine User, der Kunde oder später dessen User sie finden. Allerdings sind meine eigenen Scripte auch eher defensiv geschrieben bzw. ich bin das z.B. gewöhnt, ohne strenge Variablendeklaration zu arbeiten bzw. forme mir Variablen vor Vergleichen selbst in den korrekten Typ um, so daß mich viele dieser Inkompatibilitäten überhaupt nicht betreffen. Oft gleich schon bei der Dekontamination von User-Eingaben oder so, damit mir die DAUs nicht den Spaß versauen können. Vielleicht ist das bei anderen Leuten auch so.
Ich benutze xampp mit Netbeans.. Netbeans hat auch einen Navigator, wenn man einen Funktionsaufruf im Code anklickt, kann man zur Deklaration springen oder nach aufrufen suchen. Für schnelle Sachen benutze ich auch Notepad++. Netbeans kann man auch Debugging beibringen. Ich glaube das einzige das bei mir von PHP nicht in den Loggs gemeldet wurde war die änderung an session_start. Nur als Idee, man könnte auf das letzte php7 umstellen und die deprecated warnings mit höchstem loglevel nachschauen.
Die Klischees über PHP-Frickler Bewahrheiten sich hier mal wieder. PHP-Pfuscher schlägt auf, hat keinen Plan, dann 199 sinnfreie Antworten, 1-2 sinnvolle Antworten die auf das Problem eingehen aber komplett vom PHP-Pfuscher ignoriert werden. Jetzt fummelt er mit einer IDE herum und 1 Woche später kommen dann Fragen wie man die IDE bedient.
Lebensberatung schrieb: > Die Klischees über PHP-Frickler Bewahrheiten sich hier mal wieder. > PHP-Pfuscher schlägt auf, hat keinen Plan, dann 199 sinnfreie Antworten, > 1-2 sinnvolle Antworten die auf das Problem eingehen aber komplett vom > PHP-Pfuscher ignoriert werden. Jetzt fummelt er mit einer IDE herum und > 1 Woche später kommen dann Fragen wie man die IDE bedient. Naja, ehrlicherweise muß man allerdings auch sagen: es liegt nicht nur an den Nutzern der Sprache, sondern auch an den Entwicklern derselben. Zuerst war PHP nur ein überschaubarer Satz an Skripten zum Aufpeppen von Rasmus' Lerdorfs persönliche Homepage ("Personal Home Page", kurz: PHP) und dann wurde im Laufe der Zeit immer mehr draus, leider nicht immer vorausschauend geplant und entwickelt. Und dabei sind Entscheidungen getroffen worden... die Stringverarbeitung zumindest teilweise von C zu kopieren und später die Objektorientierung von Java, lange Zeit keine Namensräume zu unterstützen und ähnliche, in der Community und unter den Entwicklern zum Teil lange diskutierte Designentscheidungen haben im Laufe der Zeit immer mal wieder Inkonsistenzen und Inkompatibilitäten provoziert. Daß PHP schon von der Anlage her das Designproblem hat, daß es im Kern eine Templateengine ist, bei der der Code in HTML eingebettet und dadurch Logik und Darstellung miteinander vermischt werden, weswegen Profis üblicherweise eine weitere Templateengine wie Smarty benutzen, war sicher auch nicht immer zuträglich und hat leider auch Entwickler angezogen, die mit Softwaredesign nicht so vertraut waren. Vor allem waren aber aus meiner Sicht die lange fehlenden Namensräume problematisch, die dazu geführt haben, daß alle Funktionen im globalen Namensraum gelandet sind und das mitunter zu Namenskollisionen geführt hat. Und dann kamen da noch die immer mal wieder auftretenden Sicherheits- und mitunter Logikprobleme durch die mangelnde Typsicherheit hinzu... ich finde, da kann man nicht nur den Usern einen Vorwurf machen und sie einfach als "PHP-Frickler" abtun, da hat wohl die Entwicklung der Sprache selbst auch ihr Scherflein beigetragen. Andererseits muß man aber auch sehen, daß PHP es für Einsteiger immer besonders leicht gemacht hat: auf einen Webserver mit PHP konnte man einfach eine Datei mit PHP-Code und passender Dateinamenserweiterung hochladen, schon liefs. Das war für Menschen, die keine Erfahrung mit UNIXen, -Permissions und CGI-Verzeichnissen hatten, schon ein ziemlich starkes Argument für PHP.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.