:: handcode ::

s9y embedded in bestehende Seite eingebaut, Teil 2

Als ich s9y embedded in den bestehenden handcode.de Seiten eingebaut hatte, ging es erst mal drum, den s9y output in die (PHP-)Templates des bestehenden Frameworks einzubinden. Die Konfig-Option "embedded" allein hatte nicht gereicht, daher hatte ich das damals mit einem simplen output-buffer gemacht um den sy9 output in einer PHP-Variabeln "abzugreifen" zu können.

Hat ja auch erst mal funktioniert, nur war der XHTML-Code der Gesamt-Seiten nicht mehr valide, da die <link> Tags zum Einbinden der sy9-CSS Datei und der alternativen Ausgaben (RSS/Atom) nicht im <head> Tag, sondern "irgendwo" in den Seiten eingefügt wurden.

Der Hinweis von Garvin auf die (noch experimentelle) Template-API, bzw. das "default-php" Theme war zwar ein guter Tip, aber keine schnelle Lösung, denn da muss noch weiter dran gearbeitet werden, wozu ich (bis heute) leider(!) keine Zeit hatte.

Naja, wie so oft, haben Provisorien eine lange Lebensdauer, "es läuft ja erst mal..."

Heute bin ich dann bei einer anderen Aufgabe mal wieder "querlesend" durch die Smarty-Doku und dort über die Funktion {capture} (Ausgabe abfangen) gestolpert: Hey, das könnte doch die "schnelle Lösung" sein!

Gesagt getan, und siehe da, kaum macht man's richtig, schon klappt's ;-)

Ich weise jetzt einfach innerhalb des Smarty-Templates index.tpl bestimmte Blöcke eigenen Smarty-Variablen zu und greife in dem darüber liegenden Framework auf diese zu, um sie an den (endlich!) richtigen Stellen im PHP-Template einfügen zu können.

Ausschnitte aus dem Smarty-Template index.tpl meines Themes:

CODE:

{capture assign=handcode_sy9_header}
<link rel="stylesheet" type="text/css" href="{$head_link_stylesheet}" />
[...] und alle weiteren Ausgaben die in den Seitenheader sollen [...]
{/capture}
{capture assign=handcode_sy9_content}
[...] der Inhalt der sy9 Seiten [...]
{/capture}

Und der Zugriff auf die Blöcke im "drüberliegenden" PHP:

PHP:



<?php



// Get Content and Header from serendipity['smarty'] 

require './sy9.php'; 

$sy9_content = $serendipity['smarty']->get_template_vars('handcode_sy9_content'); 

$sy9_header = $serendipity['smarty']->get_template_vars('handcode_sy9_header'); 



?>

Autor: Jens Giessmann in PHP am Montag, 30. April 2007 um 23:18
Kommentare (0) | Trackbacks (0)

Tags für diesen Artikel: blog, php, programming

Spam-Blocker im Apache mit SetEnvIfNoCase (Fake:WordPress/2.1-alpha3)

Zur Zeit werde ich hier mal wieder mit nervigen Fake-Trackbacks zugeballert.
Klar, die kann man moderieren, und dann löschen, nervt trotzdem.

Was tun?

Blocken anhand der IPs ist meist nicht möglich, die wechselt in der Regel ständig.

Wenn man die Fakes/den Spam aber zum Beispiel anhand des selben (Fake) User-Agent festmachen kann, ist es recht einfach möglich diese im Apache zu blocken. Natürlich nur, wenn man Zugriff auf die Apache-Conf hat oder zumindest .htaccess Dateien anlegen darf. Wenn nicht -> Provider wechseln ;-)

Hier ein aktuelles Beispiel:
Fake-Trackbacks mit dem immer gleichen User-Agent "-- WordPress/2.1-alpha3". Prima, damit werden nicht wirklich viele "liebe User" unterwegs sein.

Eine entspr. Regel in der Apache-Conf sieht dann wie folgt aus:

CODE:

SetEnvIfNoCase User-Agent "-- WordPress/2\.1-alpha3" spammer=1

Order allow,deny
Deny from env=spammer
Allow from all

Mit der direktive SetEnvIfNoCase wird der User-Agent mit der RegEx verglichen und im Erfolgsfall die ENV-Variable spammer auf 1 gesetzt.

Dann bekommen alle Anfragen die als "spammer" geflagged sind, nur noch ein HTTP 403 Status Code (Forbidden).

Man kann solch ein Regelwerk beliebig erweitern und neue Merkmale hinzufügen.

Klar kann es sein, das man mit solchen Filter-Regeln auch False-Positives erzeugt, eine Prüfung auf User-Agent Mozilla wäre sicher keine gute Idee ;-)

Da man solche Regeln in <Directory>, <Location> und <Files> Blöcken definieren kann, muss man ja auch nicht immer die kompletten Seiten sperren. Das Blog-Verzeichnis oder die URL zum Trackback-Eintrag reicht ja.

Falls sich wer hier auf handcode.de zu Unrecht "ausgeschlossen" fühlt, soll sich bitte direkt bei mir melden.

Autor: Jens Giessmann in Apache am Freitag, 27. April 2007 um 08:30
Kommentare (0) | Trackbacks (0)

Tags für diesen Artikel: apache, blog, security

XSLT::registerPHPFunctions und "NICHT-PHP" XSLT-Prozessoren

PHP5 ermöglicht es mittels XSLTProcessor::registerPHPFunctions innerhalb von XSL-Stylesheets PHP Funktionen zu verwenden. Soweit, so gut...

Dagegen spricht:: Die Verwendung von PHP-Funktionen in XSL-Stylesheets ist böse; Mit der Verwendung von PHP-Funktionen in XSL-Stylesheets sind diese nicht mehr portabel; ...beliebige weitere (gute!) Gründe die gegen die Verwendung von PHP-Funktionen in XSL-Stylesheets sprechen
Dafür spricht:: Die Verwendung von PHP-Funktionen in XSL-Stylesheets ist praktisch ;-)

Mit einem kleinen Trick ist es aber möglich XSL-Stylesheets zu schreiben, die auch mit "Nicht-PHP-XSLT-Prozessoren" wie z.B. xsltproc verarbeitet werden können, aber beim Einsatz von PHP:XSL dennoch die Möglichkeiten der PHP-Funktionen zu nutzen.

"XSLT::registerPHPFunctions und "NICHT-PHP" XSLT-Prozessoren" vollständig lesen

Autor: Jens Giessmann in PHP, XML am Mittwoch, 11. April 2007 um 18:24
Kommentare (0) | Trackbacks (0)

Tags für diesen Artikel: php, programming, xml, xslt

(Seite 1 von 1, insgesamt 3 Einträge)