Forum: PC-Programmierung PHP-Programmierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peter S. (psblnkd)


Lesenswert?

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

von Justin S. (Gast)


Lesenswert?

Keine Tipps aber fast das gleiche ungelöste Problem, daher Solidarität 
und Hoffnung auf nützliche Antworten.

von Daniel A. (daniel-a)


Lesenswert?

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.

von Johnny B. (johnnyb)


Lesenswert?

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

von bluppdidupp (Gast)


Lesenswert?

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...

von quotendepp (Gast)


Lesenswert?

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...

von php (Gast)


Lesenswert?

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. 
:)

von Weingut P. (weinbauer)


Lesenswert?

Hab erst von 7.4 auf 8 gemacht ... schaust halt mal in die Error-Logs, 
da steht was nicht mehr passt.

von Peter S. (psblnkd)


Lesenswert?

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

von M. P. (matze7779)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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'

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Lesenswert?

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

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Totomitharry (Gast)


Lesenswert?

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.

von Lebensberatung (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.