Archiv der Kategorie: Webentwicklung

Um PHP-Dateien und Datenbankzugriffe auf dem lokalen PC testen zu können, installiert man sich ja bekanntlich eine Entwicklungsumgebung. Man kann alles einzeln installieren, also zum Beispiel den Apache-HTTP-Server, einen MySQL- oder Maria-Datenbankserver und natürlich die Programmiersprache PHP. Der Konfigurationsaufwand ist allerdings beträchtlich, und so greift man doch lieber zu einem fertigen Paket. Solche Pakete nennen sich WAMP (Windows-Apache-MySQL/MariaDB-PHP), LAMP (Linux-etc.) und MAMP (Mac-etc.).

Bisher hatte ich immer Wamp-Server benutzt, das auf zwei PCs gut lief. Doch nachdem ich den zweiten Rechner von Windows® 7 auf 10 umgestellt hatte, wollte der Apache-Teil dieses Wamp-Servers nicht mehr laufen, der Apache-Dienst ließ sich einfach nicht starten. Aber es gibt ja noch etliche andere WAMP-Stacks. Der Uniform Server gefiel mir ganz gut, ebenfalls der EasyPHP Devserver, aber letzten Endes landete ich bei Z-WAMP und blieb begeistert an ihm hängen.

Z-WAMP benötigt keine Installation. Man entpackt eine Zip-Datei und das war’s. Die Konfiguration beschränkte sich in meinem Fall darauf, in der Apache-Konfigurationsdatei anzugeben, welches Verzeichnis als localhost anzusehen ist, und dann noch die Datenbanken aus dem alten Wamp-Server-Ordner in den Z-WAMP-Unterordner vdrive\.sys\mysql\data zu kopieren. Ach ja, die bisherigen Datenbankbenutzer mussten noch neu eingerichtet werden. Übrigens, man sollte alle eventuell noch vorhanden vorherigen WAMP-Installationen deinstallieren, um Konflikte zu vermeiden. Die Datenbanken waren bei der Deinstallation von Wamp-Server sogar erhalten geblieben, aber natürlich sollte man (nicht nur vor solchen Aktionen) immer zuverlässige Backups angefertigt haben (externe Festplatte, FTP-Server, …).

Z-WAMP startet sehr schnell und lief bisher auf beiden Rechnern zuverlässig.

Bei einem Blick auf die Adressleiste des Browsers fällt auf, dass viele Blog- und Content-Management-Systeme die Webseiten an den Webbrowser ohne Dateiendung ausliefern, also ohne .html oder .php.

Nun kann es Fälle geben, wo Teile des Webauftritts, etwa ein Blog oder Newsbereich, über ein CMS laufen, daneben aber auch statische, von Hand erstellte Seiten existieren. Wir wollen nicht über den Sinn oder Unsinn solcher gemischten Umgebungen diskutieren – Gründe kann es verschiedene geben.

In einem anderen Artikel hatte ich schon darüber geschrieben, wie man die Anzeige der Dateiendungen unterdrückt. Das hat bei mir übrigens bei einem Webhoster funktioniert, bei einem anderen nicht.

Heute soll es darum gehen, wie man einen Schrägstrich am Ende des URL erzeugt oder entfernt (um die statischen Seiten in der Adresszeile des Browsers genauso aussehen zu lassen wie die durchs CMS erzeugten Seiten). Und das bewerkstelligt man dadurch, dass man folgenden Code in die Datei .htaccess (im Falle eines Apache-HTTP-Servers) einträgt:

Ohne Trailing-Slash:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]

Mit Trailing-Slash:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

Quelle des Codes: Stack Overflow

Viele Content-Management-Systeme bieten an, die Dateiendung .php aus dem URL, also aus der Webadresse, zu entfernen. Mit einem Mausklick ist das in aller Regel erledigt. Dies kann aus verschiedenen Gründen gewünscht sein. Was aber, wenn man ein Webseite von Hand erstellt hat und ohne CMS arbeitet?

Des Rätsels Lösung ist ein Eintrag in der Datei .htaccess, die auf Apache-HTTP-Servern üblich ist und verschiedenste Anweisungen enthalten kann. Die wenigen Zeilen Code, die man eintragen muss, lauten folgendermaßen:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^([^/]+)/$ $1.php


Quelle:
Diesen Tipp von Dejan Jacimovic habe ich gefunden auf StuntCoders.

Ich programmierte vor kurzem ein PHP-Skript, das die Dateien aus einem bestimmten Verzeichnis auslesen und als Links auf einer Webseite ausgeben sollte, um die Dateien zum Herunterladen anzubieten. In meiner Testumgebung auf dem lokalen Windows®-PC wurden bei einigen Dateinamen komische Zeichen angezeigt. Und zwar bei allen Dateinamen, die Umlaute, Akzente oder Sonderzeichen enthielten. Auf dem Webserver, der unter einem Linux-Betriebssystem läuft, trat dieses Problem nicht auf.

Nach langer Suche fand ich bei ComputerBase den Hinweis, dass es wohl daran liegt, dass Windows Dateinamen nicht in UTF-8 kodiert, sondern in CP-1252 oder ISO-8859-1. Mein Skript war allerdings in UTF-8 gespeichert (wie es ja üblich ist), was zu dem Zeichensalat führen musste.

Um von vornherein Problemen aus dem Weg zu gehen, verwendet man in Dateinamen fürs Web am besten gar keine Umlaute, Akzente, Leerzeichen und Sonderzeichen. Und wenn Dateien automatisch chronologisch sortiert werden sollen, benutzt man natürlich ein immer gleich bleibendes Dateinamensschema, also zum Beispiel katzenfoto-2016-03.pdf, katzenfoto-2016-04.pdf und so weiter, und nicht ein Mischmasch wie etwa KATZENFOTO März 2016.pdf und Katzenfoto 04.2016.pdf oder ähnlich, noch zumal unter UNIX® und Linux Groß- und Kleinschreibung unterschieden wird, anders als unter Windows. »Schön« sind natürlich auch Namen, die keinerlei Hinweis auf den Inhalt der Datei geben, wie etwa P3290153.JPG. Doch genau solche Dateien mit Namen, die durcheinander sind wie Kraut und Rüben, erhalte ich immer wieder von Kunden. Denn sie wissen nicht, was sie tun.

MarkdownPad ist ein Editor für das Windows®-Betriebssystem, mit dem man Markdown-Dateien erstellen und bearbeiten kann (Markdown ist eine Textauszeichnungssprache mit einfacher Syntax). Eine sehr schöne Funktion von MarkdownPad ist es, links den Text zu schreiben und rechts sich eine HTML-Vorschau anzeigen zu lassen – um zu sehen, wie der Text später in einem Webbrowser aussehen wird. Und diese Vorschau klappte auf einmal nicht mehr.

(Aufs Bild klicken zum Vergrößern)

Unter Windows 7 hatte diese Vorschau tadellos funktioniert, doch nach dem Upgrade auf Windows 10 tat sie das nicht mehr. Dieses Phänomen soll schon unter Windows 8 gelegentlich aufgetreten sein, und die entsprechende Lösung klappte bei mir auch in Windows 10. Man soll das Awesomium-SDK (Software Development Kit) installieren, außerdem Microsofts DirectX End-User Runtimes (June 2010). Das tat ich beides, und anschließend klappte die Vorschau wieder. Allerdings nicht sofort – ich musste im Texteingabebereich des Editors ein bisschen hin und her scrollen und mit der Maus in den Text klicken, und irgendwann sprang die Vorschau im rechten Bereich der Programmoberfläche wieder an. Klingt verrückt, war aber so. Vermutlich hätte auch ein Neustart des Programms geholfen.