Dispatcher Vanity URL:er | AEM

Det här dokumentet hjälper dig att förstå hur Adobe Experience Manager hanterar e-postadresser och andra tekniker, som att använda omskrivningsregler för att ta innehållet närmare leveranssidan.

Beskrivning description

Miljö

Adobe Experience Manager

Problem/symtom

Hur hanterar AEM vanity urls? Finns det ytterligare tekniker för att kartlägga innehåll som ligger närmare leveranskanterna?

Vad är Vanity-URL:er?

När du har innehåll som finns i en mappstruktur som är vettig finns det inte alltid i en URL som är enkel att referera till. Vanity-URL:er fungerar som genvägar. Kortare eller unika URL:er som refererar till det verkliga innehållet.

Ett exempel: /aboutus i /content/we-retail/us/en/about-us.html

AEM författare har möjlighet att ange egenskaper för målarens URL för ett visst innehåll i AEM och publicera det.

För att den här funktionen ska fungera måste du justera dispatcherfiltren så att du kan hantera vantheten. Detta är orimligt om du justerar dispatcherkonfigurationsfilerna med den hastighet som författare måste konfigurera dessa poster för vanlighetssidan.

Av den anledningen har dispatchermodulen en funktion för att automatiskt tillåta allt som listas som en avvikelse i innehållsträdet.

Upplösning resolution

Hur fungerar det?

URL för redigering av Vanity

Författaren besöker en sida i AEM och besöker sidegenskaperna och lägger till poster i delen med huvudadressen.

När de har sparat sina ändringar och aktiverat sidan tilldelas den här sidan huvudrollen.

Touchgränssnitt:

Klassisk innehållssökare:

Obs! Detta är mycket känsligt för namnutrymmesproblem. Vanity-posterna är globala för alla sidor, det här är bara en av de brister du måste planera tillfälliga lösningar för. Vi kommer att förklara några av dem senare.

Resursupplösning/mappning:

Varje post i Slug-kartan är en post för en intern omdirigering. Dessa kartor är synliga i AEM förekomster Felix-konsolen (/system/console/jcrresolver)

Här är en skärmbild av ett kartinlägg som skapats av ett värde för vanity:

I exemplet ovan, när vi ber den AEM instansen att besöka /aboutus, kommer det att resultera i /content/we-retail/us/en/about-us.html

Dispatcher-filter för att tillåta automatiskt:

Dispatcher i ett säkert läge filtrerar bort begäranden på sökvägen/genom Dispatcher eftersom det är roten i JCR-trädet.

Det är viktigt att se till att utgivare bara tillåter innehåll från /content och andra säkra sökvägar osv., och inte sökvägar som /system osv.

Här är busken, fånighet-URL:er som finns i basmappen för / så hur kan vi låta dem nå utgivare samtidigt som de är säkra?

Den enkla dispatchern har en autofilterfunktion och du måste installera ett AEM och sedan konfigurera Dispatcher så att det pekar på den paketsidan. Besök här för AEM.

Dispatcher har ett konfigurationsavsnitt i sin servergruppsfil:

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

Den här konfigurationen anger för Dispatcher att hämta den här URL:en från den AEM instansen som den skickar var 300:e sekund för att hämta listan över objekt som vi vill tillåta igenom.

Cachen för svaret lagras i argumentet /file så i det här exemplet /tmp/vanity_urls

Så om du besöker den AEM instansen på URI:n ser du vad den hämtar:

Det är en superenkel lista.

Skriv om regler som vanlighetsregler

Varför skulle vi nämna att använda omskrivningsregler i stället för standardmekanismen som är inbyggd i AEM som beskrivs ovan?

Förklara enkelt namnutrymmesproblem, prestanda och logik på högre nivå som kan hanteras bättre.

Låt oss gå igenom ett exempel på vanity-posten /aboutus för dess innehåll /content/we-retail/us/en/about-us.html med Apache mod_rewrite-modul för att uppnå detta.

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

Den här regeln söker efter huvudrollen /aboutus och hämtar den fullständiga sökvägen från renderaren med PT-flaggan (Pass Through).

Den kommer också att sluta bearbeta alla andra regler L-flaggor (sista), vilket innebär att den inte behöver gå igenom en stor lista med regler som JCR Resolving måste göra.

Förutom att du inte behöver göra en proxy för begäran och vänta på att den AEM utgivaren ska svara på de här två elementen i den här metoden gör det mycket mer prestandaförbättrande.

Därefter är ikonen här NC-flaggan (ingen skiftlägeskänslig), vilket innebär att om du tömmer URL:en med /Aboutus i stället för /aboutus så fungerar den fortfarande och tillåter att rätt sida hämtas.

Om du vill skapa en omskrivningsregel för att göra detta skapar du en konfigurationsfil på Dispatcher (exempel: /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules) och tar med den i .vhost-filen som hanterar den domän som behöver dessa huvud-URL:er.

Här är ett exempel på ett kodfragment av SSI:

/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

Vilken metod och var den ska användas?

S. Att använda AEM för att styra poster för vanity har följande fördelar:

B. Att använda mod_rewrite för att kontrollera poster för avvikelse har följande fördelar:

C. Använd båda metoderna, men här följer råd och kriterier som ska användas när:

Obs! Om du vill använda AEM-funktionen och undvika namnutrymme kan du skapa en namnkonvention. Använda egna URL:er som är kapslade som /brand1/aboutus, brand2/aboutus, brand3/aboutus