Автор: Sitecore MVP Джейсон Сент-Сир
Думаете о том, чтобы сделать набег на территорию обновления Sitecore 8? Мы поможем вам определить семь скрытых опасностей, чтобы вы не попались в их ловушки на своем пути:
В прежние времена, если вы отважились отправиться в пункт назначения без хорошей карты, вы могли столкнуться со всевозможными опасностями. Опасные воды будут отмечены каким-нибудь страшным зверем или леденящим душу сценарием, предупреждающим о надвигающейся гибели. Если бы вы отправились в темноту в одиночку, вас, возможно, даже съела бы мразь! Самый ценный игрок Sitecore (и картограф обновлений) Джейсон Сент-Сир направляет вас к безопасности, намечая 7 скрытников, от которых следует держаться подальше во время вашего путешествия Обновление Sitecore 8.
Скрытень №1:
Web.config такой большой, что может вас съесть
IIS имеет ограничение по умолчанию в 250 КБ для любого загружаемого файла конфигурации, включая файл Web.config. Новый файл Sitecore 8 Web.config поставляется с огромным размером 241 КБ. Большинство решений начинают сталкиваться с ошибкой IIS Не удается прочитать файл конфигурации, поскольку он превышает максимальный размер файла после обновления, особенно если у вас есть RewriteRules в вашем файле Web.config, так как они быстро занимают место на диске.
Чтобы избежать этой ошибки, попробуйте разбить настраиваемые разделы на отдельные файлы конфигурации и оставить файл Sitecore 8 Web.config как можно более чистым. 9 КБ съедаются довольно быстро!
Sitecore знает об этой проблеме, и существуют запросы в службу поддержки, поэтому мы должны увидеть это в будущем выпуске.
Скрытень №2:
Атака клонов
Почти все знают, что в Sitecore 8 появилась концепция нового поля Final Renderings для поддержки версионных макетов. Это здорово и помогает во многих отношениях, если только вы не импортируете клоны в Sitecore 8 из более старой версии.
По умолчанию, поскольку это поле не существовало в более старых версиях, клон будет иметь нулевое значение. Для обычного элемента это здорово, потому что весь макет находится в общем поле, и все работает как обычно. Для клонов значение null означает использование исходного значения из источника клона. Если вы отредактируете исходный элемент клона, его окончательные визуализации заменят презентацию вашего клона.
Скрытень №3:
Устаревшие правила и действия, пожирающие неосторожных
Если вы выполняете обновление с Sitecore 6.x, некоторые системные папки, которые раньше находились в общей папке (/sitecore/system/Settings/Rules/Common), теперь перемещаются в Устаревшее расположение в дереве (/sitecore/system/Settings/Rules/Definitions/Obsolete/Common). Это действительно произошло в Sitecore 7, наряду с довольно большой реструктуризацией этой области дерева. У некоторых решений есть свои настраиваемые правила в этом устаревшем расположении, поэтому вам нужно быть осторожным при импорте из старой базы данных, особенно если десериализация является вашим методом миграции.
Папки имеют одинаковые идентификаторы GUID, поэтому, если вы разместили в этих папках некоторые из своих собственных правил, вы сможете достаточно легко найти местоположение сопоставленной папки. Если вы импортируете этот контент, убедитесь, что вы отправляете его в правильное место или найдите новое место для ваших правил.
Скрытень №4:
Закодированные URL-адреса мультимедиа из космоса
Это еще один забавный момент, который был представлен в Sitecore 7, поэтому влияет только на вас, если вы обновляетесь с версии 6.x. Способ разрешения элементов мультимедиа из URL-адреса был исправлен в Sitecore 7 и выше, чтобы работать так же, как и разрешение обычного элемента контента. К сожалению, это может привести к поломке некоторых ваших медиа-ссылок, если вы кодируете пробелы в URL-адресах дефисами.
Проблема в том, что если вы кодируете пробелы в дефисы, ваше решение может зависеть от старого метода разрешения, в котором родительские элементы могли иметь пробелы или дефисы в одном и том же пути.
Например: /Files/Media Folder/Media-Item. Это больше не работает! Пути должны быть согласованными (пробелы или дефисы, а не смесь).
Подробности и исправления смотрите здесь.
Скрытень № 5:
Роли, потопившие корабли
Импорт ролей с помощью сериализации из другой базы данных необходимо выполнять с осторожностью. Между Sitecore 6.6 и Sitecore 8 в систему было введено несколько новых ролей. Существующие определения ролей также изменились, поскольку они могут наследоваться от новых родительских ролей.
Если вы планируете перенести определения своих ролей, я советую сериализовать как чистые роли Sitecore 8, так и определения ролей вашего решения в файловую систему с помощью инструмента «Диспетчер ролей». На этом этапе используйте инструмент сравнения файлов, такой как Beyond Compare, KDiff, WinDIFF, DiffMerge и т. д., чтобы создать объединенный набор определений ролей. Затем импортируйте объединенный набор с помощью диспетчера ролей.
Скрытень №6:
Существо из лагуны IQueryable
Те, кто перейдет с Sitecore 6.x на Sitecore 8, столкнутся с тем же препятствием, с которым столкнулись те, кто перешел на Sitecore 7: новое пространство имен Sitecore.ContentSearch. То, как сейчас работает индексация и поиск контента, сильно отличается и намного лучше, чем в предшественнике, но это означает, что вам нужно будет обновить свой код для работы с новой моделью. Вам нужно будет запланировать изменение этого кода и добавление новых конфигураций для повторного создания ваших индексов. Эта статья отлично подходит для начала работы с новым пространством имен поиска.
Скрытень №7:
Восстание модулей
При обновлении любой версии вы должны проверять свои модули на совместимость, но, в частности, Sitecore 8 сделает это необходимым. Многие модули Marketplace не были обновлены для Sitecore 8, а некоторые модули теперь заменены функциями OOTB (например, Experience Explorer и FXM). Перед обновлением определите, действительно ли вы используете модуль. Если нет, просто удалите его. Если вы его используете, определите, какие функции предоставляет вам модуль, и проконсультируйтесь со своим партнером Sitecore, чтобы узнать, может ли Sitecore 8 или альтернативный модуль предоставить вам те же функции.
