Включение Vanity URL с помощью Adobe Experience Manager

При миграции с одной версии сайта на совершенно новый веб-сайт или при переходе со старой CMS на Adobe Experience Manager пользователям часто приходится сталкиваться с двумя вещами: переписывать устаревшие перенаправления URL и обрабатывать тщетные URL.

Миграция может создать горы устаревших URL-адресов, которые необходимо переписать. Вам нужно как-то обрабатывать эти URL-адреса, независимо от того, связаны ли они с SEO-изменением шаблонов URL-адресов, устаревшим лицензионным контентом, к которому вы больше не можете получить доступ, или просто со старыми статьями, которые необходимо перенаправить в новые места.

Таблицы этих URL-адресов обычно создаются при переходе с одной архитектуры сайта на другую, и разработчикам и сотрудникам, как правило, поручается их правильная маршрутизация. Я работал над сайтами с более чем 100 000 устаревших URL . По поручению SEO-команд, их иногда добавляли, используя Splunk, чтобы отобрать список 404, которые пользователи и сканеры создают для сайта, а затем выработать правила перезаписи, чтобы направить эти запросы в соответствующий контент текущего веб-сайта.

По словам Wordstream URL-адрес тщеславия - это «уникальный веб-адрес, предназначенный для маркетинговых целей… пользовательский URL-адрес, который помогает пользователям запомнить и найти определенную страницу вашего веб-сайта».

Маркетинговые потребности являются тем, что движет этими URL, и они часто меняются вне циклов выпуска программного обеспечения. Нетехнические люди обычно указывают, куда они хотят, чтобы URL-адреса шли, поэтому заставить этих людей обновлять файлы конфигурации непосредственно в Apache крайне нежелательно, если не невозможно.

Как правило, вышеуказанные проблемы можно решить с помощью перенаправления 302/301 или сквозной перезаписи (когда URL-адрес не изменяется, но пользователь получает различное содержимое на серверной части). Существует много разных способов обработки перенаправлений, что приводит к созданию множества диких и причудливых решений для их обслуживания и обновления.

Обработка массовых устаревших переписываний
По большей части устаревшие URL лучше всего обрабатываются в Apache, и вы обычно можете использовать Apache RewriteMaps для обработки массовых переписываний для устаревших шаблонов URL, старых 404-х и т. д. Я успешно набрал более 100 000 переписывает в индексированный хеш-файл DBM, и даже крошечные двухпроцессорные облачные серверы смогли справиться с этим абсолютно без проблем. Основная последовательность:

1. Пусть ваши специалисты по маркетингу, контенту и SEO предоставят вам список - желательно в Excel - всех желаемых перенаправлений URL. Пусть они разбивают его на:

• Переписывает они хотят быть постоянными (например, 301 перенаправление)
• Переписывает, через который они хотят пройти (например, /news.htmlpulls контент из /news/2016/current/index.html, но все равно показывает /news.html в браузере пользователя)

2. Экспортируйте эти списки из Excel в текстовые файлы с разделителями табуляции.
3. Сохраните эту текстовую карту в системе контроля версий, чтобы вы могли отслеживать изменения в ней.
4. Кодируйте эту текстовую карту как файл DBM с помощью:

httxt2dbm -i mapfile.txt -o mapfile.map

5. Добавьте директиву в конфигурацию HTTPD с помощью:

Переписать имя карты "dbm: /etc/apache/mapfile.map"

6. Затем добавьте rewriteRules для каждой добавляемой карты в зависимости от способа обработки URL-адресов.

В идеале на вашем CI-сервере должны выполняться команды httxt2dbm, поэтому при обновлении rewriteMaps ваш CI-сервер может извлекать обновленные карты из системы управления версиями, преобразовывать их в DBM, передавать их в Apache и запускать сервер.

Обработка тщетных URL-адресов с помощью модуля AEM Dispatcher
До недавних обновлений не было чистого способа позволить маркетинговым командам самостоятельно обновлять уникальные URL. Я работал с командами, которые написали свое собственное приложение на Java, чтобы дать командам по маркетингу и SEO пользовательский интерфейс для ввода переписанных текстов; вывод автоматически подавался в Apache.

Другие команды пытались обработать все изменения в Sling, но это требовало от разработчиков разбора и загрузки карт перезаписи Sling. Другие по-прежнему пытались напрямую перейти к / crx / de в AEM и вручную редактировать узлы / etc / map на каждом сервере - процесс, который оставлял значительные возможности для ошибок вручную и внесения различий в уровни DEV, STG и PRD приложения.

К счастью, недавние обновления модуля AEM Dispatcher (начиная с версии 4.1.9 модуля) позволяют авторам напрямую контролировать пользовательские URL-адреса из пользовательского интерфейса автора, и они автоматически отправляются издателям, которые затем открывают их для диспетчеров. Это работает очень хорошо - он берет на себя действие по обновлению и поддержанию правил переписывания для тщеславия полностью из рук ИТ и передает его в руки маркетинга, где он принадлежит.

Вот как это сделать:

• На узлах AEM Publish загрузите и установите VanityURLS-Компоненты пакет из Adobe Package Share или вытащите его и установите вручную в / crx / packmgr .
• Перейдите к / useradmin в вашем экземпляре публикации и разрешите разрешение «Чтение» для / libs / granite / dispatcher / content / vanityUrls для группы «Все». Сделайте это, дважды щелкнув «Анонимный» пользователь, затем перейдите к «Разрешения» и проверьте столбец «Чтение» для указанного выше пути.
• Если в настройках диспетчера у вас нет разрешающего доступа, добавьте в диспетчер правило фильтрации, чтобы разрешить вызов тщетного URL-адреса в экземпляре публикации:

/ 0100 {/ type "allow" / url "/libs/granite/dispatcher/content/vanityUrls.html"}

• Добавьте правило кэширования, чтобы предотвратить кэширование этого URL:

/ 0001 {/ type "deny" / glob
"/libs/granite/dispatcher/content/vanityUrls.html"}

• Добавьте конфигурацию vanity_urls в ферму:

Файл, определенный в параметре / file, не создается автоматически и не обновляется с интервалом времени, установленным в / delay, а только при выполнении запроса, который не соответствует правилам / filter вашего диспетчера. При сбое он проверяет, существует ли файл - если нет, он сгенерирует и использует его, извлекая /libs/granite/dispatcher/content/vanityUrls.html от издателя. Если он есть, и не старше / задержки секунд, он будет его использовать. Наконец, если он старше / задержка секунд, он обновит его из экземпляра публикации и будет использовать его.

Похожие

Комментарии