====== Поддержка стандартного поведения Publishing Container ======

=====  Автоматическая замена плейсхолдеров ===== 
Поддержка стандартного поведения Publishing Container ([[edit:url_auto_replace|подробнее]]) Замена плейсхолдеров ''<%=site_url%>'' и ''<%=upload_url%>'' производится для полей типа //String//, //VisualEdit// и //Textbox//. Замена работает в обе стороны, как при загрузке, так и при сохранении. Включение этого механизма производится на [[developer:linq:db_mapping|уровне сайта]]. Там же можно модифицировать поведение механизма замены так, что плейсхолдеры будут заменяться на абсолютные URL, а не на относительные.

===== Фильтрация по умолчанию =====

По умолчанию Publishing Container фильтрует статьи следующим образом. На live-версии выводятся статьи, которые:
  - Видимы (VISIBLE = 1, флаг управляется расписанием показа)
  - Не находятся в архиве (ARCHIVE = 0)
  - Имеют максимальный статус по Workflow (в большинстве цепочек Workflow и если Workflow не назначено -- STATUS_TYPE_ID = ID статуса Published текущего сайта).

Stage-версия отличается тем, что на ней применяются только первые два условия.


В текущей версии данное поведение для LINQ-to-SQL классов настраивается через включение опции **Использовать фильтрацию по умолчанию** (**Use default filtration**) настраивается [[:content|на уровне контента]]. При включенной опции LINQ-to-SQL класс отображается не на таблицу CONTENT_NNN, а на представление CONTENT_NNN_LIVE (для stage-режима используется аналогичное представление CONTENT_NNN_STAGE вместо CONTENT_NNN_UNITED). Единственное отличие от //Publishing Container// в том, что фильтрация по статусу всегда осуществляется по //Published//, таким образом не поддерживаются цепочки Workflow, у которых максимальный статус не //Published//.


В предыдущих версиях функциональность реализовывалась через вызов метода расширения **ForFrontEnd()**. В текущей версии метод оставлен для обратной совместимости, но в случае включенной фильтрации по умолчанию никаких действий не выполняет.


Если генерируемые LINQ-to-SQL классы не используются непосредственно на сайте в папке //App_Code//, а сначала включаются в некий проект в Visual Studio, то для организации live- и stage- версий сайта имеет смысл воспользоваться режимом генерации, независимым от БД, который настраивается на [[developer:linq:db_mapping|уровне сайта]]. В этом случае один и тот же код можно использовать и на live-, и на stage-версии, они будут отличаться только .map-файлом привязки. При такой организации кода потребуется только задать для stage-версии параметр //isLive// равный //false// в секции //appSettings// файла //web.config// (для live-версии параметр можно не задавать, либо он должен быть равен //true//).