Pdoresources документация: Документация по MODX pdoResources и примеры вывода ресурсов.

Содержание

Примеры использования | Документация | Зона разработки

Во всех примерах используется библиотека pdoTools, которая, по моему скромному мнению, является обязательным дополнением.

1. Вывод списка ресурсов с сортировкой по количеству просмотров


[[!pdoResources?
    &tpl=`article.tpl`
    &loadModels=`sitestatistics`
    &leftJoin=`{
        "Statistics": {
            "class": "PageStatistics",
            "on": "modResource.id = Statistics.rid"
        }
    }`
    &select=`{
        "modResource": "*",
        "Statistics": "IFNULL(SUM(views),0) as views, COUNT(DISTINCT user_key) as users"
    }`
    &groupby=`modResource.id`
    &sortby=`views` // `users` для сортировки по посещениям
]]

Соответственно в чанке можно использовать плейсхолдеры [[+views]] и [[+users]]. Выглядеть это будет приблизительно так

2. Тоже самое, только для mFilter


[[!mFilter2?
    &class=`msProduct`
    &element=`msProducts`
    &loadModels=`sitestatistics`
    &leftJoin=`{
        "Statistics":{"class":"PageStatistics","on":"msProduct.id=Statistics.rid"}
    }`
    &select=`{
        "msProduct": "*",
        "Statistics": "IFNULL(SUM(views),0) as views, COUNT(DISTINCT user_key) as users"
    }`
    &groupby=`msProduct.id`
    &sortby=`views`
]]

3. Пример вывода ресурсов, у которых referer содержит строку «google.ru», т.е. на которые заходили с гугла.


[[!pdoResources?
    &parents=`0`
    &tpl=`@INLINE <p>Заголовок "[[+pagetitle]]". Создан {{+createdon:date=`%d.%m.%Y`}}</p>`
    &loadModels=`sitestatistics`
    &where=`["modResource.id IN (SELECT DISTINCT Statistics.rid FROM `modx_stat_page_statistics` AS `Statistics` INNER JOIN `modx_stat_online_users` `StatUser` ON StatUser.user_key = Statistics.user_key and StatUser.referer LIKE '%google.ru%')"]`
]]

4. Пример вывода недавно просмотренных страниц текущего пользователя.


[[!pdoResources?
    &parents=`0`
    &tpl=`@INLINE <p>[[+pagetitle]].</p>`
    &loadModels=`sitestatistics`
    &innerJoin=`{
        "Statistics":{"class":"PageStatistics","on":"modResource.id=Statistics.rid"}
    }`
    &select=`DISTINCT modResource.pagetitle`
    &where=`{"Statistics.user_key": "[[+sitestatistics.userKey]]"}`
    &sortby=`Statistics.date`
    &limit=`5`
]]

Можно ограничить периодом. Для этого нужно немного изменить условие


//1. Просмотренные пользователем ресурсы за текущий день
&where=`["Statistics.user_key = '[[+sitestatistics.userKey]]' AND Statistics.date = CURDATE()"]`
//2. Просмотренные пользователем ресурсы за конкретный день
&where=`["Statistics.user_key = '[[+sitestatistics.userKey]]' AND Statistics.date = '2016-03-05'"]`
//3. Просмотренные пользователем ресурсы за январь
&where=`["Statistics.user_key = '[[+sitestatistics.userKey]]' AND Statistics.month = '2016-01'"]`
//4. Просмотренные пользователем ресурсы за год
&where=`["Statistics.user_key = '[[+sitestatistics.userKey]]' AND Statistics.year = 2016"]`
//5. Просмотренные пользователем ресурсы за период
&where=`["Statistics.user_key = '[[+sitestatistics.userKey]]' AND Statistics.date BETWEEN '2016-01-01' and '2016-03-31' "]`
//6. Просмотренные пользователем ресурсы за последние 7 дней
&where=`["Statistics.user_key = '[[+sitestatistics.userKey]]' AND Statistics.date >= DATE_SUB(CURDATE(),INTERVAL 7 DAY)"]`

5. Вывод статистики по пользователям за указанный период


[[!pdoUsers?
    &tpl=`@INLINE <p>[[+username]] - [[+views]].</p>`
    &loadModels=`sitestatistics`
    &innerJoin=`{
        "UserStat":{"class":"UserStatistics","on":"modUser.id=UserStat.uid"},
        "PageStat":{"class":"PageStatistics","on":"UserStat.user_key=PageStat.user_key"}
    }`
    &select=`{
        "PageStat": "SUM(PageStat.views) as views"
    }`
    &groupby=`UserStat.uid`
    &where=`["PageStat.date BETWEEN '2016-01-01' and '2016-01-31'"]`
]]

Если нужно вывести статистику только для текущего пользователя, то указываем его в where


&where=`["UserStat.uid = [[+modx.user.id]] AND PageStat.date BETWEEN '2016-01-01' and '2016-01-31'"]`

Шпаргалка по Fenom | BUSTEP.RU

Описание по подключению плейсхолдеров на страницу

информация с официальной документации pdotools

MODXFenomОписание
[[+pagetitle]]{$pagetitle}Заголовок
[[*pagetitle]]{$modx->resource->pagetitle}Заголовок
[[%lexicon]]{$modx->lexicon(‘lexicon’)}вывод словарей
[[~[[+id]]]]{$modx->makeUrl($id)}укл на страницу
[[++site_url]]{$modx->config.site_url}настройки modx
[[$chunkName]]{$pdoTools->getChunk(‘chunkName’)} или {include ‘chunkName’}чанк
[[!snippetName]]{$modx->runSnippet(«pdoResources», [‘parents’ => 0])}сниппет
[[*id:is=`1`:then=``:else=``]]{if $id = 1}{else}{/if}if else
[[+pagetitle:modificator]]{$pagetitle | modificator}модификатор
[[+pagetitle:modificator]]{$_modx->placeholders}массив с системными плейсхолдерами

Другие параметры

FenomОписание
{$_modx->placeholders}массив с системными плейсхолдерами
{$_modx->config}массив с системными настройками
{$_modx->context}массив (не объект!) с текущим контекстом
{$_modx->user}массив (не объект!) с текущим пользователем
{$_modx->resource}массив (не объект!) с текущим ресурсом
{$_modx->lexicon}служба загрузки лексиконов
{$_modx->lexicon()}функция для вывода строки из лексикона
{$_modx->runSnippet()}запуск сниппета
{$_modx->runProcessor()}запуск процессора
{$_modx->getChunk()}вывод чанка
{$_modx->runSnippet(‘!pdoResources’)}не кэшируемый
{$.get.test}GET
{$.post.test}POST
{$date|date:»Y»}текущий год
{55|url}Ссылка на документ

Модификаторы MODX FENOM

FenomОписание
{$date| date: «Y»}текущий год
{55| url}Ссылка на ресурс

Подключение наборов параметров

FenomОписание
{$_modx->getChunk(‘Name@PropertySet’)}для чанка
{include ‘Name@PropertySet’}
{$_modx->runSnippet(‘NameName@PropertySet’)}для сниппетов
{include ‘template:TemplateName@PropertySet’}

Подключение шаблона

FenomОписание
{include ‘template:имя шаблона’}подключение шаблока
{include ‘имя чанка’}подключение чанка
{include ‘имя чанка’}подключение чанка
{block ‘content’}контект{/block}расcтановка блоков
{extends ‘file:templates/base.tpl’}наследование шаблона

Примеры работы

    // загрукзка ресурсов
    {$_modx->runSnippet('pdoResources', [
        'parents' => 19,
        'depth' => 0,
        'where' => ['isfolder' => 0],
        'showLog' => 1,
    ])}

    // загрукзка меню
    {$_modx->runSnippet('pdoMenu', [
        'parents' => 0,
        'level' => 2
    ])}

    <p>
    {$_modx->lexicon->load('ms2gallery:default')}
        Проверка словарей ms2Gallery: {$_modx->lexicon('ms2gallery_err_gallery_exists')}
    </p>

    <p>
    {if $_modx->isAuthenticated('web')}
        Привет, {$_modx->user.fullname}!
    {else}
        Вам нужно авторизоваться =(
    {/if}
    </p>
    <p>Текущий контекст: {$_modx->context.key}</p>

Создание значения из переменной с добавление префикса

{set $lexicon = "ms2_product_{$field}"}
{('ms2_product_' ~ $name) | lexicon}

Тег foreach предоставляет простой способ перебора массивов.
Foreach работает только с массивами, объектами и интервалами.

{foreach $list [as [$key =>] $value] [index=$index] [first=$first] [last=$last]}
   {* ...code... *}
   {break}
   {* ...code... *}
   {continue}
   {* ...code... *}
{foreachelse}
   {* ...code... *}
{/foreach}

{foreach}

Перебор значений массива $list:

{foreach $list as $value}
 <div>{$value}</div>
{/foreach}

{foreach 1..7 as $value} {* так же хорошо работает и с интервалами *}
 <div>№{$value}</div>
{/foreach}

Перебор ключей и значений массива $list:

{foreach $list as $key => $value}
 <div>{$key}: {$value}</div>
{/foreach}

Получение номера (индекса) итерации, начиная с 0

{foreach $list as $value}
 <div>№{$value@index}: {$value}</div>
{/foreach}

или

{foreach $list as $value index=$index}
 <div>№{$index}: {$value}</div>
{/foreach}

Определение первой итерации:

{foreach $list as $value}
 <div>{if $value@first} first item {/if} {$value}</div>
{/foreach}

или

{foreach $list as $value first=$first}
 <div>{if $first} first item {/if} {$value}</div>
{/foreach}

Переменная $value@first будет иметь значение TRUE, если текущая итерация является первой.
Определение последней интерации:

{foreach $list as $value}
 <div>{if $value@last} last item {/if} {$value}</div>
{/foreach}

или

{foreach $list as $value last=$last}
 <div>{if $last} last item {/if} {$value}</div>
{/foreach}

Переменная $value:last будет иметь значение TRUE, если текущая итерация является последней.

Замечание:
Использование last требует от $list быть countable.

{break}

Тег {break} используется для выхода из цикла до достижения последней итерации.
Если в цикле встречается тег {break}, цикл завершает свою работу, и далее, выполняется код, следующий сразу за блоком цикла

{continue}

Тег {continue} используется для прерывания текущей итерации.
Если в цикле встречается тег {continue}, часть цикла, следующая после тега, не выполняется, и начинается следующая итерация.
Если текущая итерация была последней, цикл завершается.

{foreachelse}

Тег {foreachelse} ограничивает код, который должен быть выполнен, если итерируемый объект пуст.

{var $list = []}
{foreach $list as $value}
 <div>{if $last} last item {/if} {$value}</div>
{foreachelse}
 <div>empty</div>
{/foreach}

В блоке {foreachelse}...{/foreach} использование {break}, {continue} выбросит исключение Fenom\CompileException при компиляции

08 февраля 2019, 09:10    22249

pdoTools / Утилиты / Дополнения MODX / modstore.pro

Внимание, этот компонент требует версию PHP
5.6
или выше!
Если ваш сайт использует PHP ниже требуемого, установка этого
дополнения может его сломать.

Внимание, этот компонент требует версию MODX не ниже
2.3
!

pdoTools — это набор удобных сниппетов для повседневной работы + небольшая библиотека, которая делает их очень быстрыми.

Благодаря использованию общей библиотеки, все сниппеты pdoTools обладают единым минимальным функционалом:

  • Все запросы в БД работают через PDO. Объекты xPDO не создаются, только если они действительно не нужны.
  • Предварительная обработка простых плейсхолдеров в чанках. Парсер MODX разбирается только со сложными вызовами.
  • Правильная сортировка, подготовка, обработка и вывод ТВ параметров.
  • Код чанков можно указывать прямо при вызове сниппета, загружать обычным образом или из статичных файлов.
  • «Быстрые плейсхолдеры» в чанках, которые заменяют фильтры типа «isempty» и оборачивают значения в теги только если те не пусты.
  • Ведение подробного журнала работы сниппета с отметками времени, для отладки.

Все запросы строятся на xPDO, выборка производится через PDO для экономии ресурсов и скорости.

В состав входят:

  • pdoResources — Очень быстрая замена для getResources, совместимая по параметрам.
  • pdoMenu — Замена для Wayfinder, строит меню.
  • pdoUsers — Выборка и вывод пользователей сайта, с фильтрацией по ролям и группам.
  • pdoCrumbs — Хлебные крошки, замена BreadCrumb.
  • pdoSitemap — Быстрая генерация карты сайта, замена GoogleSiteMap.
  • pdoNeighbors — Вывод ссылок на соседние документы.
  • pdoField — Вывод любого поля документа, замена getResourceField и UltimateParent.
  • pdoPage — Постраничный вывод результатов, замена getPage.

Основные возможности

— Любые выборки, из любых таблиц с любыми условиями и джоинами.
— Учет времени на каждую операцию, подробный лог для выявления узких мест.
— Полная совместимость с getPage для постраничного вывода результатов.
— Самый быстрый процессинг чанков, быстрее только вообще без них.
— Встроенный шаблонизатор Fenom в версии 2.0

Как сделать 3х уровневое меню c разными стилями через PdoResources и PdoMenu в MODX? — Хабр Q&A

Есть вот такое меню.

Скрин:

Хочу сделать его автоматизацию в MODX.
В меню 1-го уровня: 1-ая ссылка (Главная) и 2-ая ссылка (сам Каталог) имеют свои стили.
В меню второго уровня: стили Родителя 2-го уровня отличаются от стилей Родителя 1-го уровня.
Сам пункты 2-го, 3-го уровня тоже отличны от пунктов 1-го уровня меню.

<ul>
				<li><a href=""><span></span><i>Главная</i></a></li>
				<li>
					<a href=""><span><span></span><span></span><span></span></span>Каталог</a>

					<ul>
						<li><a href="">Товар номер - 1</a></li>
						<li>
							<a href="">Товар номер - 2</a>
							<ul>
								<li><a href="">Товар номер - 2.1</a></li>
								<li><a href="">Товар номер - 2.2</a></li>
								<li><a href="">Товар номер - 2.3</a></li>
							</ul>
						</li>
						<li><a href="">Товар номер - 3</a></li>
						<li><a href="">Товар номер - 4</a></li>
						<li>
							<a href="">Товар номер - 5</a>
							<ul>
								<li><a href="#">Товар номер - 5.1</a></li>
								<li><a href="#">Товар номер - 5.2</a></li>
								<li><a href="#">Товар номер - 5.3</a></li>
							</ul>
						</li>
					</ul>
				</li>
				<li><a href="">Контакты</a></li>
				<li><a href="">О нас</a></li>
				<li><a href="">Цены</a></li>
				<li><a href="">Доставка</a></li>
				<li><a href="">Оплата</a></li>
			</ul>

Как правильно реализовать такую конструкцию через PdoResources?

[[pdoResources?
…
]]

[[pdoMenu?
…
]]

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

Создаём поиск по сайту на MODX Revo при помощи компонента mSearch

Почти любой сайт должен иметь такой функционал как поиск. Во всех CMS есть для этого дополнения или компоненты, не стал исключением и MODX Revo. Самым популярным пакетом в MODX для этих целей является «SimpleSearch». Несмотря на это мы воспользуеся другим компонентом — «mSearch». Его преимущество заключается в учитывании при поиске морфологии русского языка, а так же в повышенной скорости работы.



К сожалению, у этого пакета есть и недостатки:


  • Во-первых, его нет в официальном репозитории MODX. Тем не менее, его можно без проблем найти через поисковые системы, либо скачать по этой ссылке.

  • Во-вторых, автор прекратил его поддержку, переписал компонент заново, назвал его «mSearch3» и теперь он платный. Тем не менее, я настроил старую версию и она прекрасно работает.

  • В-третьих, у него есть проблемы с выводом TV параметров при выдаче результатов, но мы обойдём это хитрым способом.

Создание страницы для вывода результатов поиска в MODX


Устанавливаем дополнения «mSearch» и «pdoTools». Второе дополнение есть в официальном репозитории MODX. Из него нам потребуется сниппет «pdoResources», хотя вполне можно вместо него использовать и «getResources». Это на ваше усмотрение.


Затем создадим страницу (ресурс), которая будет отвечать за вывод результатов поиска. Шаблон для этого ресурса в большинстве случаев подходит стандартный, требование одно — основное место в нём должно выделяться под содержимое ресурса. В содержимом страницы вызываем сниппет «pdoResources», в параметре к которому передаём id найденных ресурсов сниппетом «mSearch»:




Результаты поиска по запросу: [[+mse.query]] ([[+total]])

    [[!pdoResources?
		&parents=`0`
		&resources=`[[!mSearch? &templates=`4` &returnIds=`1`]]`
		&limit=`15`
		&includeTVs=`img-news,tags,HitsPage`
		&tpl=`articleTpl`
	]]

[[+mse.error]]


В этом примере мы немного извратились. По идее, сам сниппет поиска может выводить результаты, но на деле он некорректно отображает связанные с ресурсом TV параметры. Точнее он их отображает только для первого найденного ресурса. Чтобы обойти это мы настроили «mSearch» так, чтобы он выдал только id найденных ресурсов, а их вывод и оформление мы осуществляем через «pdoResources».


Используемые плейсхолдеры и параметры:


  • [[+mse.query]] — плейсхолдер выводит строку запроса.

  • [[+total]] — выводит количество найденых ресурсов.

  • [[+mse.error]] — выводит ошибки, например при отсутствии найденных ресурсов выведет об этом сообщение.

  • &templates=`4` — параметр задаёт поиск только среди ресурсов с этими номерами шаблонов, через запятую. Если требуется искать по всему сайту, указываем все шаблоны. Так же вместо этого параметра можно использовать &parents, в котором потребуется указать список ресурсов-родителей, в которых будет производиться поиск.

  • &returnIds=`1` — указывает на то, что требуется вернуть id найденных страниц.

  • &tpl=`articleTpl` — параметр сниппета «pdoResources» — указывает чанк для оформления результата вывода одной страницы. В нём можно вывести название ресурса, TV параметры и.т.п. Например:



<div >
	<img src="[[+tv.img-news]]" alt="[[+tv.tags]]">
	<a href="[[++site_url]][[~[[+id]]]]">[[+pagetitle]]</a>
	<p>[[+description]] ...</p>
</div>


Создание формы поиска


Осталось передать созданной странице параметр, через который сниппет «mSearch» узнает, что именно надо искать. Для этого в любом месте сайта располагаем следующий код:



<form  action="[[++site_url]][[~20]]" method="GET">
	<input type="text" name="query" maxlength="40" value="" placeholder="Найти" /> 
	<input type="submit" value="Найти" />
</form>


Как вы наверно догадались, [[~20]] это id страницы, которую мы создали на предыдущем шаге. Вся задача этой формы — отправить ей методом «GET» или «POST» параметр «query». Можно приступать к тестированию, так как основная часть поиска на MODX закончена.


Вывод результатов с постраничной пагинацией


Если в выдаче очень много ресурсов, то целесообразно использовать постраничный вывод. Для этого можно использовать сниппет «getPage» или «pdoPage». Последний входит в состав дополнения «pdoTools», поэтому пример именно с ним:



[[!pdoPage? 
	&elementClass=`modSnippet` 
	&element=`pdoResources` 
	&parents=`0` 
	&resources=`[[!mSearch? &templates=`4` &returnIds=`1`]]` 
	&limit=`5` 
	&includeTVs=`img-news,tags,HitsPage`
	&tpl=`articleTpl`
]]

<div>
	[[!+page.nav]]
</div>


Форма поиска должна обязательно передавать параметр «query» методом «GET».

Как вывести контент в ModX Revolution с помощью GetResources

Что такое getResources?

getResources это сниппет MODX Revolution, который извлекает содержимое полей из других ресурсов и выводит его в любом удобном для вас виде. Если вы знакомы MODX Evolution, getResources может считаться заменой Ditto.

Почему нужно использовать именно getResources?

getResources отлично подходит для случаев, где вам необходимо объединить и вывести информацию от различных ресурсов в одном месте и в необходимом формате. Наиболее очевидным применением сниппета getResources будет создание основной блоговой страницы сайта, другие возможные блоки использования — слайдеры, страница портфолио, новостная лента…

Как использовать сниппет getResources?

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

  • Для начала установите сниппет getResources
  • Далее необходимо решить как структурировать страницы, контент которых мы собираемся вывести и какой будет шаблон вывода страниц. Всё будет отличаться в зависимости от структуры вашего сайта и целей. Вы можете выводить отдельные страницы на вашем дереве сайтов либо размещать дочерние страницы в контейнере и использовать ИД контейнера, чтобы их вывести и др.
  • Определиться какие поля будут показаны на выведенной странице. Вы можете, например, показать только список заголовков на вашем сайдбаре или показать только заголовок страницы и содержание, либо показать несколько полей и переменных шаблона, и т.д.
  • Если у вас еще нет шаблона, то создайте шаблон для вашей странице вывода контента.
  • Сделайте простой вызов getResources чтобы убедиться в том, что контент извлекается и выводится.
  • Создайте чанк-шаблон для вывода полей, которые вы будете показывать на вашей странице.
  • Добавьте нужные параметры в вызове сниппета getResources

Я детально и последовательно опишу каждый из описанных выше шагов. Если вы уже разбираетесь в построении шаблонов и разбираетесь в переменных шаблона и других вопросах шаблонизации, то можете смело переходить прямо к 5 шагу.

1. Установка getResources

Я уже установил getResources и мы будем его использовать для создания страницы статьи. Мы будем использовать для шаблона страницы блога шаблон 7 in 1 Business Success Site студии Themeforest. Страница блога (частично) будет выглядеть следующим образом:

Как видите, у нас есть страница с несколькими компонентами – заголовок, изображение, дата публикации, изображение и отрывок содержания со ссылкой “читать остальную часть записи” к целому посту. Этот шаблон мы будем использовать для объединённого вывода наших статей.

2.Подготовьте шаблон для вывода отдельной статьи:

После установки сниппета getResources, смотрим на оформить стуктуру страниц отдельного вывода статей. Для этого я буду использовать шаблон отдельного поста нашей темы, который я взял из файла single.html.  Я уже портировал данный шаблон в свой шаблон и назвал его “7in1 Single Article”.  Вот как мой “7in1 Single Article” шаблон будет выглядеть:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US"> <head profile="http://gmpg.org/xfn/11"> [[$7in1-header]] </head> <body> [[$7in1-logo-nav-search-bar]] <div></div> <div> <div> <div> <div> <div> <div> <span>[[*publishedon:strtotime:date=`%d`]]</span> <span>[[*publishedon:strtotime:date=`%b`]]</span> <span>[[*publishedon:strtotime:date=`%Y`]]</span> </div> <h4><a href="[[~[[*id]]]]" rel="bookmark" title="Permanent Link to [[*pagetitle]]">[[*pagetitle]]</a></h4> </div> <div> <p><a href="[[*id]]"><img title="[[*article_image_title]]" src="[[*article_image]]" alt="" /></a> [[*content]] <div>Tags: <a href="#" rel="tag">tag3</a>, <a href="#" rel="tag">tag5</a>, <a href="#" rel="tag">tag7</a><br /> Posted in <a href="#" title="View all posts in Latest News" rel="category">Latest News</a> | <a href="#comments" title="Comment on Blog Post 5">6 Comments &#187;</a></div> </div> </div> [[$articleCommentStuff_temp]] </div> <!-- end post_content --> [[$7in1-articles-sidebar]] </div> <!-- end container_bkgnd_btm --> </div> <!-- end page_container --> <div></div> <div> </div> [[$7in1-bottomwidgets]] <div> </div> [[$7in1-footer]] </body> </html>

Вы узнаете чанки шапки и подвала, мы уже их использовали, я добавил всего лишь два дополнительных чанка, один для содержимого сайдбара (7in1-articles-sidebar) и одного временного чанка (articleCommentStuff_temp) для секции комментирования, чтобы не нагромождать все элементы. В данный момент эти два чанка содержат статический контент нашего шаблона, но в следующий уроках мы сделаем их динамичными. Так же я добавил две дополнительных переменных шаблона, одну для вывода текста в теге изображения (article_image_title) и другую для самого изображения (article_image – {тип ввода – изображение, тип вывода – текст}).  Также я добавил другие поля, такие как ИД поста, урлы и др., многое из этого должно быть вам понятно из предыдущих уроков.

Последним моментом, на который я хотел обратить ваше внимание —  вывод поля даты. Он производится через publishedon используя при этом функцию PHP strtotime для показа даты в необходимом виде (как в шаблоне нашей темы). Более детально про функцию strtotime и форматирование дат — в конце этого поста ссылки.

Как я уже говорил, содержимое сайдбаров, теги и секция комментариев – статичны и мы над этим вопросом поработаем в следующих уроках.

3. Добавьте статьи

Отлично, теперь у нас есть шаблон для отдельных страниц и можно двигаться дальше. Создадим несколько статей для нашего сайта, используя этот шаблон, таким образом мы сможем проверить наш вызов getResources.  В моём случае я создал контейнер Articles и установил шаблон для него Base Template, который я поменяю позже, когда буду готов выводить объединённый контент. Всередине я размещу парочку контейнеров для каждой категории или темы, которую покрывают мои статьи… например – новости, MODX уроки и др.

Размышляя об этом, я понимаю, что не хочу, чтобы мои статьи выводились в меню, также я хочу, чтобы они все использовали шаблон 7in1 Single Article. В рассуждениях о том, как же лучше сделать легче мою работу или работу клиента, я решил, что так как большинство новых ресурсов будут статьями, то есть здравый смысл в том, чтобы сделать соответствующими настройки по умолчанию для типа содержимого. Другими словами, сделайте все новые ресурсы с этого момента по умолчанию использующими шаблон 7in1 Single Article, а также они должны быть скрытыми от меню. Конечно же, можно отредактировать один за одним все ресурсы и это не будет проблемой, так как остальные мои страницы уже созданы и большинство новых ресурсов буду статьями. Итак, чтобы сделать это, идём System->System Settings, далее фильтр « area» и выбираем “Site”.  Нужные настройки – Default Template, Hide from Menus Default.

 

После внесения изменений наблюдаем такую картину:

 

Теперь, при создании нового ресурса, он берёт шаблон отдельной статьи по умолчанию и уже поставлена галочка в Скрыть от меню (Hide From Menus).

Заметка: Обратите внимание, что такое поведение будет в случае, когда документ создаётся в корне. Если же вы зайдёте в любой контейнер и нажмёте «Создать документ здесь» (Create a Document Here), то он возмёт шаблон контейнера и скроет от меню. Поэтому будьте внимательны к настройкам каждого ресурса.

Давайте продолжим и создадим около 8 простых статей для нашего сайта, чтобы сниппет мог их объединить и вывести getResources. Я беру сгенерированный текст отсюда http://www.malevole.com/mv/misc/text/ и произовальные картинки из Гугла.  Позже при наличии времени я заменю этот текст другим необходимым, здесь же в целях обучения будет достаточно наличия любого текста и картинок. Вот как выглядит дерево моего сайта в данный момент:

 

Теперь можно перейти к следующему этапу, который состоит в том, что мы созданим шаблон для нашей основной страницы блога и далее сформируем вызов сниппета getResources.

4. Подготовка страницы агрегированного контента.

Если вы используете тот же шаблон, что и я, то посмотрите на код и вы увидите, что он почти не отличается от кода для обычного шаблона, но без секции комментирования и других аналогичных элементов, поэтому можно использовать те же чанки и код, что мы использовали ранее. Вот как будет выглядеть шаблон 7in1 Aggregated Articles:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US"> <head profile="http://gmpg.org/xfn/11"> [[$7in1-header]] </head> <body> [[$7in1-logo-nav-search-bar]] <div></div> <div> <div> <div> [[*content]] </div> <!-- end post_content --> [[$7in1-articles-sidebar]] </div> <!-- end container_bkgnd_btm --> </div> <!-- end page_container --> <div></div> <div> </div> [[$7in1-bottomwidgets]] <div> </div> [[$7in1-footer]] </body> </html>

Теперь я использую данный шаблон для вывода содержимого ресурсов — дочерних элементов следующих контейнеров – контейнер Articles и каждого из контейнеров для категорий, в моём случае — MODX News, MODX Web Development, MODX Tips and Tricks и Other Stuff.  Теперь одна из категорий будет выглядить приблизительно так:

 

Давайте перейдём к выводу нашего контента.

5. Базовый вызов сниппета getResources

Перед тем, как мы начнём формировать вызов сниппета и работать с getResources, важно познакомится с несколькими вещами, которые могут легко ввести в заблуждение, если вы до этого не были знакомы с getResources и даже если вы знакомы. Я называю их мои getResources уловки!

  • Вызов getResources по-умолчанию не содержит шаблона вывода. Вам необходим шаблон — tpl-чанк, чтобы определить вывод содержимого ресурса (ресурсов).
  • getResources по-умолчанию не покажет ресурсы, которые скрыты от меню, поэтому вам необходимо задать &showHidden=`1`
  • getResources по-умолчанию не включит поля содержимого ваших ресурсов, поэтому вам необходимо задать &includeContent=`1`
  • В дополнение, если даже вы установите includeContent, сниппет getResources по-умолчанию не включит переменные шаблона, поэтому вам необходимо задать &includeTVs=`1` и &processTVs=`1`
  • Если вы зададите includeTVs и processTVs, сниппет getResources будет ожидать, что в вашем шаблоне tpl,  вы будете обозначать ваши переменные шаблона префиксом “tv.”. Вы можете перезаписать это добавив &tvPrefix=` ` и далее использовать только лишь имя переменной шаблона как заполнитель.
  • Если вы выводите необходимые ресурсы через параметр &resources=`1,2,3`, где 1,2,3 — выводимые ресурсы, то не забудьте обязательно указать параметр &parents=`-1`

Есть еще много моментов, но это основные, в которых легко допустить ошибку.

Как и у всех других сниппетов, вызов getResources выглядит так:

[[!getResources]]

Базовый вызов позволит вам убедиться в том, что сниппет работает на нашем сайте. Если я размещу данный вызов на странице Articles page я ничего не получу. Вы можете подумать, что происходит что-то неправильное, но этому есть простое объяснение. Помните наш список находок? По умолчанию getResources ожидает, что ваши ресурсы не будут скрыты от меню, поэтому если вы хотите показать скрытые ресурсы вам необходимо добавить параметр &showHidden и установить его значение в true. Поэтому отредактируйте ваш вызов:

[[!getResources? &showHidden=`1` ]]

Если я перегружу страницу, то вот что я получу:

 

Выглядит плохо, но это значит, что getResources работает и извлекает контент. Что нам сейчас нужно сделать, так это привести контент к нужному виду и определить какими должны быть наши параметры: например, какие контейнеры использовать для параметра parents, как глубоко в дереве ресурсов делать выборку самих ресурсов, какие поля каждого ресурса мы хотим извлекать на нашу страницу статей и т.д.

6. Создание шаблонирующего tpl чанка для getResources

Для вывода страницы в нужном нам виде, нам необходимо создать чанк для шаблонизации отдельных элементов, которые будет извлекать наш сниппет getResources.  Для этого, я возьму код из статического шаблона, который представляет каждый элемент поста и заменить статические элементы динамическим кодом.

При работе с tpl-чанком мы используем синтаксис заполнителя [[+field_name]] для динамических кусков.

Итак берём HTML код для вывода поста блога в статическом коде файла шаблона blog.html:

<div> <div> <div> <span>06</span> <span>Jan</span> <span>2010</span> </div> <h4><a href="single.html" rel="bookmark" title="Permanent Link to Blog Post 5">Blog Post 5</a></h4> </div> <div> <p><a href="single.html"><img title="slide_7_new" src="sample-data/slide_7_new.jpg" alt="" /></a>This is a test…Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim.</p> . . . <a href="#">Read the rest of this entry &raquo;</a></p> </div> <div>Tags: <a href="#" rel="tag">tag3</a>, <a href="#" rel="tag">tag5</a>, <a href="#" rel="tag">tag7</a><br /> Posted in <a href="#" title="View all posts in Latest News" rel="category">Latest News</a> | <a href="single.html#comments" title="Comment on Blog Post 5">6 Comments &#187;</a></div> </div>

Мы можем использовать данный код как базу нашего tpl чанка. Я заменю статические куски заполнителями. Для короткого содержимого поста я не хочу извлекать содержимое поля Content ресурса, мне нужна лишь короткая выдержка. Поэтому я буду использовать поле аннотация (Introtext) ресурса и далее выводить его, используя конструкцию [[+introtext]] можно также использовать Переменную шаблона [[+tv.tvname]]. Для вывода также можно использовать содержимое ресурса — поле Content. Я могу взять, например, первые 350 символов каждой статьи и вывести. Чтобы это сделать прикрепляю фильтр вывода :ellipsis=350 к моему заполнителю контента.

<div> <div> <div> <span>[[+publishedon:strtotime:date=`%d`]]</span> <span>[[+publishedon:strtotime:date=`%b`]]</span> <span>[[+publishedon:strtotime:date=`%Y`]]</span> </div> <h3><a href="[[~[[+id]]]]" rel="bookmark" title="Permanent Link to [[+pagetitle]]">[[+pagetitle]]</a></h3> </div> <div> <p><a href="[[~[[+id]]]]"><img title="[[+tv.article_image_title]]" src="[[+tv.article_image]]" alt="" /></a> [[+content:ellipsis=`350`]]</p> <a href="[[~[[+id]]]]">Read the rest of this entry &raquo;</a></p> </div> <div>Tags: <a href="#" rel="tag">tag3</a>, <a href="#" rel="tag">tag5</a>, <a href="#" rel="tag">tag7</a><br /> Posted in <a href="#" title="View all posts in Latest News" rel="category">Latest News</a> | <a href="single.html#comments" title="Comment on Blog Post 5">6 Comments &#187;</a></div> </div>

Помните о том, что мы оставляем секцию тегов статической в данный момент, потом к этому мы ещё вернёмся.

Теперь я могу сохранить этот код в чанк, который я назову articleTpl. Далее я изменю мой вызов getResources, добавив туда мой tpl-чанк.

[[!getResources? &showHidden=`1` &tpl=`articleTpl` ]]

Если мы перегрузим нашу страницу Articles, то сразу увидим разницу:

Картинка постепенно оживает!  Мы видим, что выводимый контент отображается с использованием правильного шаблона и мы можем нажать на заголовки, которые ведут на отдельные посты. Но еще предстоит еще много поработать.

Обратите внимание, что если у вас более 5 статей, то только 5 появятся на странице. Так происходит потому что по умолчанию getResources ограничен количеством извлекаемых страниц, которое равно 5.

Вы можете перезаписать данный параметр добавив &limit и указав необходимое количество статей. Я установлю количество статей равным 10, чтобы убедится, что у меня работает всё так как нужно.

Вспоминая наши уловки описанные выше, мы знаем причину того, что аннотации контента не показываются и причину того, что наши заполнители картинок пусты, потому что нам необходимо использовать includeContent, includeTVs и processTVs. Давайте изменим наш вызов и добавим следующие элементы:

[[!getResources? &showHidden=`1` &tpl=`articleTpl` &limit=`10` &includeContent=`1` &includeTVs=`1` &processTVs=`1`]]

Если мы обновим нашу страницу теперь, то увидим изображения и короткие в 350 символов аннотации извлекаемого содержимого, как я указал в шаблонирующем tpl-чанке:

 

Теперь наш контент извлекается и выводится нужнім образом, можем продолжить далее и улучшить наш вызов getResources, добавив другие параметры, которые нам могут понадобиться.

7. Добавьте другие параметры к вызову getResources

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

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

Если вы взглянете на вывод, то заметите, что страница Articles извлекается на странице категории, то бишь MODX News, MODX Web Development, MODX Tips & Tricks и Other Stuff. Очевидно, что я этого не хочу. Вместо этого, я хочу обозначить, что эти субконтейнеры являются предками ресурсов, которые я хочу показать и я хочу проникать только на один уровень вниз до этих субконтейнеров. По умолчанию, getResources предполагает, что ресурс, в котором вы разместили вызов вашего сниппета – это родительский ресурс и он показывает все ресурсы под собой и их дочерние ресурсы на глубину равную 10.

Поэтому я изменю мой вызов и добавлю ID субконтейнеров тех ресурсов, которые я хочу включить и определю глубину отображения ресурсов:

[[!getResources? &showHidden=`1` &tpl=`articleTpl` &limit=`10` &includeContent=`1` &includeTVs=`1` &processTVs=`1` &parents=`13,14,15,16` &depth=`1`]]

Теперь данный вызов покажет только статьи сами по себе, а не их родительские контейнеры. Есть еще несколько спобов сделать так же. Например, если вы собираетесь добавить контейнеры других категорий в будущем и не хотите помнить о том, как возвращаться к вызову, чтобы добавить их ID к параметру &parents, то можете использовать &hideContainers=`1` и далее убрать или отредактировать параметр &depth, чтобы он отвечал структуре вашего сайта. В этом случае вы можете полностью убрать &parents, так как getResources будет считать, что вызов сниппета происходит в родительском ресурсе или для завершения редактирования задайте его значение равным [[*id]]:

[[!getResources? &showHidden=`1` &tpl=`articleTpl` &limit=`10` &includeContent=`1` &includeTVs=`1` &processTVs=`1` &parents=`[[*id]]` &hideContainers=`1`]]

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

Домашнее задание:

Вот маленькое домашнее задание для вас, чтобы протестировать знания, приобретённые в ходе урока.

  • Поработайте над первой секцией сайдбара страницы articles, чтобы построить список и ссылки на категории статей. Можете использовать для этого Wayfinder или getResources, оставляю выбор за вами
  • После этого, необходимо, чтобы страницы, на которые вели ссылки данных категорий содержали агрегацию контента только этой категории. Это просто сделать.

Getresources документация :: iwqnve

Getresources документация

Скачать Getresources документация

Информация:
Дата загрузки: 03.12.2014
Скачали 423 раз
В рейтинге: 277 из 1042
Скорость скачивания: 18 мбит/сек
Файлов в категории: 326
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

mount linux to mac пример

kettler vito m инструкция

Как сделать так, чтобы дочерние документы getResources не выводил, в вот из [[*list_prog_ch]] выводил?
[[GetResources]]. Вызов сниппета без &TPL (то есть без указания шаблона вывода) выведет просто выходной массив полей и их значений.
18 января 2013Нужно вывести через getResources документы, в котором через TV параметр задана определённая дата. … Почитай документацию — он и так выбирает даты из ТВ.
getResources был разработан Джейсоном Ковардом и издан в июне 2009 года. Загрузка. … Смотрите также подраздел Примеры этой документации для ознакомления с более…
С переводом документации getResources можно ознакомиться по этой ссылке: http … Отличительной особенностью данного раздела на rtfm является то, что материалы там…
What is getResources? A general purpose Resource listing and summarization snippet. … getResources was first written by Jason Coward (opengeek) and released on June 30th, 2009.
Разработки MODX Revolution. Документация по getResources. … Что такое getResources? Общая цель — вывод списков Ресурсов и обощающий сниппет.
Документация getResources на русском. Описание. getResources — выводит информацию из ресурсов по заданному шаблону.
Список вещей, которые есть в getResources, но пока не реализованы в pdoResources … И да, документацию я изучила вдоль и поперек еще до того как сюда написала, но все равно спасибо.You can use this class to access your application’s resources. You can generally acquire the Resources instance associated with your application with getResources().

nero cover designer инструкция, dodge caliber, руководство по ремонту, microsoft облако документы. y

pdoTools / Утилиты / Дополнения MODX / modstore.pro

Версия
2.13.2-пл

Дата выхода
09.02.2021

Предупреждение! Для этого компонента требуется версия PHP.
5.6
или выше!
Если ваш сайт использует PHP меньше, чем требуется, установка этого
пакет может его сломать.

Предупреждение! Этот пакет требует MODX не ниже
2.3
!

pdoTools — набор удобных сниппетов для повседневной работы + небольшая библиотека, что делает их очень быстрыми.

Благодаря использованию общих библиотек все фрагменты pdoTools имеют одинаковую минимальную функциональность:

  • Все запросы в базе данных работают через PDO. Объекты XPDO создаются только в том случае, если они действительно не нужны.
  • Предварительная обработка простых заполнителей кусками. Парсер MODX разбирается только в сложных задачах.
  • Правильная сортировка, подготовка, обработка и настройка ТВ вывода.
  • Куски кода можно указывать при вызове сниппета, загружать обычным способом или из статических файлов.
  • «Быстрые заполнители» в чанках, которые заменяют фильтры типа «isempty» и переносят значения в теги, только если они не пусты.
  • Вести подробный фрагмент журнала с отметками времени для отладки.

В спешке разрабатываем сайт под MODx

Vom
14. декабрь 2015 г.

Когда мы обновляли демонстрационный сайт нашей компании (игровая площадка для клиентов), мы поняли, что разработка сайта идет намного быстрее, когда контент и структура уже есть. Не то чтобы мы просто экономили время, которое обычно тратили на настройку структуры. Очень важно иметь структуру на месте. В результате ваша команда разработчиков будет примерно в 20 раз быстрее, чем обычно.

В этой статье мы собираемся рассмотреть несколько вещей, которые мы делали (неправильно) в прошлом, но мы не собираемся делать это снова в будущем, особенно для больших или растущих сайтов.

Разработка сайта MODx — восхитительная работа. По нескольким причинам:

  • «Есть несколько способов сделать это»
  • Нет ограничительного механизма шаблонов, который сообщает вам, где что разместить.
  • Нет уязвимых «популярных» плагинов, которые сводят вас с ума
  • Никаких попыток подбора пароля (после смены адреса менеджера)
  • Нет сценария, когда вы должны сказать своему клиенту, что «это просто невозможно».

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

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

Предварительные требования

Это статья с передовым опытом, адресованная разработчикам, которые знают о следующих программных продуктах:

Есть еще несколько, о которых нам нужно знать. На самом деле речь идет не об этих конкретных пакетах, а об уровне вашего опыта разработки сайтов в целом.

Что еще нужно знать о
  • Настройка разрешений
  • Настройка отдельного медиа-источника для ваших клиентов
  • Настройка менеджера / формы

Зачем вам об этом знать? Мы обращаемся к тем из вас, кто планирует предоставить своим клиентам «идеальный» продукт, который трудно сломать и который легко поддерживать, даже если он поддерживает сложный веб-сайт.

Делать все в правильном порядке

Это самая важная часть, в которой мы чаще всего ошибались. Даже если это сложно сделать, постарайтесь придерживаться следующего порядка:

  1. Соберите всей информации, которую вы можете получить о сайте, который вы должны создать
  2. Создайте структуру на сайте, как она будет выглядеть, какой сайт вы хотите создать, образцы страниц, образцы коллекций и т. Д.
  3. Добавьте большинство переменных шаблона и образцы фрагментов (да, большинство из них, вы пропустите хотя бы один :))

После этого можно приступать к работе.Вы можете создавать шаблоны. Вот как это сделать быстро и элегантно:

  1. Выберите шаблон с наибольшим количеством элементов (скорее всего, страница приветствия)
  2. Начните разбивать шаблон на многократно используемые части, которые вы можете использовать в других шаблонах (заголовок, нижний колонтитул, новости, участники, welcomeSlider и т. Д.).
  3. Установите и запустите этот шаблон one , собрав всю информацию из связанных ресурсов и т. Д.
  4. После этого скопируйте из этого шаблона и повторно используйте уже проделанную работу.Это намного быстрее, когда у вас уже есть все готовые к работе и извлеченные из них фрагменты.
  5. Когда все будет готово, вы можете приступить к настройке параметров менеджера, разрешений и всего остального. Это также работа, которую необходимо выполнить last , потому что вы можете дублировать свои наборы настроек, что также сэкономит вам много работы.

К настоящему времени ваши шаблоны должны выглядеть чистыми и простыми (как и ваши формы). К настоящему времени большая часть кода шаблона должна уместиться в одном окне.Если есть еще какие-то огромные блоки HTML, подумайте, не являются ли они чем-то лишним, принадлежащим чунлу.

Примечание: мы написали это, потому что выполнение действий в неправильном порядке оставит вам примерно в три раза больше работы, не считая одной настройки менеджера.

Избегайте «дорогих» фрагментов

Мы использовали getResources, WayFinder, getPage и несколько других почти на каждом сайте, который мы создали в прошлом, что было хорошо для страниц среднего размера, но как только у нас было несколько запросов на получение связанных данных на одной странице, все стало замедляться. существенно.

Кэширование базы данных, переход на memcache, множество других улучшений, которые, похоже, не имели значения. Но ждать! Было множество реликвий разработки: почти половина вызовов наших сниппетов были некэшированными. Это дало некоторые улучшения. Но все равно страница загружалась около 2 секунд.

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

 
 
 Может показаться, что это немного, но это экономит половину времени рендеринга.Либо $ chunk1, либо $ chunk2 останется заключенным в две дополнительные скобки, что приведет к тому, что MODx будет разрешать только результат вместо рендеринга каждого отдельного фрагмента. 

 
 Если вы еще этого не сделали, возможно, вы все еще используете фрагмент «Если». Удалите его и используйте вместо него выходные фильтры. Если действительно медленно. 

 
 getResources, getPage, WayFinder 

 
 … все можно заменить пакетом под названием «pdoTools». Использование эквивалентов pdoTools для упомянутых выше фрагментов ускорит вашу страницу в среднем в 10 раз.

 
 Причина этого — во избежание ненужных звонков. Так что у этого подхода есть и недостатки. Поскольку pdoTools использует xpdo напрямую вместо использования getCollection, это также означает, что он обходит безопасность MODx, поэтому разрешения и все, что в них нуждается (что не так на большинстве сайтов, потому что большинство сайтов не имеют большой логики или другого пользователя -groups) потребуется активировать вручную. Тем не менее, есть флаг под названием & checkPermissions, чтобы включить их, если они вам понадобятся.

 
 Однако в большинстве случаев в этом нет необходимости, поэтому вы можете безопасно использовать pdoTools в качестве замены для ваших вызовов. 

 
 Другие отличия: 

 
  includeTVs : это не флаг 0 или 1 в pdoResources, а список конкретных телевизоров, которые нужно захватить, что делает его тоньше и быстрее, чем getResources 

 
  родителей : наконец-то согласовано. pdoMenu не использует startId вместо родителей, и флаги tpl немного отличаются. Помимо этого, это прямая замена Wayfinder.Поскольку вы, скорее всего, отобразите меню на  ВСЕХ  своих страницах, включая нижний колонтитул и другие меню, изменение этого параметра сильно повлияет на производительность ваших сайтов. 

 
  pdoPage  также более удобен и больше не нуждается в этом неортодоксальном синтаксисе. 

 
 Вместо того, чтобы читать это, вам, вероятно, следует прочитать документацию pdoTools и попробовать. 

 
 pThumb, изменение размера, getCache, MinifyX, autoFixImageSize 

 
 Есть также множество других сниппетов, которые заменяют «дорогие», завершают вещи, которые увеличивают загрузку страницы и которые в большинстве случаев просто неправильно настроены (или отсутствуют).Многие люди забывают изменить размер фоновых изображений, изображений слайдеров и общего содержимого, и, что более важно, настроить pthumb для рендеринга с качеством 85% и принудительного форматирования в jpg, чтобы избежать bmps, tiffs и png для огромных изображений. Это значительно уменьшит размер вашей страницы. Просто прочтите, что делают другие фрагменты. 

 
 Общие улучшения 

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

 
 MinifyX не может объединить все Javascript и CSS, иногда это все портит. Но ты можешь. После завершения работы над сайтом вы можете использовать компилятор Google Closure Compiler, чтобы загрузить только ОДИН минифицированный файл javascript вместо загрузки тонны отдельных файлов. 

 
 Уменьшите размеры изображений, уменьшите размер файлов CSS и постарайтесь придерживаться вышеуказанных правил. 

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

 
 Итог 

 
 Избегайте getResources, избегайте WayFinder, замените phpThumbof на pthumb, настройте кэширование базы данных, замените большую часть используемого вами материала эквивалентом pdoTools и начните делать вещи в правильном порядке. 

 
 Как сказал бы Монах: 

 
 Вы меня потом поблагодарите. 

 
 Приложение 

 
 Для вашего удовольствия вот несколько вещей, в которых мы пошли не так: 

 
 # 1 После того, как мы спланировали сайт для нашего клиента, мы начали разработку сайта, добавили к нему много данных, настроили модные страницы для ссылок и членов команды, настроили для всех них настройки менеджера и представили работу, которую мы уже пришлось им, чтобы они могли видеть, как легко поддерживать свою информацию.

 
 — Оказалось, что колебания сотрудников слишком велики, чтобы назвать кого-либо из членов команды, фотографий не существует, а ссылки / портфолио не нужны, потому что они не хотят, чтобы кто-то знал, кто их клиенты. Большинство из них — конкуренты. Возможно, у нас была возможность сначала спланировать структуру сайта. Мы как бы упустили это. 

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

 
 — каждые две недели мы добавляли еще одно поле, еще одно поле, дополнительное изображение и прикрепленный к нему файл PDF. Тогда PDF-файл должен быть изображением первой страницы PDF-файла, и он должен быть интерактивным. После этого нужно было подсчитать количество скачиваний файла. 

 
 Примерно через шесть недель клиенты спрашивают: «Можно ли вообще просто вести список общей информации вместо того, что мы только что добавили». — на этом этапе вы можете захотеть убить своего клиента.Но с другой стороны, это наша вина. Сначала мы должны были собрать всю эту информацию, и мы должны были сделать предложение о том, как поддерживать и представлять эту информацию. 

 
 часов, потраченных впустую на настройку менеджера, отсутствие полей в настройках менеджера, отсутствие MIGX, неисправный MIGX, разные метки и т. Д. — Всего этого можно было бы избежать, если бы мы просто сделали все в правильном порядке. 

 
 Это намного больше, и мы уверены, что это еще не все. Но вы видите, к чему мы клоним.


 Технические соображения Последние исследования 


 

Стивен Воронецки
◽
 

 

Фемке Анна Шпигеленберг
◽
 

 

Александр Шоссон
◽
 

 

Бет Тернер
◽
 

 

Изабель Ки
◽
 

 …

 

Природные решения (NBS) & mdash; т.е. работа с природой и улучшение ее состояния для решения социальных проблем & mdash; функция, которая становится все более заметной в ответах на изменение климата, в том числе в планах адаптации наиболее уязвимых стран.Хотя доказательств эффективности NbS для адаптации становится все больше, существует меньше данных о том, уменьшают ли и каким образом NbS уязвимость к изменению климата на Глобальном Юге, несмотря на то, что этот регион является домом для большинства наиболее уязвимых к климату людей в мире. Чтобы решить эту проблему, мы проанализировали результаты снижения уязвимости 85 природоохранных мероприятий в сельских районах по всему Глобальному Югу и факторы, опосредующие их эффективность, на основе систематической карты рецензируемых исследований, охватывающих большое разнообразие экосистем и климатических воздействий. , виды вмешательства и институты.Мы применили аналитическую структуру, основанную на социально-экологических системах и уязвимости к изменению климата, кодируя исследования по шести путям снижения уязвимости: социальная и экологическая уязвимость, чувствительность и способность к адаптации. Мы находим широко распространенную эффективность NbS в наборе данных, при этом 95% обеспечивают положительные результаты для адаптации к изменению климата. В целом, природоохранные мероприятия снизили уязвимость, прежде всего, за счет снижения чувствительности экосистем к климатическим воздействиям (73% вмешательств), за которым последовало снижение социальной чувствительности (43%), уменьшение воздействия на окружающую среду (37%) и / или повышение социальной способности к адаптации (34 %), способность к экологической адаптации (18%) и снижение социальной подверженности (12%).С помощью анализа факторов-посредников мы показываем, что на эффективность снижения уязвимости влияли как социальные и политические факторы, так и технические соображения. Действительно, конфигурации существующих и введенных формальных и неформальных институтов кажутся ключевыми для эффективности и распределительного эффекта изучаемых вмешательств. Мы пришли к выводу, что внимание к отдельным путям снижения уязвимости может помочь максимизировать преимущества NbS и что для достижения успеха необходимо тщательное рассмотрение их применимости к конкретным обстоятельствам, а также их социальных аспектов.

 
 Создание динамически обновляемого списка элементов с использованием списка конфигураций MIGX в MODX 


 У меня есть довольно большая симуляция, которую я сейчас запускаю в Shiny с использованием цикла double for, и это занимает очень много времени. Я читал о возможности использования  foreach , но это не сработает, что бы я ни пробовал, я и выше с ошибками. Может быть, кто-нибудь сможет обнаружить ошибку и помочь мне исправить ее? 

 
 app.R, который работает (хотя и очень медленно (на реальных данных) здесь с данными для примера для  REPEX  

 
  требуется (блестящий)
требовать (tidyverse)
требовать (foreach)
требуется (doMC)
registerDoMC ()
параметры (cores = detectCores ())

df <- данные.кадр (a = rnorm (n = 26), b = 1:26, c = 100: 125)

calc <- function (let = 0.5, var1 = 0.1, var2 = 0.5) {
  df%>%
    mutate (p1 = ifelse (a %
    mutate (p2 = ifelse (a %
    суммировать (mean_b = mean (b * p1),
              mean_c = среднее значение (c * p2))
}

# Определить UI для приложения, которое рисует гистограмму
ui <- fluidPage (
  
  # Название приложения
  titlePanel ("Пример"),
  
  # Боковая панель с ползунком для ввода количества ящиков
  sidebarLayout (
    sidebarPanel (
      sliderInput (inputId = "selected_let",
                  label = "LET",
                  значение = 0.5,
                  мин = 0,
                  макс = 1,
                  шаг = 0,1),
      
      submitButton ("ВЫЧИСЛИТЬ")
      
      
    ),
    
    
    # Показать график сгенерированного распределения
    mainPanel (
      h2 (paste0 ("Таблица1")),
      tableOutput ("таблица_1"),
      
      h2 (paste0 ("Таблица2")),
      tableOutput ("таблица_2")
    )
  )
)

# Определить логику сервера, необходимую для рисования гистограммы
server <- функция (ввод, вывод) {

  
  
  данные <- реактивный ({
    
    данные <- data.frame ()
    
    for (i in seq (0,1, by = 0.1)) {
      for (j in seq (0,1, by = 0.1)) {
        
        tmp <- calc (let = input $ selected_let, var1 = i, var2 = j)
        tmp_df <- data.frame (var1 = i,
                             var2 = j,
                             mean_b = tmp $ mean_b,
                             mean_c = tmp $ mean_c)
        данные <- rbind (данные, tmp_df)
        
      }
    }
    возврат (данные)
    
  })
  
  
  output $ table_1 <- renderTable ({
    данные ()%>%
      выберите (var1, var2, mean_b)%>%
      распространение (var2, mean_b)
  })
  
  
  вывод $ table_2 <- renderTable ({
    данные ()%>%
      выберите (var1, var2, mean_c)%>%
      распространение (var2, mean_c)
  })
  
  
}

# Запускаем приложение
shinyApp (пользовательский интерфейс = пользовательский интерфейс, сервер = сервер)

  
 Моей целью было изменить данные  <-...  часть с  foreach пакет , и поскольку мой компьютер работает под UNIX, я использую  doMC .
 заменить на:
  данные <- реактивный ({
  
  foreach (i = rep (seq (0,1, by = 0,1), каждый = 11),
          j = rep (seq (0,1, by = 0,1), раз = 11),
          .combine = "rbind")% dopar% {
            
            val <- calc (let = input $ selected_let,
                        var1 = i,
                        var2 = j)
            
            data.frame (var1 = i,
                       var2 = j,
                       mean_b = tmp $ mean_b,
                       mean_c = tmp $ mean_c)
          }
  
})

  
 Но это приводит к постоянным ошибкам:
 Я пробовал выставить  require (dplyr)  в серверной части, но это тоже не помогло.Есть предложения по решениям?
 Как автономно,  foreach часть  работает хорошо с  let = 0,5  в качестве входных данных, учитывая, что его нет в  reactive 
  foreach (i = rep (seq (0,1, by = 0,1), каждый = 11),
        j = rep (seq (0,1, by = 0,1), раз = 11),
        .combine = "rbind")% dopar% {
          
          val <- calc (let = 0.5,
                      var1 = i,
                      var2 = j)
          
          data.frame (var1 = i,
                     var2 = j,
                     mean_b = tmp $ mean_b,
                     mean_c = tmp $ mean_c)
        }
  
 Как мне заставить Babel и WayFinder работать с разными контекстами и уникальными стартами? 
 Я использую MODX Revolution 2.5,6-пл. У меня есть многоязычный сайт с несколькими языками, использующий Babel, который работает, как ожидалось. Однако для навигации у меня есть стартовый идентификатор, который относится к контейнеру на моем (английском) сайте по умолчанию.
Другие языки будут использовать тот же шаблон и, следовательно, тот же вызов WF. Как я могу изменить вызов WF, чтобы предоставить уникальные стартовые идентификаторы для каждого языкового контекста? - Или мне нужно создать уникальный вызов WF для каждого языка?
Это мой вызов WF:
[[Wayfinder?
& startId = `80`
& outerClass = `navigation__nav__list`
& innerClass = `navigation__nav__submenu`
& rowTpl = `navigationRows`
& rowIdPrefix = `nav__item`
& level = `3`
]]
 
У wayfinder есть опция: & startIdContext, но она не задокументирована (опубликуйте свой вопрос на форумах modx), если вы не можете установить контекстную переменную в контексте ewach и вызвать wayfinder:
[[Wayfinder?
& startId = `[[++ context_start_id]]`
& outerClass = `navigation__nav__list`
& innerClass = `navigation__nav__submenu`
& rowTpl = `navigationRows`
& rowIdPrefix = `nav__item`
& level = `3`
]] 
 Связанные 
 CMS Made Simple - установка переменной, доступной в шаблонах 
 Можно ли создать пользовательскую переменную в CMS Made Simple, которую можно было бы установить в одном шаблоне, а затем это значение было бы доступно в другом шаблоне для того же сайта?
Редактировать:
Я забыл добавить, что шаблон, в котором я хочу установить переменную, использует другой домен, хотя это тот же сайт.Это означает, что я не могу использовать файлы cookie или переменные сеанса.
 
Вы можете использовать систему smarty assign или capture:
{assign var = "foo" value = "bar"}
{capture name = "foo"} панель {/ capture}
Обратите внимание, что это зависит от порядка выполнения шаблонов. Например, в большинстве сценариев все, что находится внутри, выполняется раньше, чем все, что находится внутри основного шаблона. 
 Как создать мультиязычный сайт MODx с уникальными статьями на каждом языке? 
 Мне нужно разработать мультиязычный веб-сайт (русский, английский и кыргызский языки), каждая статья имеет версию только на одном языке.Не могли бы вы помочь мне с вопросами:
1. как создать контекст для кыргызского языка? это просто поставить ключ культуры = кг?
2. как перевести массу кусков, то есть "комментариев" или кнопок? мне нужно создавать разные чанки для новых контекстов? Или я просто куда-то сохраняю перевод?
3. как контролировать, какие ресурсы будут отображаться через pdoresources (getresources)? мне нужно указывать идентификатор из всех контекстов?
4. Для контекстных веб-страниц есть псевдоним mywebsite.ru/category/article, а для контекста "en" - mywebsite.ru/en/INDEX/category/article.как убрать индекс? когда я пытаюсь использовать ссылку вроде mywebsite.ru/en/ - отображается ошибка 503. в чем может быть проблема?
Спасибо!
 
Создать новый контекст
Используйте словарный запас. Если вы не хотите создавать новое пространство имен, просто используйте core.
Если вы читаете документацию, вы можете увидеть доступные параметры для определения родителя, ресурсов или исключенных ресурсов для отображения.
Вам нужно проверить свой .htaccess и все настройки дружественных URL. 503 сам по себе означает недоступный сайт. Проверьте настройки своей системы и найдите ключ site_status.Это должно быть «да» для работающего веб-сайта. 
 Докувики - как динамически изменять видимое содержимое страницы 
 У меня есть документация для разработчиков на сайте dokuwiki. Существует несколько версий программного обеспечения (например, v1, v2 ...). Я хотел бы иметь возможность динамически изменять видимое содержимое страницы в зависимости от версии программного обеспечения.
Например, на странице есть раскрывающийся список, позволяющий читателю выбрать «v1, v2 и т. Д.»"При выборе v2 только определенные части страницы изменяются, чтобы отразить часть v2.
Вот пример содержания некоторой вики-страницы:
Чтобы собрать проект foobar, сначала загрузите код:
cd ~
git clone https://foo.example.com/bar.git
git checkout v1.0
...
Если человек изменит выбранный элемент в раскрывающемся списке на v2, он изменится на следующее:
Чтобы собрать проект foobar, сначала загрузите код:
cd ~
git clone https://foo.example.com/bar.git
git checkout v2.0
...
Кто-нибудь знает плагин, который может делать подобные вещи в «Докувики»?
 
Некоторое время назад я написал плагин вариантов, это доказательство концепции плагина, который позволяет предоставлять варианты частей страницы в зависимости от заданных пользователем параметров.Это работает, но набор функций очень ограничен, то есть вы можете указать только какой-то параметр в URL-адресе, а затем, в зависимости от этого параметра, в вашем тексте могут быть блоки if-else. Должна быть возможность установить этот параметр из раскрывающегося списка, но плагин не предоставляет раскрывающегося списка. Если вы хотите его расширить, не стесняйтесь и отправьте патч или запрос на перенос.
Другой подход используется плагином page4release, который был создан для описываемой вами цели, но он использует совершенно разные страницы для разных версий программного обеспечения.Вы также можете использовать комбинацию этого подключаемого модуля и подключаемого модуля включения, если на ваших страницах есть большие общие части, которые вы можете включить с одной общей страницы (отказ от ответственности: я являюсь автором подключаемого модуля включения). 
 ModX WayFinder не отображает список 
 Я установил путевой указатель на свой MODX Revolution 2.2.0-rc3 (с помощью диспетчера пакетов).
Есть 2 опубликованных документа.
Я поместил это в основной шаблон:
[[Wayfinder? & startId = `0`]]
Но ничего не произошло. Есть идеи?
Имейте в виду, что это мой первый день в Modx.Спасибо
 
Я знаю, что в документах говорится называть это так, но сначала попробуйте назвать его некэшированным, если не убедитесь, что ваши опубликованные документы не `` скрыты ''
без кеширования:
[[! Wayfinder? & startId = `0`]]
заставить его показать скрытый
[[! Wayfinder? & startId = `0` & ignoreHidden =` 0`]]
Я вижу, вы задали еще один вопрос относительно modx, пробовали ли вы пользоваться официальным форумом modx и форумом поддержки пользователей? rtfm.modx.com 
 Как использовать запрос URL / перезаписи URL для локализации в ASP.NET - использование модуля HTTP или кода Global.asax 
 Я хотел посмотреть, есть ли способ использовать URL-адрес запроса / перезапись URL-адреса для установки языка, на котором отображается страница, путем изучения части URL-адреса в ASP.NET. У нас есть сайт, который уже работает с локализацией ресурсов ASP.NET, и пользователь может изменить язык, на котором они видят страницы / ресурсы на сайте, однако текущий механизм не очень удобен для поисковых систем, поскольку все языковые вариации для каждого языка отображаются как одна страница.Было бы намного лучше, если бы у нас были такие страницы, как www.site.com/en-mx/realfolder/realpage.aspx, которые позволяют ссылаться на версии страницы, специфичные для культуры.
Я знаю, что многие люди, вероятно, уже делали локализацию с помощью структур URL-адресов раньше, и я хотел знать, может ли кто-нибудь из вас поделиться, как это сделать, в файле Global.asax или с помощью модуля HTTP (указание на ссылки на сообщения в блогах тоже было бы здорово ). У нас есть ограничение, что сайт основан на ASP.NET 2.0 (поэтому мы пока не можем использовать функции 3.5+).Вот пример сценария:
Настоящая страница закрывается по адресу:
www.site.com/realfolder/realpage.aspx
На странице есть механизм для пользователя
изменить язык, на котором он отображается
в раскрывающемся списке.
Есть поисковая оптимизация
и ссылки пользователей, которые делятся преимуществами с
делать это, потому что люди могут ссылаться
прямо на страницу с содержанием
это применимо к определенному
язык (это также может включать
раскладки справа налево для языков
вроде японец).
Я хотел бы использовать модуль HTTP для
посмотрите, если первая часть URL-адреса после
www.site.com, site.com,
subdomain.site.com и т. д. содержит
действительный код культуры (например, en-us, es-mx)
затем используйте это значение, чтобы установить
культура локализации
страница / ресурсы на основе этого URL.
Итак, если пользователь обращается к URL-адресу
www.site.com/en-MX/realfolder/realpage.aspx
Затем страница будет отображаться в Мексике
вариант испанского.
Если пользователь переходит на
www.site.com/realfolder/realpage.aspx
непосредственно страница будет использовать их
языковые настройки браузера.
 
Я делаю это в global.asax, как объясняется в этом ответе, затем я настраивал разные URL-адреса на главной странице, чтобы изменить язык в зависимости от текущего:
то есть:
Если Request.Path.Contains ("/ en /") Тогда
DestinationPathEs = Request.Path.Replace ("/ en /", "/ es /")
DestinationPathPt = Request.Path.Replace ("/ en /", "/ pt /")
litLangBar.Text = "  испанский  "
litLangBar.Text + = "  Portugues  "
litLangBar.Text + = " английский " 
 Образец резюме старшего аналитика по финансовому учету 
 Роль старшего аналитика по финансовому учету отвечает за Microsoft, аналитику, Excel, отчетность, базы данных, продвинутый, количественный, розничный, финансы, обучение.
 Чтобы написать отличное резюме на должность старшего аналитика финансового учета, ваше резюме должно включать:
  •  Ваша контактная информация
  •  Стаж работы
  •  Образование
  •  Список навыков
 Контактная информация раздела важна в вашем резюме старшего финансового аналитика. Рекрутер должен иметь возможность связаться с вами как можно скорее, если они хотят предложить вам работу. Вот почему вам необходимо предоставить:
  •  Имя и фамилия
  •  Электронная почта
  •  Телефонный номер
 Опыт работы в разделе - важная часть вашего резюме старшего аналитика финансового учета.Это единственное, что действительно волнует рекрутера и которому он уделяет больше всего внимания.
 
 Этот раздел, однако, не просто список ваших предыдущих обязанностей старшего аналитика финансового учета. Он предназначен для того, чтобы представить вас в качестве достойного кандидата, продемонстрировав ваши соответствующие достижения, и должен быть адаптирован специально для конкретной должности старшего аналитика финансового учета, на которую вы претендуете.
 Раздел об опыте работы должен быть подробным описанием ваших последних 3 или 4 позиций.
 Представитель Старшего аналитика по финансовому учету в резюме Опыт может включать:
  •  Человек, ориентированный на работу в команде, обладающий отличными навыками решения проблем и суждения с большим вниманием к деталям и точностью
  •  Продемонстрированные аналитические и устные / письменные коммуникативные навыки
  •  Подтвержденный опыт работы с принципами признания доходов
  •  Способен эффективно работать с большими группами данных
  •  Работайте независимо и эффективно, создавая оперативные документы
  •  Опыт ведения бухгалтерского учета или отчетности в телеиндустрии
 Обязательно сделайте образование приоритетным в своем резюме старшего аналитика финансового учета.Если вы проработали несколько лет и у вас есть несколько хороших позиций, выберите свое образование после опыта старшего аналитика финансового учета.
 Например, если у вас есть докторская степень в области неврологии и степень магистра в одной и той же области, просто укажите свою докторскую степень. Далее идут степени магистра, бакалавра и, наконец, младшего специалиста.
 Дополнительные сведения должны включать:
  •  Школа, которую вы закончили
  •  Major / minor
  •  Год выпуска
  •  Расположение школы
 Это четыре дополнительных элемента информации, которые вы должны указать при включении вашего образования в резюме.
 При перечислении навыков в резюме старшего аналитика финансового учета всегда честно указывайте уровень своих способностей. Включите раздел навыков после опыта.
 Представьте самые важные навыки в своем резюме, есть список типичных навыков старшего аналитика финансового учета:
  •  Сильный бухгалтерский учет, анализ отклонений, сверка баланса и навыки решения проблем
  •  Продемонстрированные навыки координации проекта и решения проблем
  •  Продвинутый уровень владения приложениями Microsoft Office с хорошими навыками компиляции и агрегирования данных в Excel (например,грамм. сводные таблицы и v-справочник)
  •  Продвинутые навыки в разработке моделей прогнозирования, отчетности и дисперсионного анализа
  •  Отслеживайте прогресс производства, чтобы обеспечить финансовую прозрачность и гарантировать, что производство работает эффективно / результативно
  •  Высокий уровень знаний по основным компьютерным навыкам, таким как Windows, электронные таблицы и текстовый процессор
 1. -? Веб-просмотр используйте результаты оценки HSE для разработки Документа C-09 «Требования HSE» для включения в тендерную документацию.... Инструктаж и инструктаж по ОТ, ПБ и ООС 
 Petroleum Development Oman L.L.C.
 Документ: Контракт на управление ОТОСБ:
 Идентификатор документа
 PR-1171 ЧАСТЬ 1
 Тип документа
 Процедура
 Безопасность
 Без ограничений
 Дисциплина
 Менеджмент Безопасность и окружающая среда
 9000 Руководитель документа
 корпоративного HSE-SD
 Месяц и год выпуска
 Март 2012
 Версия
 5.0
 Ключевые слова
 Правила компании по управлению ОТ, ПБ и ООС в контрактах
 ОКОНЧАНИЕ
 Авторские права: Этот документ является собственностью Petroleum Development Oman, LLC. Ни весь, ни какая-либо часть этого документа не может быть раскрыта другим лицам или воспроизведена, сохранена в поисковой системе или передана в любой форме любыми средствами (электронными, механическими, репрографическая запись или иным образом) без предварительного письменного согласия владельца.
 ПРОЦЕДУРА HSE
 Внедрение HSE в наш бизнес
 (ПРОЦЕДУРА ЗДОРОВЬЯ, БЕЗОПАСНОСТИ И ОКРУЖАЮЩЕЙ СРЕДЫ Контрактное управление ОТОСБ обязательно для персонала PDO, участвующего в управлении контрактом ДОКУМЕНТ ID- PR 1171 Часть IREVISION- 5.0 ДАТА- 01 // 2011)
 PR1171 Часть I
 ПЕРЕСМОТР 1.0
 Page 35
 PR1171 Часть I: HSE в процедуре контрактов
 Напечатано 23.04.12
 Контролируемая версия этого документа CMF находится в Интернете на Livelink. Печатные копии НЕ КОНТРОЛИРУЮТСЯ.
 ДОКУМЕНТ Авторизация
 Ниже приводится краткое изложение трех последних редакций этого документа. Подробная информация обо всех предшествующих изменениях хранится у Хранителя документов.
 Номер версии
 Дата
 Автор
 Объем / Примечания
 Версия 5.0
 01.04.2012
 Кевин Дойл MSE / 12
 Переформатировано. Заменяет PR1171 Часть I. Версия 4. Добавлен. Требование к предварительному плану ОТОСБ. Критические задачи упорядочены с 53 до 25, чтобы повысить ценность контрактного процесса ОТОСБ.
 Версия 4.0
 Янв 2002
 Trevor Ford UEG / 1D
 Переформатировано. Заменяет HSE / 97/04, HSE / 97/06 HSE / 96/02, SP-1080.Переработано в соответствии с новой схемой CHCS. Удалены положения по контрактам с низким уровнем риска. Удалено требование к предварительному плану ОТОСБ.
 Version 3.0
 Dec 1998
 Steve Raatz CSM / 2x
 Перенумерован для EDMS (ранее HSE / 97/02). Переформатирован в новый шаблон процедуры. Добавлено положение о контрактах с низким уровнем риска, включая незначительные изменения в плане управления контрактами.
 Примечания для пользователя:
 Требования этого документа являются обязательными. Несоблюдение должно быть разрешено только CFDH Operations Safety посредством утверждения STEP-OUT.
 Контролируемая копия текущей версии этого документа находится на Livelink и на веб-странице HSE, а также на странице HSE для подрядчиков. Прежде чем делать ссылку на этот документ, пользователь несет ответственность за то, чтобы любая его бумажная или электронная копия , является текущим. За помощью обращайтесь к Хранителю документов.
 Данный документ является собственностью ООО «Петролеум Девелопмент Оман». Ни весь, ни какая-либо часть этого документа не может быть раскрыта другим лицам или воспроизведена, сохранена в поисковой системе или передана в любой форме любыми средствами (электронными, механическими, репрографическая запись или иным образом) без предварительного письменного согласия владельца.
 Связанные бизнес-процессы и документы CMF
 Связанные бизнес-процессы
 Код
 Бизнес-процесс (EPBM 4.0)
 Родительские документы
 Док. №
 Название документа
 CP 122
 Руководство по системе управления HSE
 Прочие сопутствующие документы CMF
 Док. №
 Название документа
 PR 1171 Pt I & II
 Контракт на управление ОТОСБ
 PR 2010 Pt II
 Утверждения и процедура обеспечения качества обучения HSE
 SP 1157
 Спецификации обучения HSE
 SP 2000
 SP 2000
 SP 2000
 SP 2000
 Спецификация автомобильного транспорта
 GU 673
 Основная система оценки HSE
 PR1233
 Контрактный менеджмент C&P
 SP1234
 PPE
 Связанные документы корпоративного управления (CMF)
 Соответствующие документы CMF можно найти в корпоративных документах CMF. Регистр деловой документации CMF.
 Petroleum Development Oman LLC
 Версия: 3.9
 Дата вступления в силу: март 2012 г.
 i
 PR1171 Часть I: HSE в компании по процедуре контрактов
 Отпечатано 23.04.12
 Контролируемая версия этого документа CMF находится в Интернете в Livelink. Печатные копии НЕ КОНТРОЛИРУЮТСЯ.
 Содержание
 Связанные бизнес-процессы и документы CMFiv
 Связанные документы системы корпоративного управления (CMF )iv
 1.Введение1
 1.1 Предпосылки1
 1.2 Цель1
 1.3 Распределение1
 2. Контрактная процедура управления ОТОСБ2
 2.1 Объем2
 2.2 Описание2
 2.3 Обязанности владельцев контрактов2
0003 2.4 Обязанности держателей контрактов
0003 Планирование и приглашение к участию в тендере4
 Задача 1 Держатель контракта на проведение оценки ОТОСБ4
 Задача 2 Подготовка (GU140) C-09 Требования к ОТОС 4
 Задача 3 Разработка критериев предварительной квалификации по ОТОСБ5
 Задача 4Tender Board
 Предварительный квалификационный отбор
000 Фаза контракта Период проведения тендера7
 Задача 6 Представление подрядчиком: Документ GU140 (C-09) Требования HSE7
 Задача 7 Посещение объекта7
 Задача 8Совещание по разъяснению7
 Этап контракта: оценка и присуждение контракта8
 Задача 9Проверить представление подрядчика по документу C-09 Требования ОТБОС 8
 Задача 10 Утвердить ключевой персонал ОТОСБ подрядчика 9
 Этап контракта: Мобилизация9
 Задача 11 Начальное совещание PDO Внутреннее совещание и встреча подрядчика9
 Задача 12 Семинар ОТОСБ10
 Задача 13 Утвердить план ОТОСБ подрядчика.11
 Задача 14 Держатель контракта разрабатывает программу мониторинга ОТОСБ для PDO, рассматривает и утверждает 11
 Задача 15ОПР и обучение подрядчиков 11
 Задача 16 Предварительный аудит ОТОСБ подрядчика (контрольный список ОТОСБ) 12
 Задача 17 Подрядчик выполняет пункты предварительного аудита ОТОСБ 13
 Задача 18 Держатель договора о выдаче Свидетельства о начале HSE13
 Этап договора - выполнение14
 Задача 19 Мониторинг выполнения подрядчиками плана управления HSE14
 Задача 20 Дополнительные требования HSE14
 Задача 21 Пересмотреть / пересмотреть и внедрить план HSE 14
 Задание по умолчанию
 Задача 23 Контрактные отчеты о выполнении ОТОСБ15
 Этап контракта: Демобилизация16
 Задача 24 Утверждение сертификата восстановления сайта16
 Фаза контракта: Отчет о закрытии16
 Задача 25 Отчет о выполнении ОТОСБ по окончательному контракту16
 Приложение A: Контрольный список контрактов по ОТОСБ 17 9000 для второстепенных контрактов 3
 Приложение B: Формат по умолчанию HSE (Образец) 18
 Приложение C: Программа мониторинга HSE 20
 Приложение D: Шаблон, Контрактный отчет о выполнении HSE21
 Приложение E: Свидетельство о начале HSE23
 Приложение F: Сертификат восстановления объекта24
 Приложение G: доступ к PDO и веб-документам Shell25
 Приложение H Контракт Схема деятельности по ОТОСБ и RASCI (ответственность, подотчетность, поддержка, консультации, информирование) 26
 ii
 PR1171 Часть I: HSE в компании по процедуре контрактов
 Отпечатано 23/04 / 12
 Контролируемая версия этого документа CMF находится в сети в Livelink.Печатные копии НЕ КОНТРОЛИРУЮТСЯ.
 ЧАСТЬ I: Обязательно для персонала PDO, участвующего в управлении контрактами
 1. Введение 1.1 Общие сведения
 Документ политики PDO, PL-04, Здоровье, безопасность и защита окружающей среды, требует применения систематического подхода к управлению ОТ, ПБ и ООС, что потребует от подрядчиков управлять ОТОСБ в соответствии с Политикой ОТОСБ PDOs. Документ кодекса практики PDO, Руководство по системе управления HSE CP-122, часть 2, глава 3, требует, чтобы менеджеры PDO Asset Manager были осведомлены о требованиях к управлению HSE PDOs и имели адекватные средства управления бизнесом для их выполнения.
 Международная организация по стандартизации (ISO 14001: 1996, параграф 4.4.3) требует, чтобы процедуры были установлены и поддерживались в рабочем состоянии, чтобы гарантировать, что соответствующие экологические требования доведены до сведения Подрядчиков.
 1.2 Цель
 Документ PR-1171 состоит из двух частей:
 Часть I: Обязательно для персонала PDO, участвующего в управлении контрактами
 Часть II: Обязательно для держателей контрактов и подрядчиков
 Часть I содержит подробную информацию, которой должны следовать Держатели контрактов Описаны 25 важнейших действий, связанных с вопросами управления HSE по контракту, вместе с любыми конечными результатами и соответствующими справочными документами, которые можно получить в интранет-системе PDO. См. Приложение G для получения помощи в доступе к PDO и Shell Web. Документы.
 Часть I описывает задачи, которые должны быть выполнены Держателями контрактов, от определения стратегии до закрытия контракта, чтобы гарантировать, что Подрядчики достигнут тех же (или более высоких) стандартов HSE, что и требуемые PDO для его собственных операций. Процедура основана на плановом подходе с уделением внимания вопросам ОТ, ПБ и ООС на ранних этапах контракта, чтобы должным образом решать вопросы ОТОСБ на протяжении всего контрактного процесса.
 Приложение H Контрольный лист держателя контракта и RASCI
 Часть II упоминается в документе GU-140 C-09 Требования HSE, чтобы позволить Подрядчикам вместе с Держателями контрактов выполнять предписанные PDO мероприятия по HSE в порядке и в соответствии с уровень, требуемый PDO.Особое внимание в этом разделе уделяется деталям, приведенным для подготовки Плана ОТОСБ Подрядчика.
 Входные данные для каждой фазы контракта и глубина анализа (Задачи) в первую очередь зависят от уровня риска HSE, представленного действиями контракта, который, следовательно, определяет действия и входные данные, необходимые для выполнения контракта.
Добавить комментарий 
Ваш адрес email не будет опубликован. Обязательные поля помечены *