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.
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 …)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.
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 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.
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 …)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 …)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.
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:
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.
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.
Bisher stand eproi für maßgeschneiderte WordPress-Plugins und technisch raffinierte Programmierungen. Mit Aeventus präsentieren wir erstmals ein eigenständiges Softwareprodukt – browserbasiert, geräteunabhängig und bereit für den öffentlichen Auftritt.
(mehr …)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…