Где создавать статьи в Sitecore?

Я не согласен с Мареком и рекомендую вам выбрать вариант 2.

Хранение ваших статей в папке под узлом данных позволяет использовать эти элементы в качестве источника данных. Это принцип, на котором был построен Sitecore. Затем вы можете отображать эти статьи несколькими интересными способами с помощью виджетов, таких как рекламные панели, предлагая пользователю щелкнуть, чтобы прочитать о статье, не дублируя ее данные и не требуя, чтобы редакторы контента управляли данными несколько раз.

Он даже поддерживает несколько сайтов, поэтому статьи можно использовать на других сайтах, которые вы можете добавить в свой экземпляр Sitecore в будущем.

Как вы заявляете, это потребует дополнительной работы с точки зрения URL-адресов и навигации, но этого можно достичь с помощью элемента подстановочной карты Sitecore, и вы даже можете использовать отличный модуль с открытым исходным кодом из Sitecore Marketplace, чтобы выполнить 90% работы за вас. См. ссылки ниже для получения дополнительной информации.

Вы по-прежнему можете реализовать идею Марека о применении сведений о презентации один раз к стандартным значениям создаваемого вами элемента «дикой корзины». Если вы используете Sitecore 7 и выше, вы можете хранить все свои статьи в корзине, поэтому, если у вас много статей, они хранятся и доступны для поиска осмысленным образом.

• http://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2011/09/wildcards-and-data-driven-urls.aspx
• https://marketplace.sitecore.net/en/Modules/Wildcard_module.aspx

В стандартной настройке одного экземпляра самой простой реализацией является создание статей в виде страниц.

В Sitecore вы хотите ограничить количество элементов в папке до 100 или менее, что является наилучшей практикой для обеспечения оптимальной работы редакторов контента.

Это приводит к тому, что вам нужна структура папок и пара опций:

1. Вручную поддерживайте структуру папок для своих статей. Например статьи/год/месяц/день. Это дает вашим редакторам максимальный контроль над структурой папок и позволяет им перемещаться по статьям более традиционным способом через видимую структуру папок.

2. Используйте ведро, которое автоматически создает структуру папок и скрывает эту сложность от редактора контента. Это избавляет редактор контента от ручного создания и обслуживания папок и создает их автоматически на основе конфигурации, которую вы установили для своей корзины. Папки не будут видны редактору контента, поэтому они будут вынуждены искать любые статьи в корзине, а не перемещаться по папкам.

3. Используйте модуль перемещения новостей с общим источником (https://marketplace.sitecore.net/en/Modules/News_mover.aspx). Это требует другого подхода к вышеизложенному. Он работает через традиционную структуру папок, однако создает папки и перемещает элемент при сохранении на основе поля даты в статье. Таким образом, средство перемещения новостей обрабатывает создание папок, однако вам все равно нужно будет снова проверить не более 100 элементов в папке для производительности при открытии папок с большим количеством элементов.

Со всеми решениями вы все равно должны учитывать URL-адреса для своих статей, поскольку по умолчанию они будут включать структуру папок. Это не всегда приемлемо. Я предпочитаю удалять структуру папок из URL. Для этого вам нужно создать собственный linkProvider и собственный HttpRequestProcessor. Во-первых, поставщик ссылок позволяет вам гарантировать, что новый URL-адрес всегда создается и отображается на вашем сайте так, как вы хотите. Затем HttpRequestProcessor гарантирует, что при переходе по сокращенному URL-адресу Sitecore распознает его как действительный URL-адрес и представляет правильную страницу.

Исключение структуры папок из URL-адреса также добавляет дополнительное преимущество, заключающееся в том, что URL-адрес не зависит от структуры. Это означает, что редакторы могут изменить структуру этой папки, и им не нужно создавать элементы перенаправления, чтобы гарантировать, что рейтинг SEO или закладки пользователей не будут потеряны.

Более чистая модель данных заключается в использовании подхода с подстановочными знаками для URL-адресов и централизованном хранении данных статей в группе источников данных. Это обеспечит оптимальную производительность и повторное использование данных.

Однако это не то, как автор думает о своем веб-сайте. Когда они используют систему, они, как правило, переходят в область, где они будут просматривать статьи, и пытаются создать там новую. Авторы склонны мыслить «страницами», поэтому постарайтесь скрыть от них любую модель данных, которую вы используете, и дайте им возможность редактировать страницу с помощью редактора опыта.

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

Я рекомендую использовать постраничный подход, при котором автор создает структуру URL с папками и элементами, которые он понимает. Затем, если вам действительно нужно, вы можете сделать первичные данные статьи компонентом на странице, управляемым источником данных. Пользователь может использовать все инструменты, с которыми он знаком (редактор опыта, предварительная навигация), но вы по-прежнему можете хранить необработанные данные в централизованной папке. Затем вы теоретически можете поменять местами данные статьи, используя правила DMS, или скрыть информацию на основе аутентификации или статуса членства.

Используйте подход 1: статья — это страница.

Определите все детали презентации в Article Page шаблоне __Standard Values. Все новые статьи получат их. И вы можете изменить некоторые детали презентации для выбранных вами статей, если хотите.

Если вы знаете, что у вас будет много статей, подумайте о year/month/day структуре папок, например. articles/2015/06/12.

Подход 2 ничего вам не дает — вам все равно нужно иметь элемент для каждой статьи. И, как вы написали, это потребует дополнительного кодирования, которое не требуется.