eproi

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

Kategorie: eproi pur

eproi pur – das ist „unsere“ Kategorie in der wir ganz speziell beleuchten was uns in/um/mit eproi bewegt. Dabei sowohl technisches aus unseren Projekten aber mitunter auch tagesaktuelle IT-Themen.

  • 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 …)
  • Primärschlüssel: Warum Auto-Increment IDs UUIDs in den meisten Projekten schlagen

    Primärschlüssel: Warum Auto-Increment IDs UUIDs in den meisten Projekten schlagen

    Die harmlos wirkende Anforderung

    Es fing mit einer simplen Aufgabe an: Eine AJAX-Abfrage sollte idempotent werden. Konkret bedeutete das — egal wie oft der Request gefeuert wird, das Ergebnis bleibt stabil und vorhersehbar. Kein Flackern, keine Race Conditions, keine doppelten Einträge die sich gegenseitig überholen.

    Die klassische Lösung: ORDER BY id. Fertig. Nächstes Problem.

    Nur dass es diesmal kein nächstes Problem gab. Zumindest nicht sofort.

    (mehr …)

  • Neuer Service: Ein Pageconverter

    Nach unserer Event‑Ressourcenplattform Ende letzten Jahres folgt nun das nächste Produkt aus dem eproi‑Ökosystem: PageConvertPage.
    Mit diesem Tool lassen sich Webseiteninhalte direkt in den gewünschten Pagebuilder übersetzen – schnell, zuverlässig und mit weitaus geringerer manueller Nacharbeit als bisher.

    (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 …)

  • WordPress Plugins: Warum schlechte Auswahl deine Installation ruiniert

    WordPress (und auch andere CMS) sind verlockend: Schnell installiert, schnell mit Plugins erweitert und schnell online im Netz. Es ist aber leider etwas mehr als ein Pippi Langstrumpf Abenteuer bei dem 3×3 = 6 ergibt…

    (mehr …)

  • WordPress Performance: Warum zu viele Plugins deine Seite ausbremsen

    WordPress erfreut sich seit Jahren großer Beliebtheit – trotz oder vielleicht gerade wegen seines Alters. Heute wird damit fast alles gebaut: vom persönlichen Blog über Vereinsseiten bis hin zu ausgewachsenen Shopsystemen. Ursprünglich war WordPress aber eine reine Blogsoftware. Viele WordPress‑Seiten werden langsam, weil zu viele Plugins geladen werden – oft ohne dass Betreiber es merken. Oft entstehen Performance‑Probleme dabei nicht durch ein einzelnes Plugin, sondern durch Plugin‑Konflikte – besonders wenn mehrere Erweiterungen dieselben Hooks nutzen.

    Aber viele kennen es: Etliches ist eben nur mit zusätzlichen Plugins möglich.
    Und genau da beginnt das Problem: Nur weil man kann, heißt das nicht, dass man sollte.

    (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 …)

  • PHPUnit-Tests: Wenn ein roter Test ein Erfolg ist

    Vor einiger Zeit berichteten wir schon mal darüber, dass wir angefangen haben, PHPUnit-Tests zu verwenden. Inzwischen ist das fast schon ein Standard bei uns geworden – Zeit nochmal einen Einblick in etwas Spannendes zu geben…

    Am Anfang steht natürlich immer die Frage: Was teste ich und wie?

    Ein Test existiert schließlich nicht nur, damit am Ende alles schön grün aussieht. Vielmehr geht es darum, Schwachstellen, Edge‑Cases und unerwartete Situationen vor der Produktivsetzung abzufangen.

    Die Erwartungshaltung ist klar


    Ich schreibe einen Test, lasse ihn laufen und arbeite mich durch die Fehler, bis alles grün ist. Wenn ich gut bin, geht das schnell. Wenn ich schlecht bin oder Folgefehler auftreten, dauert es eben länger.

    Und natürlich bringt mir ein Testpaket nur etwas, wenn ich mich nicht selbst belüge. Also: keine „nur einfachen Tests“, sondern Dinge, die realistisch auftreten können. Ein paar Beispiele:

    • Nachname bleibt in einem Anmeldeformular unbelegt
    • Telefonnummern in verschiedenen Schreibweisen -> wichtig! Die Frage hier ist kann mein Setup damit umgehen
    • vielleicht eine nicht konforme Emailadresse
    • bei API Routen und Co. durchaus mal Testen mit gültigem Auth, ungültigem Auth und keinem Auth. Kommt bei ungültigem und keinen Auth z.B. ein passender 401 bzw. 403 zurück? (Hier gern auch ein Hinweis auf unseren Artikel zum HTTP 401 vs. 403)

    Gerade letzteres ist vielleicht etwas, auf das man nicht zwingend direkt kommt. Aber gerade solche Dinge sind auch wichtig, weil sie in der Realität ein Einfallstor liefern. Eine API Route die unautorisierte Zugriffe erlaubt und vielleicht sogar noch wilde Daten rausgibt – absolut undenkbar.

    Aber muss man dafür immer gleich eine neue Testreihe schreiben?

    Nicht unbedingt! Wir hatten zu Beginn der Entwicklung hier erst mal die API Route lokal ohne Auth hinterlegt. Das ist unsere modale Vorgehensweise: Schritt für Schritt und immer nach dem Credo Form follows function!

    Was wir dann gemacht haben? Naja nachdem wir soweit waren das alle Tests „grün“ waren haben wir die Auth-Middleware aktiviert. Und dann? Einfach die Tests nochmal ausgeführt.

    Natürlich waren alle Tests rot und das war auch erwartbar. Das war hier aber auch das Ziel – so konnten wir ohne neue Tests direkt sagen: Die Auth funktioniert, die Routen liefern korrekt ihr 401 zurück..

    Also ja, unsere Tests waren rot.
    Aber nein, das ist nicht schlimm.
    Es war erwartbar – und in diesem Moment genau das, was wir wollten.