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
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.
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.
:)
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.:
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.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten