eproi

present IT for tomorrow
IT-Lösungen – von heute für morgen.

Kategorie: Startseitenfeature

  • PHP-Dateien ohne PHP — warum das eine stille Performance-Falle ist

    PHP-Dateien ohne PHP — warum das eine stille Performance-Falle ist

    Bei der Analyse einer älteren WordPress-Installation fiel mir kürzlich etwas auf, das auf den ersten Blick harmlos wirkt: Dateien mit der Endung .php — die aber kein einziges Byte PHP enthalten. Stattdessen: XML-Strukturen, SVG-Markup, statische Inhalte. Alles prima, nur eben nicht PHP.

    Klingt nach Kleinigkeit. Ist es nicht.

    (mehr …)

    Bei der Analyse einer älteren WordPress-Installation fiel mir kürzlich etwas auf, das auf den ersten Blick harmlos wirkt: Dateien mit der Endung .php — die aber kein einziges Byte PHP enthalten. Stattdessen: XML-Strukturen, SVG-Markup, statische Inhalte. Alles prima, nur eben nicht PHP.

    Klingt nach Kleinigkeit. Ist es nicht.

    (mehr …)
  • Laravel 12 auf 13 — warum wir migriert haben, obwohl wir nicht mussten

    Laravel 12 auf 13 — warum wir migriert haben, obwohl wir nicht mussten

    Manchmal merkt man beim Arbeiten an einem neuen Projekt was einem an einem älteren fehlt. Genau das ist passiert: Bei neueren Laravel-Projekten haben wir direkt mit Version 13 gestartet und dabei Features entdeckt, die wir rückwirkend auch in unserem eigenen Produkt haben wollten.

    Allen voran: native Suche in verschlüsselten Datenbankspalten. Ein Feature das für datenschutzsensible Anwendungen konkret relevant ist — und das in Laravel 13 sauber im Standard mitkommt, ohne eigene Konstrukte drumherum.

    Dazu kam eine pragmatische Entscheidung: Lieber jetzt migrieren, bevor weitere Features dazukommen. Je mehr ein System wächst, desto mehr gibt es beim nächsten Mal zu testen und anzupassen. Wer das kennt, kennt auch den Moment wo man sich denkt: hätte ich das früher gemacht.

    Das Projekt hatte über die Zeit einige eigene Klassenkonstrukte und Besonderheiten im Front- und Backend angesammelt. Dinge, für die Laravel zwar die Basis gelegt hatte, die wir aber selbständig weiterentwickelt hatten. Entsprechend stand zu Beginn gefühlt eine sehr lange Checkliste im Raum.

    Am Ende zeigte sich: Es ging schneller als erwartet. Der Grund dafür hat weniger mit der Laravel-Version zu tun als mit dem Zustand des Projekts davor.

    (mehr …)

    Manchmal merkt man beim Arbeiten an einem neuen Projekt was einem an einem älteren fehlt. Genau das ist passiert: Bei neueren Laravel-Projekten haben wir direkt mit Version 13 gestartet und dabei Features entdeckt, die wir rückwirkend auch in unserem eigenen Produkt haben wollten.

    Allen voran: native Suche in verschlüsselten Datenbankspalten. Ein Feature das für datenschutzsensible Anwendungen konkret relevant ist — und das in Laravel 13 sauber im Standard mitkommt, ohne eigene Konstrukte drumherum.

    Dazu kam eine pragmatische Entscheidung: Lieber jetzt migrieren, bevor weitere Features dazukommen. Je mehr ein System wächst, desto mehr gibt es beim nächsten Mal zu testen und anzupassen. Wer das kennt, kennt auch den Moment wo man sich denkt: hätte ich das früher gemacht.

    Das Projekt hatte über die Zeit einige eigene Klassenkonstrukte und Besonderheiten im Front- und Backend angesammelt. Dinge, für die Laravel zwar die Basis gelegt hatte, die wir aber selbständig weiterentwickelt hatten. Entsprechend stand zu Beginn gefühlt eine sehr lange Checkliste im Raum.

    Am Ende zeigte sich: Es ging schneller als erwartet. Der Grund dafür hat weniger mit der Laravel-Version zu tun als mit dem Zustand des Projekts davor.

    (mehr …)

  • WordPress gehackt: Befallene Installation bereinigen — ein Praxisfall

    Eine WordPress‑Installation, die gestern noch normal lief, ist plötzlich komplett tot – weder Frontend noch Backend reagieren. Nach der ersten Wiederherstellung zeigt sich schnell, dass das Backend zwar wieder erreichbar ist, das Frontend jedoch weiterhin ausfällt. Ein Blick per FTP bringt die eigentliche Ursache ans Licht: Die Seite ist kompromittiert. Die Art der Infektion sorgt für massive Systemlast, selbstreparierende Core‑Dateien und ein Root‑Verzeichnis, das sich nicht mehr bereinigen lässt. Besonders heikel: Das Ganze läuft auf einem klassischen Webspace ohne SSH‑Zugriff, also ohne jede Möglichkeit, tiefer in das System einzugreifen.

    Parallel dazu berichtet Golem über aufgekaufte WordPress‑Plugins, die gezielt mit Backdoors versehen wurden. Cloudflare wiederum bewirbt sein neues EmDash‑System als robustere Alternative. Doch was bedeutet das alles in der Praxis – und was lässt sich aus dieser Melange wirklich lernen?

    (mehr …)

  • PHP Warum truthy Prüfungen nicht immer wahr sind

    In PHP – wie natürlich auch in anderen Programmiersprachen – gibt es verkürzte truthy-Prüfungen. Ob, wie und wann man sie einsetzt muss aber genau überlegt sein. Das hilft am Ende nicht nur der Lesbarkeit sondern vermeidet auch Bugs, die auf Grund falsch gedachter oder vermeintlich logischer Prüfungen aufkommen.

    (mehr …)

  • HTTP 500: Fehler – nur welcher?

    Neulich haben wir schon über den Unterschied zwischen 401 und 403 gesprochen. Jetzt wollen wir weiterschauen: der HTTP Code 500 ist ein weiterer häufiger Kandidat – und verhält sich „mysteriös“. Teilweise ist das aber auch gut so.

    (mehr …)

  • PHP – catch me if you can!

    In PHP werden natürlich auch Fehler behandelt. Wenn man kritische Fehler nicht abfängt, wandern sie weiter nach oben bis das Script irgendwann eben abbricht. Fast jeder Entwickler dürfte schon einmal eine fatal error message erhalten haben. Oder falls der Server nicht ganz so auskunftsfreudig ist – was natürlich auf Grund der Sicherheit einer Seite begrüßenswert ist – dann eben einfach nur einen 500 internal Server error.

    Beides trägt jetzt in der Regel in Produktivsystemen nicht gerade zur Begeisterung bei. Deswegen könnte der ein oder andere auch schon mal auf die Idee kommen um seinen Code einen try…catch Block zu bauen. Das bietet sich gerad bei potentiell sehr fehleranfälligen Programmpassagen an, hat aber manchmal noch zur Folge, dass der Fehler trotzdem auftritt. Das liegt daran das meistens dann eine solche Struktur genutzt wird:

    try
{
   echo 50/0;
}
catch (Exception $e)
{
   echo "Division durch null ist nicht erlaubt!";
}

    Das Problem dabei: Nicht alles was auftauchen kann ist auch Exception. Eigentlich ist eine Exception eher sowas wie ein Spezialfall für einen Fehler der auftauchen kann. Deswegen sollte man in einem solchen Fall das ganze besser so aufbauen:

    try
{
echo 50/0;

}
catch (Throwable $e)
{
   echo "Division durch null ist nicht erlaubt!";
}

    Denn alles was auftreten könnte ist auf jeden Fall ein Throwable. Hier wird es jetzt korrekt abgefangen und das Programm steigt nicht mehr aus. Natürlich lässt sich das noch verfeinern und erhebt keinen Anspruch auf Vollständigkeit, kann aber in manchen Situationen die Rettung sein…