Dispatcher-Vanity-URLs

Dieses Dokument hilft Ihnen zu verstehen, wie AEM mit Vanity-URLs und einige zusätzliche Techniken handhabt, die Rewrite-Regeln verwenden, um Inhalte näher am Versand zu mappen.

🏠Inhalt

🔙Zurück Dispatcher Flushing

Was sind Vanity-URLs?

Wenn Sie Inhalte haben, die sich in einer sinnvollen Ordnerstruktur befinden, wird sie nicht immer in einer URL gespeichert, die einfach zu referenzieren ist. Vanity-URLs sind wie Verknüpfungen. Es sind kürzere oder eindeutige URLs, die auf den Ort verweisen, an dem sich der tatsächliche Inhalt befindet.

Beispiel:/aboutus zeigt auf /content/we-retail/us/en/about-us.html

AEM-Autoren haben die Möglichkeit, Eigenschaften von Vanity-URLs für einen Inhaltsabschnitt in AEM zu spezifizieren und zu veröffentlichen.

Damit dies funktioniert, müssen Sie die Dispatcher-Filter so einstellen, dass sie die Vanity-URLs passieren lassen. Doch dies wäre zu aufwendig, da die Konfigurationsdateien des Dispatchers nicht mit derselben Geschwindigkeit angepasst werden können, mit der Autoren diese Vanity-Seiteneinträge einrichten.

Aus diesem Grund verfügt das Dispatcher-Modul über eine Funktion, durch die automatisch alles zugelassen wird, was als Vanity in der Inhaltsstruktur aufgeführt wird.

Funktionsweise

Erstellen von Vanity-URLs

Sie besuchen als Autor eine Seite in AEM und deren Seiteneigenschaften und fügen die Einträge im Vanity-URL-Abschnitt hinzu.

Nachdem Sie Ihre Änderungen gespeichert und die Seite aktiviert haben, ist die Vanity dieser Seite zugewiesen.

Berührungsempfindliche Benutzeroberflächen:

Dropdown-Dialogmenü für die AEM-Authoring-Benutzeroberfläche im Anzeigebereich des Site-Editors

Dialogseite der AEM-Seiteneigenschaften

Klassischer Content Finder:

Sidekick-Seiteneigenschaften in der klassischen Benutzeroberfläche von AEM SiteAdmin

Dialogfeld der Seiteneigenschaften der klassischen Benutzeroberfläche

Hinweis:

Achten Sie in diesem Bereich auf mögliche Namensraumprobleme.

Vanity Einträge wirken sich global auf alle Seiten aus. Hierbei entstehen oft Probleme. Weiter unten werden Umgehungsschritte bei Problemen beschrieben.

Auflösen/Mappen von Ressourcen

Jeder Vanity-Eintrag ist ein Sling Map-Eintrag für eine interne Umleitung.

Diese Maps können angezeigt werden, indem Sie die AEM-Instanzen in der Felix-Konsole (/system/console/jcrresolver) aufrufen

Im Folgenden sehen Sie einen Screenshot des Map-Eintrags, der von einem Vanity-Eintrag erstellt wurde:

Konsolen-Screenshot eines Vanity-Eintrags in den Ressourcen-Auflösungsregeln

Wenn wir im obigen Beispiel die AEM-Instanz auffordern, /aboutus zu besuchen, wird sie in /content/we-retail/us/en/about-us.html aufgelöst.

Filter mit automatischer Genehmigung durch den Dispatcher

Der Dispatcher filtert im sicheren Status Anfragen an den Pfad / durch den Dispatcher heraus, da dies der Stamm der JCR-Struktur ist.

Wichtig dabei ist sicherzustellen, dass Publisher nur Inhalte aus dem /content und anderen sicheren Pfaden zulassen und nicht aus Pfaden wie /system.

Hier ist die rub, Vanity-URLs live im Basisordner von /. Wie können wir also sicherstellen, dass die Publisher erreicht werden, und der Vorgang dennoch sicher ist?

Der einfache Dispatcher verfügt über einen Mechanismus zum Ermöglichen des automatischen Filterns. Sie müssen ein AEM-Paket installieren und dann den Dispatcher so konfigurieren, dass er auf diese Package-Seite zeigt.

https://experience.adobe.com/#/downloads/content/software-distribution/en/aem.html?package=/content/software-distribution/en/details.html/content/dam/aem/public/adobe/packages/granite/vanityurls-components

Der Dispatcher hat einen Konfigurationsabschnitt in seiner Farm-Datei:

/vanity_urls { 
    /url    "/libs/granite/dispatcher/content/vanityUrls.html" 
    /file   "/tmp/vanity_urls" 
    /delay  300 
}

Diese Konfiguration weist den Dispatcher an, diese URL alle 300 Sekunden von der AEM-Instanz abzurufen, um die Liste der Elemente abzurufen, die wir passieren lassen möchten.

Der Cache der Antwort wird dabei im /file-Argument gespeichert, also in diesem Beispiel /tmp/vanity_urls.

Wenn Sie also die AEM-Instanz unter dem URI besuchen, sehen Sie, was sie abruft:

Screenshot des unter /libs/granite/dispatcher/content/vanityUrls.html gerenderten Inhalts

Dies ist eine einfache Liste.

Rewrite-Regeln als Vanity-Regeln

Warum erwähnen wir die Möglichkeit, dass Regeln umgeschrieben werden können, anstatt den oben beschriebenen in AEM integrierten Standardmechanismus zu verwenden?

Es soll einfach gesagt eine bessere Handhabung von Problemen mit Namensräumen, der Performance und Logik auf höherer Ebene ermöglicht werden.

Im Folgenden sehen Sie ein Beispiel für den Vanity-Eintrag /aboutus für seinen Inhalt /content/we-retail/us/en/about-us.html unter Verwendung des Apache-Moduls mod_rewrite.

RewriteRule ^/aboutus /content/we-retail/us/en/about-us.html [PT,L,NC]

Diese Regel sucht nach der Vanity /aboutus und ruft den vollständigen Pfad vom Renderer mit der PT-Flag (Pass Through) ab.

Dabei wird die Verarbeitung aller anderen Regeln (L flag (Last)) angehalten. Dadurch wird verhindert, dass keine überlange Liste von Regeln wie JCR Resolving durchlaufen werden muss. 

Neben der Tatsache, dass die Anfrage keinen Proxy benötigt und nicht auf die Antwort des AEM Publishers warten muss, ermöglichen diese beiden Elemente dieser Methode eine wesentlich bessere Performance.

Zusätzlich wird eine NC-Flag verwendet (keine Beachtung der Groß-/Kleinschreibung), d. h. wenn ein Kunde für den URI irrtümlicherweise /AboutUs statt /aboutus schreibt, funktioniert dies dennoch und die richtige Seite lässt sich abrufen.

Um eine Umschreibungsregel zu erstellen, definieren Sie eine Konfigurationsdatei für den Dispatcher (Beispiel: /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules) und fügen Sie sie in die .vhost-Datei ein, die die Domäne verarbeitet, in der diese Vanity-URLs gelten.

Im Folgenden finden Sie ein Beispiel für ein Code-Fragment für die Einfügung in /etc/httpd/conf.d/enabled_vhosts/we-retail.vhost

<VirtualHost *:80> 
 ServerName weretail.com 
 ServerAlias www.weretail.com 
        ........ SNIP ........ 
 <IfModule mod_rewrite.c> 
  ReWriteEngine on 
  LogLevel warn rewrite:info 
  Include /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules 
 </IfModule> 
        ........ SNIP ........ 
</VirtualHost>

Methoden und deren Anwendung

Die Verwendung von AEM zur Steuerung von Vanity-Einträgen hat folgende Vorteile:

  • Autoren können sie spontan erstellen.
  • Sie sind im Inhalt enthalten und können mit dem Inhalt verpackt werden.

Die Verwendung von mod_rewrite zur Steuerung von Vanity-Einträgen hat folgende Vorteile:

  • Schnellere Inhaltsauflösung
  • Näher an Inhaltsanfragen von Endbenutzern
  • Mehr Erweiterbarkeit und Optionen zur Steuerung der Inhaltszuordnung unter anderen Bedingungen
  • Die Beachtung der Groß-/Kleinschreibung kann erforderlich sein.

Hier finden Sie Ratschläge und Kriterien zur Verwendung der beiden Methoden:

  • Wenn die Vanity temporär ist und wenig Traffic geplant ist, sollten Sie die integrierte AEM-Funktion verwenden
  • Wenn die Vanity ein grundlegender Endpunkt ist, der sich nicht oft ändert und häufig verwendet wird, verwenden Sie eine mod_rewrite-Regel
  • Wenn der Vanity-Namensraum (z. B.: /aboutus) für viele Marken auf derselben AEM-Instanz wiederverwendet wird, verwenden Sie Rewrite-Regeln.
Hinweis:

Wenn Sie die AEM-Vanity-Funktion verwenden und einen Namensraum vermeiden möchten, können Sie eine Benennungsregel erstellen. Verwenden von Vanity-URLs, die wie /brand1/aboutus, brand2/aboutus, brand3/aboutus verschachtelt sind.

Adobe-Logo

Bei Ihrem Konto anmelden