Sofern man Doctrine verwendet sehen die Einträge in der routing.yml so aus:
user:
class: sfDoctrineRouteCollection
options:
model: User
module: user
prefix_path: user
column: id
with_wildcard_routes: true

In der Regel wird die komplette Collection ja auch nur im Backend eingesetzt und dort sind diese Routen meist angemessen. Problematisch wird es nur, möchte man den entsprechenden Usern nicht unbedingt die Datenbank-ID in der URL präsentieren.

Eigentlich kein Problem, sollte man denken. Einfach den Wert von column in bspw. username geändert und die IDs sind hier verschwunden. Die Links in der List-View werden auch korrekt umgewandelt. Klickt man nun aber z.B. auf einen Link in folgender Form: “www.example.com/backend/user/admin/edit” wird er mit hoher Wahrscheinlichkeit zu folgender Fehlermeldung führen:
404 | Not Found | sfError404Exception
Action "user/admin" does not exist.

Symfony erkennt also scheinbar “admin” als Action und nicht “edit”. Grund hierfür sind die Requirements. Das Standardverhalten der sfObjectRouteCollection ist es ‘\d+’ als requirement für die column (siehe Zeile 50) vorzugeben. Dieser reguläre Ausdruck matcht aber nur auf Ziffern.

Auch wenn man nun in folgender Weise versucht diese Requirements zu ändern, kommt man nicht zum gewünschten Ergebnis:
...
with_wildcard_routes: true
requirements: { username: '\w+' }

Symfony nimmt die requirements der Route selbst als Vorgabe und überschreibt die übergebenen options der Collection. Die korrekte Fehlerbehebung sieht daher so aus:
user:
class: sfDoctrineRouteCollection
options:
model: User
module: user
prefix_path: user
column: username
with_wildcard_routes: true
requirements: { username: '\w+' }

Hierbei ist die Einrückung, wie generell in YAML-Dateien, entscheidend.

Potentielle Interessenten können sich direkt über die Website anmelden und erhalten sofort Rückmeldung, ob sie einen festen Platz erhalten haben, oder auf der Warteliste platziert wurden.
Wird später in Folge einer Stornierung ein Platz wieder frei, so rückt automatisch eine Anmeldung aus der Warteliste nach und der Teilnehmer wird per E-Mail informiert.
Dieser Prozess entlastet die Verantwortlichen, die ansonsten jeden Teilnehmer manuell auf seinen Status hinweisen müssten.

Die im PDF-Format gelieferte Agenda der Tagung wurde direkt auf der Seite eingebunden und per microformats ausgezeichnet. Zusätzlich wurde eine iCalendar Datei erzeugt und bereitgestellt. Durch dieses Angebot in verschiedenen Formaten ist es jedem Teilnehmer möglich die angesetzten Vorträge in den eigenen Kalender zu importieren.

Um trotz dieser Einschränkung zumindest in anderen Browsern das PNG zu verwenden ohne auf ein favicon im Internetexplorer zu verzichten, lässt sich mit Hilfe der Conditional Comments eine Umgehung verwirklichen:

<!--[if !IE]><!--><link rel="shortcut icon" href="/favicon.png" /><!--<![endif]-->
<!--[if IE]><link rel="shortcut icon" href="/favicon.ico" /><![endif]-->

Die zweite Zeile wird nur durch Internetexplorer interpretiert, die erste von allen anderen Browsern. So erreicht man ohne große Umstände eine alternative Darstellungsweise.

Entstanden ist aus einer inhaltlichen und gestalterischen Vorlage, die selbstverständlich dem Heft nachempfunden ist, ein Auftritt, der das Magazin in multimedialer Hinsicht ergänzt. Zur Veranschaulichung des Magazins wurde auf die intuitive Page-Flip Technologie zurückgegriffen, ein Bestellformular integriert und die ganze Seite durch ein Video-Editorial abgerundet. Hierbei wurde explizit auf barrierearme Ersatzinhalte wert gelegt, die gleichzeitig mit weiteren gängigen Maßnahmen in diesem Bereich den Grundstein für eine erfolgreiche Suchmaschinenindizierung bilden.

Um Wörter, die keinen bedeutenden Inhalt tragen, zu entfernen, dazu zählen stopwords bzw. Stoppwörter wie bspw. “ein”, “das” und “für”, verwendet Doctrine einen sogenannten “Text Analyzer“. Jedoch entfernt der Doctrine_Search_Analyzer_Standard nur englische stopwords und wandelt Umlaute und weitere Buchstaben wie bereits in einem früheren Artikel beschrieben falsch um, obwohl diese für die Suche in deutscher Sprache einen Unterschied ausmachen ( Äpfel != Apfel ).

Wir haben einen “Doctrine_Search_Analyzer_German” geschrieben, der die oben genannten Mankos behebt. In diesem Zuge bedanken wir uns für eine Liste von solariz.de, die deutsche stopwords enthält.

Zusätzlich zu diesem Analyzer haben wir noch die Möglichkeit integriert, mittels strip_tags HTML-Tags zu entfernen, da diese für die Suche ebenfalls nicht relevant wären. Dafür muss statt des Doctrine_Search_Analyzer_German der Doctrine_Search_Analyzer_StriptagsGerman verwendet werden.

Das ganze ist wieder als symfony-Plugin verpackt, kann jedoch auch problemlos in anderen Anwendungen verwendet werden:
wpDoctrineSearchAnalyzersPlugin

Eingebunden in symfony wird das ganze, sofern es unter Plugins installiert und der Cache geleert wurde, wie folgt:
Artikel:
actAs:
Searchable:
fields: [beitrag]
analyzer: Doctrine_Search_Analyzer_German


Vorab ein Beispiel:
Angenommen es sollen alle Sonderzeichen aus dem Satz “Grüß mich, sonst gibt’s Ärger!” entfernt und durch Leerzeichen ersetzt werden. Hat man ein wenig Erfahrung mit regulären Ausdrücken, so ist diese Aufgabe mittels preg_replace einfach zu bewerkstelligen. preg_replace('/\W/', ' ', "Grüß mich, sonst gibt's Ärger!" )
Bei ANSI codierten Texten mag dies noch funktionieren, bei UTF-8 führt dieser Ausdruck allerdings zu falschen Zeichendarstellungen.

Dieser Umstand lässt sich durch den ‘u’-modifier beseitigen:
preg_replace('/\W/u', ' ', "Grüß mich, sonst gibt's Ärger!" );

Wer jetzt, so wie ich, einen Windows-PC als Entwicklerrechner hat, wird sich schon über das Ergebnis freuen. Zu früh gefreut! Einmal auf den eigenen Webspace hochgeladen offenbart sich, dass trotz korrekter Zeichenzuordnung das dort installierte Betriebssystem, der Webserver oder PHP offenbar nichts davon hält Umlaute auf die Zeichenklasse “\W” zu “matchen” und diese somit rausschmeißt. echo preg_replace('/\W/u', ' ', "Grüß mich, sonst gibt's Ärger!" ); ergibt in der Ausgabe: Gr mich sonst gibt s rger

Dies kann unter anderem auch mit der gesetzten “locale” Einstellung zusammenhängen.

Abhilfe schafft nun die extra eingeführte Escape-Sequenz “\pL” die für einen Buchstaben in beliebiger Sprache steht. Dies führt zum korrekten Ergebnis: echo preg_replace('/\[^\pL]/u', ' ', "Grüß mich, sonst gibt's Ärger!" ); ergibt in der Ausgabe: Grüß mich sonst gibt s Ärger

Und da es thematisch passt und es sich nicht lohnt einen eigenen Beitrag zu verfassen: Wer die korrekte Umwandlung eines UTF-8-Strings mit Umlauten in Kleinbuchstaben möchte, sollte statt strtolower($string); lieber mb_strtolower($string,"UTF-8"); verwenden. Ansonsten werden die Umlaute durch Fragezeichen ersetzt.

Diese Funktionalität wird in Doctrine ( und wenn man Doctrine in symfony verwendet auch dort ) von der Klasse Doctrine_Template_Sluggable bzw., da diese sie delegiert, von Doctrine_Inflector übernommen. Der einzige Nachteil der Implementation ist, dass die Methode “unaccent” deutsche Umlaute durch einzelne Buchstaben ersetzt. Das bedeutet aus ‘ö’ wird ‘o’ und aus ‘Ä’ wird ‘A’. Korrekt wäre jedoch eine Ersetzung in folgender Form:

  Ä => Ae      ä => ae
  Ö => Oe      ö => oe
  Ü => Ue      ü => ue
  ß => ss

Dadurch können die Besucher, aber auch die Suchmaschinen, die URL besser verstehen.

Um diesen Mangel zu korrigieren, haben wir für symfony ein Plugin geschrieben und hier zum Download bereitgestellt:
wpDoctrineUmlautinflectorPlugin

Zur Installation wird einfach der Plug-In-Ordner in das Verzeichnis “plugins” des entsprechenden Projekts kopiert und der Cache geleert. Anschließend muss in der schema.yml lediglich der sog. “builder”, d.h. die Klasse die den Slug erstellt, festgelegt werden. Hier ein Beispiel: Artikel:
actAs:
Sluggable:
fields: [titel]
builder: [Doctrine_Umlautinflector, urlize]

Wer Doctrine ohne symfony verwendet kann jedoch die darin enthaltene Klasse Umlautinflector einfach adaptieren.

Dies mag beim Backend noch vertretbar sein, kann jedoch bei öffentlichen apps zu Verwirrungen führen. Außerdem mag der ein oder andere aus SEO-technischen Gründen etwas gegen diese URLs haben.

Möchte man nun ‘backend/’ statt ‘backend.php/’ anzeigen lassen, lässt sich eine Möglichkeit, die bisher für uns bestens funktioniert hat, durch folgende Schritte realisieren:

1. Ordner ‘backend/’ direkt im Ordner ‘web/’ erstellen.
2. Datei ‘backend.php’ aus ‘web/’ in ‘backend/’ verschieben.
3. Datei ‘.htaccess’ aus ‘web/’ in ‘backend/’ kopieren.
4. In der ‘.htaccess’ folgende Veränderungen durchführen:
   RewriteRule ^(.*)$ index.php [QSA,L] ändern in RewriteRule ^(.*)$ backend.php [QSA,L] und direkt darüber folgende Zeilen einfügen: RewriteRule ^(.*)$ ../$1 [QSA]
RewriteCond %{REQUEST_FILENAME} !-f Diese sorgen dafür, dass weiterhin alle Bilder und CSS-Dateien korrekt geroutet werden.
5. In der Datei ‘backend.php’ folgende Veränderungen durchführen:
   require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php'); ändern in require_once(dirname(__FILE__).'/../../config/ProjectConfiguration.class.php'); damit die Projektkonfiguration noch gefunden wird.
6. In der ‘apps/backend/config/settings.yml’ bei prod no_script_name auf on setzen.
   prod:
.settings:
no_script_name: on

Das war es soweit schon. Wir haben es uns angewöhnt in der gleichen Weise auch die ‘_dev.php’ Dateien zu behandeln. So ergibt sich folgende Dateistruktur:

web/
  backend/
    .htaccess
    backend.php
  dev/
    backend/
      .htaccess
      backend_dev.php
    .htaccess
    frontend_dev.php
  .htaccess
  index.php

Natürlich sind hier ebenfalls die ‘.htaccess’ und der Pfad zur Konfiguration sowie der ‘no_script_name’ der jeweiligen ‘environments’ anzupassen.

Bisher wurden Lieferunternehmen und Kunden von mehreren Mitarbeitern per Telefon kontaktiert, um die die Anliefertermine an verschiedenen Lägern europaweit zu erfragen bzw. weiterzugeben. Dass dieser Prozess eine hohe Kapazitätenbindung erforderte ist selbsterklärend.

Mit Hilfe von PHP und dem Zend Framework wurde ein webbasiertes Lieferinformationssystem geschaffen, dass allen Beteiligten einen seperaten Zugang gewährt. Somit haben die Lieferunternehmen zentrale Anlaufstelle um Ihre Termine einzutragen. Die Kunden der ULD GmbH können sich Ihre Lieferberichte wahlweise täglich oder wöchentlich per E-Mail zuschicken lassen.

Das Ergebnis ist eine erhebliche Zeiteinsparung auf Seiten der United Logistics & Distribution GmbH ohne zusätzliche Belastung Ihrer Partner.

• 

  Ausschnitt aus dem Adminbereich

• 

  Exemplarischer Lieferbericht

• 

  Eintragung der Liefertermine

Aus vertragsrechtlichen Gründen können wir leider keinen direkten Einblick in das Projekt gewähren.

Ein modularer Systementwurf basierend auf Internet-Technologie in Verbindung mit aktuellen Frameworks erhöht die Flexibilität und Verteilung der daraus entstehenden Anwendung.

Um einen einfachen Einsteig für spätere Entwickler zu erleichtern wurde PHP in Verbindung mit symfony gewählt.

Das Resultat ist eine Sammlung vielseitiger und ineinander greifender Controllingwerkzeuge die dezentral organisierte und in unterschiedlichen Erscheinungsformen vorkommende Tools ablöst.

Aus vertragsrechtlichen Gründen können wir leider keinen Einblick in das Projekt gewähren.