DEZEMBER 13TH, 2011
By ROBERT BERNHARD
Irgendwann stand oder steht wohl jeder PHP-Entwickler einmal vor dem Problem der Auswahl eines geeigneten PHP Frameworks. Bis vor einigen Monaten habe ich mich primär mit selbst erstellten Frameworks herum geschlagen. Nicht das die Frameworks schlecht waren, jedoch verspürte ich mehr und mehr den Drang, bekannte PHP-Frameworks kennen zu lernen. Dies ist nicht zuletzt dem Umstand geschuldet, dass am Markt befindliche Ressourcen nicht kompatibel zu selbst erstellten Frameworks sind (der Aufwand und somit die Kosten sind zu hoch).
So fiel meine Wahl zunächst auf ZEND Framework – das Flaggschiff unter den PHP Frameworks. ZEND ist ein sehr mächtiges aber leider auch ein unterirdisch performantes Framework. Die eigenartige auf Grund von PHP Abwärtskompatibilität angewendete Namespace-Implementierung mit Unterstrichen sowie die Komplexität des ZEND-Monsters haben mich jedoch zunehmend abgeschreckt. Mit ZEND gehen viele Dinge, wirklich sehr viele, aber in der Regel brauche ich diese Dinge nicht. Insofern bestand tief in mir der Wunsch nach einem schlankeren, Ressourcen schonendem und gut dokumentierten Framework Ausschau zu halten. Das Framework sollte zudem einfach konfigurierbar und modular verwendbar sein. Die Möglichkeit Extensions zur Erweiterung des Frameworks einzubinden, setze ich als gegeben voraus.
Read more »
JULI 15TH, 2010
By ROBERT BERNHARD
Nicht selten ist es beim Aktualisieren von Datensätzen notwendig, die Bedingung für in Frage kommende Datensätze bei der Update-Anweisung einzufügen. Wer keine Kenntnis darüber besitzt, wird eine zweite Abfrage vorschalten und das Ergebnis in der eigentlichen Update-Anweisung verwerten.
Dabei ist das Updaten von Datensätzen mittels bei MySQL sehr trivial. Folgende Abfrage aktualisiert alle Datensätze von tabelle1 (aktiv wird auf 1 gesetzt) welche in tabelle2 existieren.
UPDATE tabelle1 AS a
JOIN tabelle2 AS b
ON a.id = b.id
SET a.aktiv=1
Folgende Abfrage setzt das Flag “aktiv” in beiden Tabellen bei Datensätzen, die in beiden Tabellen vorkommen.
UPDATE tabelle1 AS a
JOIN tabelle2 AS b
ON a.id = b.id
SET a.aktiv=1,
b.aktiv=1
Die Verknüpfung der Tabellen ist beliebig erweiterbar. Selbst Subselects oder Derived Tables sind kein Problem.
JULI 15TH, 2010
By ROBERT BERNHARD
Unter Umständen ist bei dem Löschen von Datensätzen ein JOIN notwendig. Das Löschen von Datensätzen unter Verwendung eines JOINS unter MySQL ist dabei relativ einfach.
Folgende Operation löscht den Datensatz auf lediglich aus Tabelle 1. Gelöscht werden Datensätze von tabelle1 bei welchen die Bedingungen tabelle1.id = tabelle2.id erfüllt.
DELETE del
FROM tabelle1 AS del
JOIN tabelle2 AS sel
ON del.id = sel.id
Folgende Abfrage löscht Einträge aus beiden Tabellen. Gelöscht werden Datensätze von tabelle1 und tabelle2 bei welchen die Bedingungen tabelle1.id = tabelle2.id erfüllt.
DELETE del,
sel
FROM tabelle1 AS del
JOIN tabelle2 AS sel
ON del.id = sel.id
Die Verknüpfung der Tabellen mittels JOIN ist beliebig (auch mit LEFT JOIN) erweiterbar.
JULI 7TH, 2009
By ROBERT BERNHARD
Sicherlich standet ihr auch schon einmal vor dem Problem, die Ergebnismenge einer SQL Abfrage einschränken zu müssen. Soweit ist alles unkritisch. Wird nun beispielsweise für eine Seitenauswahl (pagination 1, 2, 3, … etc.) die Gesamtanzahl der Datensätze benötigt, ist eine weitere Abfrage erforderlich, welche ohne Limit die Ergebnisse zählt (COUNT).
SELECT COUNT(*) FROM tabelle WHERE feld = 'suchwort'
Bei einfachen Abfragen ist diese Art des “countens” von Datensätzen kein Problem. Sind die Abfragen jedoch komplexer, so ist zum Zählen von Datensätzen die SQL Abfrage doch sehr oft um zu formulieren.
Die Lösung des Problems bietet MySQL selbst mit dem Befehl SQL_CALC_FOUND_ROWS.
SELECT SQL_CALC_FOUND_ROWS
spalte1,
spalte2
FROM tabelle
WHERE feld = 'suchwort'
LIMIT 0, 10
wird einfach vor die zu selektierenden Spalten gesetzt (Achtung ohne Komma) und wirkt sich abgesehen von der minimal schlechteren Performance zunächst nicht aus. Das Resultset besteht aus maximal 10 Datensätzen und kann wie gehabt gefetcht werden. Durch eine weitere SQL Abfrage mit dem Befehl
FOUND_ROWS wird anschließend die Anzahl aller gefundenen Datensätze ohne die Limitierung abgefragt.
Diese Abfrage gibt genau einen Record (Datensatz) mit einem Tupel zurück und enthält die Anzahl gefundener Datensätze ohne Limitierung. Neben des Vorteils, dass die Abfrage nicht für das Zählen der Einträge umgeschrieben werden muss, ergibt sich oftmals jedoch ein minimaler Performancenachteil. Hier gilt es zwischen Komfort und Performance abzuwägen.
Mehr Informationen über SQL_CALC_FOUND_ROWS und FOUND_ROWS findet ihr in der offiziellen MySQL-Dokumentation.
Ein PHP Beispiel findet ihr im kompletten Beitrag. Read more »
FEBRUAR 19TH, 2009
By ROBERT BERNHARD
Dass neugierige Dritte eigene Projekte analysieren (Konkurrenzanalyse) ist ja nicht neu. Immer häufiger treffe ich in letzter Zeit beim Stöbern durch meine Logs auf manipulierte Header. Grundsätzlich spricht ja nichts dagegen, sich bei anderen etwas abzugucken. Wenn jedoch der User Agent absichtlich in der Form manipuliert wird, dass sich der Analysator als Googlebot ausgibt, hört mein Verständnis auf.
Wie ein Fake Google Bot mittels .htaccess ausgesperrt wird, möchte ich euch nun kurz aufzeigen. Zuvor möchte ich jedoch auch davor warnen – es wird niemals eine zu 100 Prozent vollständige Liste aller Google IP Adressen geben. Nahezu täglich erweitert Google die eigenen Serverfarmen und somit auch die Anzahl der im Netz befindlichen Crawler (Bots). Jeder neuer Crawler hat eine eigene und unter Umständen euch nicht bekannte IP-Adresse. Die Folge kann sein, dass ihr ungewollter Weise Google aussperrt und das ist nicht Sinn der Sache.
Gut fangen wir an – zunächst benötigen wir eine Liste der Googlebot IP Adressen. Derartige Listen lassen sich bei Google finden. Falls nicht bereits vorhanden, legen wir nun im Root-Verzeichnis der zu schützenden Webseite eine .htaccess Datei mit folgendem Inhalt an (falls bereits angelegt, überspringen).
RewriteEngine On
Nun sind mittels der angelegten .htaccess Datei noch die IP Adressen des die Webseite aufrufenden Benutzers gegen seinen User Agent zu prüfen. Kommt im User Agent “googlebot” vor und die IP Adresse ist in unserer Liste nicht vorhanden, wird der Besucher kurzer Hand ausgesperrt (nix nada niente).
RewriteEngine On
# ACHTUNG!!! Die IP Adressen sind nur exemplarisch
# und gehören nicht zu Google
RewriteCond %{HTTP_USER_AGENT} googlebot
RewriteCond %{REMOTE_ADDR} !^1.1.1.1 [OR] # IP Adresse 1
RewriteCond %{REMOTE_ADDR} !^2.2.2.2 [OR] # IP Adresse 2
RewriteCond %{REMOTE_ADDR} !^2.2.3. [OR] # IP Bereich 2.2.3.1 - 2.2.3.255
RewriteRule ^.* - [F]
Das war es dann auch schon. Fake Google Bots sind ab sofort ausgesperrt. Bitte achtet unbedingt auf die Aktualität eurer Ip Adressen Liste! Wer eine halbwegs aktuelle Liste von Google IP Adressen findet, kann sie gerne in einem Kommentar bekannt geben.
JANUAR 29TH, 2009
By ROBERT BERNHARD
Es kommt immer wieder mal vor, dass man vor die Aufgabe gestellt wird, einen in der Datenbank abgelegten Quelltext für die Ausgabe vor zu bereiten. Nicht zuletzt peppen Plugins wie Lightbox oder Slimbox ein eingestaubtes CMS System mächtig auf, in dem Bilder in einer sehr schönen Optik vergrößert angezeigt werden können.
Bevor man sich nun die Arbeit macht, jedes im Quellcode eingebettetes Bild (<img src=”" … >) an das auserwählte Plugin anzupassen, macht ein regulärer Ausdruck hier viel mehr Sinn.
Beim Einsatz von PHP genügt folgender regulärer Ausdruck, um alle Bilder eines Quelltextes für Lightbox beziehungsweise Slimbox anzupassen:
Einfach aber gut stimmts?
JANUAR 10TH, 2009
By ROBERT BERNHARD
Als langjähriger Entwickler schlägt man sich bei einem Blick auf den eigenen Quellcode von früheren Zeiten doch sehr oft die Hände über dem Kopf zusammen “Wer soll das bitte lesen? Wo sind alle die Kommentare abgeblieben? Für was steht gleich die Variable $a2?”. Gerade heute habe ich wieder über fremden Quellcode schauen müssen und dachte mir, dass dies ein guter Anlass für ein solches Posting wäre. Read more »
JANUAR 9TH, 2009
By ROBERT BERNHARD
Eins möchte ich euch schon einmal vorweg nehmen – vergesst META REFRESH und Javscript Aufrufe ala location.href=”bla.html”. Für eine dauerhafte Umleitung sind diese Methoden nicht der richtige Weg. Permanent Redirect bedeutet, dass eine Internetseite für den Browser und Suchmaschinen - vor allem Suchmaschinen sind da richtig geil drauf – eindeutig erkennbar dauerhaft auf eine andere Internetseite umgeleitet wird. Als Erkennungsmerkmal wird beim Aufruf einer permanent umzuleitenden Seite anstatt des normalen Header
HTTP/1.x 200 OK
der Header
HTTP/1.x 301 Moved Permanently
gesendet wird. Und genau diese Modifikation des Header können META REFRESH und Javascript location.href=”bla.html” nicht. Soweit so gut…
Oftmals spricht man der Kürze wegen auch von einem 301 Redirect … mehr über Header kann man bei Wikipedia nachlesen. Das dauerhafte Umleiten von Links kann aus verschiedensten Beweggründen wichtig sein. Einer der Gründe ist das Vermeiden von Duplicate Content, ein anderer könnte eine veränderte Internetadresse sein, …. es gibt sicherlich 1000 Weitere Gründe.
Wie man nun einen Permanent Redirect realisiert und was es dabei zu beachten gibt, habe ich nachfolgend kurz zusammen gefasst. Read more »
