Saubere URLs mit „lesbaren“ Titeln erzeugen

Die als „Permalink“ oder „Slug“ bekannten Endungen von URLs, die meist den Titel abbilden, kennen wohl die meisten Internetnutzer. Dieser Beitrag hat zum Beispiel den Slug saubere-urls-mit-lesbaren-titeln-erzeugen.

Diese Art und Weise des Aufrufs ist eine leserfreundliche Alternative zum Aufruf via ID (index.php?id=3242) und bietet vor allem den Vorteil, dass der Leser sofort anhand der URL erkennen kann, welchen Artikel er aufgerufen hat.

Das Erzeugen eines URL Slugs ist nicht ganz so trivial. Zwar gibt es sehr einfache Methoden (zum Beispiel alle Zeichen zu verwerfen, die nicht a-z oder 0-9 sind), aber dann verliert die URL besonders im Deutschen viel Sinn. Denn Umlaute oder das ß würden komplett unter den Tisch fallen.

Bei Matteo Spinelli habe ich eine schöne Funktion gefunden, die ich jetzt benutze, um eigene Slugs zu erstellen. Alle nicht darstellbaren Zeichen werden bei dieser Funktion durch ähnliche Buchstaben ersetzt, also zum Beispiel das ß durch Doppel-S, ö und Ö durch o und so weiter.

Ich habe die Funktion für meine Zwecke angepasst und erweitert. Sie erzeugt jetzt einzigartige Slugs, vorausgesetzt niemand nutzt den gleichen Titel in exakt der gleichen Sekunde (das genügt als „uniqueness“ für meinen Anwendungsfall).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
 * Generate a readable (URL-valid) slug from a given string
 * @param string $str
 * @return string
 */
public static function slug($str){
 
	setlocale(LC_ALL, 'en_US.UTF8');
	$slug = iconv('UTF-8', 'ASCII//TRANSLIT', $str);
	$slug = preg_replace("/[^a-zA-Z0-9\/_|+ -]/", '', $slug);
	$slug = strtolower(trim($slug, '-'));
	$slug = preg_replace("/[\/_|+ -]+/", '-', $slug);
	$slug = (time()-1388530800).'-'.$slug; //1388530800 => 2014-01-01
	return $slug;
 
}

Direkter Joomla-Logout ohne Zwischenseite (J!2.5 und höher)

Bei Joomla gibt es ein Problem, wenn man sich direkt ausloggen möchte. Ich nutze beispielsweise ein Menü (Modul), in dem ich gerne einen Abmelden-Link haben möchte.

Da gibt es dann 3 Optionen:

  1. Ich baue eine Form ein, die den direkten Logout erlaubt. Das ist lässt sich dann sehr schlecht mit CSS stylen.
  2. Ich leite den Nutzer auf eine Zwischenseite von com_users weiter, wo er sich ausloggen kann. Das ist umständlich.
  3. Ich baue einen direkten Logout-Link mit dem nötigen Token.

Der 3. Weg ist natürlich die beste Lösung, allerdings habe ich ihn nirgendwo beschrieben gesehen. Daher jetzt hier kurz und knapp:

<a href="<?php echo JRoute::_('index.php?option=com_users&task=user.logout&'.JSession::getFormToken().'=1'); ?>"><?php echo JText::_('JLOGOUT'); ?></a>

phpmyadmin sicher(er) zur Verfügung stellen

Möchte man phpmyadmin mehreren Domains zur Verfügung stellen, so bietet sich dafür das Debian-Paket „phpmyadmin“ an:

1
apt-get install phpmyadmin

Danach kann man unter /etc/phpmyadmin/apache.conf eine config finden, die man per

1
ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf.d/phpmyadmin.conf

in das Apache-Verzeichnis einbindet.

Jetzt muss an hier aber noch ein wenig gefeilt werden, denn so stellt man phpmyadmin grundsätzlich auch über HTTP – also unverschlüsselt – zur Verfügung. Administriert jetzt jemand über ein öffentliches Netzwerk seine Datenbank (immer an den DAU denken, auch wenn es sich erst mal vollkommen an den Haaren herbeigezogen anhört), hat man ruck-zuck ein Problem.

Deshalb leite ich grundsätzlich alle HTTP-Anfragen an phpmyadmin einfach nach HTTPS weiter. Dazu öffnet man die /etc/phpmyadmin/apache.conf und fügt ganz oben folgenden Text ein:

1
2
3
4
5
6
7
8
9
<IfModule mod_rewrite.c>
        <IfModule mod_ssl.c>
                <Location ~ "/phpmyadmin(/|$)">
                        RewriteEngine on
                        RewriteCond %{HTTPS} off
                        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
                </Location>
        </IfModule>
</IfModule>

Jetzt wird jeder Besucher von http://domain.de/phpmyadmin zu https://domain.de/phpmyadmin umgeleitet, was phpmyadmin ein ganzes Stück sicherer macht. Trotzdem ist zu überlegen, ob man die Software nicht lieber zusätzlich mit einem .htaccess-Schutz versieht. Wie das geht, erfährt man unter anderem bei SELFHTML.

Lange Zend DB-Queries bringen PHP/Apache zum Absturz

Beim Programmieren einer Anwendung mit Zend und IBM DB2 bin ich auf ein Phänomen gestoßen, das zunächst unerklärlich schien. Führte ich einen langen Query aus (in diesem Fall sollte ein längerer XML-String in ein XML-Datenfeld der IBM DB2 Express-C geschrieben werden), so stürzte Apache ohne Fehlermeldung ab. In den Logs tauchte nur „restarting“ auf, sonst nichts.

Nach etwas Recherche stellte sich heraus, dass wohl eine fehlerhafte Implementierung der PCRE-Erweiterung Schuld an dem Desaster ist. Ist Backtracking auf einen zu hohen Wert eingestellt, so konsumiert PCRE (Zend Framework benutzt preg_match(), um SQL-Queries auf Korrektheit zu prüfen) den gesamten Stack, wodurch der Prozess sang- und klanglos abgeschossen wird.

Eine Erklärung zu PCRE-Backtracking gibt es hier: http://www.regular-expressions.info/catastrophic.html.

Für PHP ist die Lösung relativ simpel, der voreingestellte Wert von 100.000 für pcre.backtrack_limit und pcre.recursion_limit muss (entgegen einiger Aussagen in diversen Bugreports und Tutorials) heruntergesetzt werden. In meiner PHP.ini sieht das zurzeit folgendermaßen aus:

1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
[Pcre]
;PCRE library backtracking limit.
; http://php.net/pcre.backtrack-limit
pcre.backtrack_limit=1000
 
;PCRE library recursion limit.
;Please note that if you set this value to a high number you may consume all
;the available process stack and eventually crash PHP (due to reaching the
;stack size limit imposed by the Operating System).
; http://php.net/pcre.recursion-limit
pcre.recursion_limit=1000

Damit laufen meine Queries (~1800 Zeichen pro Query) anstandslos durch. Bei Bedarf kann dieser Wert auch weiter abgesenkt werden, auf 500 zum Beispiel. Da die PCRE-Funktion einen Aufwand von O(2^n) hat, bringt auch diese relativ kleine Änderung wieder recht viel.

10 falsche Vorstellungen über PHP

Ich mag PHP. Habe es schon immer gemocht, seit ich in meiner Schulzeit von HTML(3)-Markup – was ich davor für Programmieren hielt – zu echten Programmiersprachen gewechselt bin. PHP ist einfach zu erlernen, bietet viel Komfort und, unter Beachtung verschiedener Voraussetzungen, eine hohe Performance bei Nutzung relativ weniger Systemressourcen. Zudem ist es (fast) überall im Web verfügbar, egal ob beim Free-Hoster mit Werbefinanzierung oder auf dem 800-Euro-pro-Monat-Rootserver.

Hartnäckig halten sich allerdings zahlreiche Gerüchte über PHP, von schlechter Performace (sehr häufig) über Bedenken wegen fehlender Objektorientierung bis zur Angst, dass Zend aufgrund seiner Vormachtstellung im Development von PHP die Sprache vollständig kontrolliert. Manuel Lemos hat dazu auf phpclasses.org einen sehr guten Artikel verfasst, den sich jeder Interessierte mal zu Gemüte führen sollte. Sogar als erfahrener Developer kann man dort noch das ein oder andere, das man vielleicht noch nicht wusste, erfahren. Oder wussten Sie, dass man mit PHP Windows-Dienste erstellen kann?

Neues Projekt: Huruhelpdesk für Joomla 1.6

Während meiner DEV-Tätigkeit für rising-gods.de stehe ich ab und zu einmal vor größeren Umwälzungen und muss dann entscheiden, wann sie durchzuführen sind. Bei über 150.000 (Stand zum Zeitpunkt der Artikelerstellung) registrierten Nutzern ist das keine einfache Frage.

Zuletzt trat so eine Situation auf, als ich von Joomla 1.5.22 auf das ausgereiftere 1.6.3 wechseln wollte. Schon vorher wurde ich mehrmals vom Admin-Team auf einen Wechsel angesprochen, allerdings halte ich bei Joomla Versionen kleiner als x.x.3 generell für relativ unsicher. Die Liste der Security-Fixes im Patchlog von 1.6.1 und 1.6.2 hat mich dann auch wieder in dieser Ansicht bestätigt. Mit dem Release von 1.6.3 kam dann die Entscheidung, jetzt zu wechseln. Dazu mussten etliche Komponenten, u.a. das Premiumsystem, und das Template umgeschrieben werden. Weitere Komponenten wie das Kunena-Forum mussten aktualisiert und wieder dem vorherigen Funktionsstand angepasst werden.

Die größte Änderung betraf jedoch Huruhelpdesk, für das es keine J!1.6-kompatible Version gibt. Zudem scheint der Entwickler James R. Erickson momentan ziemlich inaktiv zu sein. Daher habe ich beschlossen, den Huruhelpdesk 0.88d – den wir bei rising-gods.de als Ticket-System einsetzen – selbst 1.6-kompatibel zu machen. Alles in Allem kein besonders schwieriges Unterfangen, wenn auch zeitaufwändig, da die Joomla-Docs für 1.6 zurzeit noch einfach miserabel sind. Besonders das Herausfinden der neuen XML-Strukturen für die Installations-XMLs hat viel länger gedauert, als eigentlich nötig. Letztendlich jedoch war auch dieses Hindernis genommen und nach einer Woche Regelbetrieb in der 150k-Community von Rising Gods ohne Zwischenfälle habe ich mein Projekt auf Github veröffentlicht, um auch anderen Huru-Nutzern den Umstieg auf Joomla 1.6 zu ermöglichen.