Diese Webseite befindet sich immer noch in der Entwicklung. Neben Änderungen im Layout, kommen auch gelegentlich neue Funktionen hinzu bzw. werden fehlerhafte oder nicht erwünschte Funktionen entfernt.
Aktueller Stand
Diese Webseite befindet sich immer noch in der Entwicklung. Neben Änderungen im Layout, kommen auch gelegentlich neue Funktionen hinzu bzw. werden fehlerhafte oder nicht erwünschte Funktionen entfernt.
Aktueller Stand
Nachdem ich mich bei meinem Hoster beschwert hatte, daß mein Feed nicht mehr auf planet.schokokeks.org aggregiert wird, bekam ich dann den Hinweis das mein Feed fehlerhaft war. Peinlich, Peinlich. Verantwortlich für den Fehler waren ein paar Zeilen PHP-Code die sich auf zunächst mysteriöse Weise in den Feed (ATOM und RSS) vor dem eigentlichen XML-Abschnitt eingeschlichen hatten.
Beim Debuggen ist mir dann aufgefallen, daß das Template für den Fehler verantwortlich ist. Sobald ich ein anderes Template ausgewählt hatte, funktionierte der Feed wieder einwandfrei. Da ich aber zwingend mein neues Template behalten wollte, musste also eine Lösung her. Mit Jans Hilfe konnte ich das Problem recht schnell ich der Datei config.inc.php lokalisieren und beheben. Dazu muss eigentlich nur der Code zu Beginn der Datei gesucht werden:
if ($serendipity['GET']['adminModule'] == 'templates' || $serendipity['POST']['adminModule'] != 'templates') {Und anschließend wie folgt korrigiert werden:
if ($serendipity['GET']['adminModule'] == 'templates' || $serendipity['POST']['adminModule'] == 'templates') { Nach der Korrektur läuft jetzt alles einwandfrei!
technorati tags: serendipity, s9y, template, theme, freshy, feed, rss, atom
Ich möchte jetzt mal ein paar Fragen in den Raum stellen, die mich heute beschäftigt haben. Anlaß war das Erstellen eines Fragenkatalogs um u.a. Qualitätsmerkmale einer (grafischen) Benutzeroberfläche abzufragen.
Für Tips und Hinweise wäre ich sehr dankbar.
Werden solche Richtlinien soweit sie existieren auch beim Webdesign oder der Entwicklung umgesetzt und anschließend auch geprüft?
Nach vielen Versuchen .Net 3.0 auf den Clients in der Firma zu installieren, hatte ich heute endlich mal eine produktive Fehlermeldung. Ein richtiger Fortschritt!
Demnach war die Datei machine.config fehlerhaft und das Installationsprogramm wolle die Datei nicht lesen. Bemängelt wurde der Zeichensatz, welchen ich dann flugs mal in UTF-8 geändert habe.
Nach der Änderung gings mit der Installation wieder von vorne los und dieses mal meldete das Installationsprogramm einen XML-Fehler mit dem doppelten Bezeichner </runtime> in der Zeile 103. An der Stelle ist er jedoch vollkommen richtig, allerdings taucht er ohne öffnenden Bezeichner <runtime> nochmals früher in der Datei auf. Nach dem Löschen des überflüssigen Bezeichners, lief der nächste Installationdurchgang problemlos durch.
Und damit läuft endlich auch der Windows LiveWriter mit dem ich gleich mal diesen Artikel schreibe.
technorati tags: .net 3, windows, live, writer, live writer, xml, utf-8
Bei aktiviertem mod_rewrite ist es nicht möglich beliebige Dateien innerhalb der S9Y-Installation zu öffnen, da man aufgrund der rewriterule's in der .htaccess immer umgeleitet wird. Damit wird auch verhindert, das man eigene (statische) HTML-Seiten innerhalb des Blogs darstellen kann. Die einfache Lösung besteht darin, in jedem betreffenden Unterverzeichnis der S9Y-Installation eine .htaccess-Datei zu erstellen und darin die Rewrite-Engine mittels rewriteengine off auszuschalten.
[ via: S9Y-Forum ]
technorati tags: serendipity, s9y, mod_rewrite, rewriterule, rewriteengine, htaccess
Ich habe aus gegebenem Anlass mal ein paar Fakten zu der leidigen PHP-Sicherheitsfunktion SAFE_MODE zusammengetragen. Da ich selber weder Webdesigner, noch Programmierer oder (Web-)Server-Admin bin, muss ich mich hier auf die Qualität meiner Quellen verlassen. Notwendigerweise habe ich dafür mehrere Foren (Serendipity, Gallery, living-e, etc) durchstöbert und gegengelesen. So konnte ich die wichtigsten Argumente zusammengefassen und aufbereiten.
| PRO | CONTRA |
| SAFE_MODE verhindert, das Skripte über PHP-Funktionen auf die Daten anderer Nutzer zugreifen können indem es ausschließlich Zugriff auf Dateien und Verzeichniss des ausführenden Nutzers (z.B. Apache) gewährt. | SAFE_MODE gibt es nur für PHP. Skripte anderer Sprachen bedürfen anderer Sicherheitsmechanismen. Somit kann mit eigeschaltetem SAFE_MODE nur ein Server, der PHP als einzige Sprache anbietet, völlig abgeschottet werden. |
| SAFE_MODE ist einfach. Daher wird es oft als erste Maßnahme zum Schutz vor Problemen im Umgang mit PHP genommen. | SAFE_MODE ersetzt nicht die korrekte Konfiguration der Zugriffsrechte. Auf einem korrekt konfiguriertem Server mit PHP-FastCGI + SuExec + Apache 2 + Chroot Jails ist SAFE_MODE nicht mehr notwendig. Hier gibt es eine Anleitung zur sicheren Einrichtung eines Servers ohne SAFE_MODE. |
| SAFE_MODE wird es in PHP 6 nicht mehr geben. Daher müssen für PHP andere Sicherheitsmechanismen und -strukturen, die es teilweise bereits gibt, eingeführt werden, wie z.B. OPEN_BASEDIR. Konfiguration von OPEN_BASEDIR für Gallery2. |
Wie man zumindest wieder Herr seiner eigenen Dateien auf schokokeks.org wird, steht im WIKI.
technorati tags: php, safe_mode, fastcgi, suexec, chroot jail, open_basedir, serendipity, s9y