Правила модуля: Модуль числа — урок. Математика, 6 класс.

Правила наименования и размещения вашего модуля Drupal 8

English

English

1. Главная
2. Документация с Drupal.org
3. Создание модулей для Drupal
4. Правила наименования и размещения вашего модуля Drupal 8

04/24/2020, by maria

Прежде чем вы начнете

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

Назовите свой модуль

Первый шаг в создании модуля — выбрать для него «короткое имя» или имя машины. Это имя машины будет использоваться в нескольких файлах и функциях вашего модуля, а ядро Drupal используется программно для обозначения вашего модуля.

Есть несколько важных правил, которым нужно следовать при выборе имени машины:

• Оно должно начинаться с буквы.
• Оно должен содержать только строчные буквы и подчеркивания.
• Оно не должен содержать пробелов.
• Оно должно быть уникальным. Ваш модуль не должен иметь такое же короткое имя, как любой другой модуль, тема или профиль установки, который вы будете использовать на сайте.
• Не должно быть каких-либо зарезервированных терминов: src, lib, vendor, assets, css, files, images, js, misc, templates, includes, fixtures, Drupal

Для этого случая мы выберем «hello_world» в качестве имени машины.

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

Создайте папку для вашего модуля

Учитывая, что мы выбираем имя машины «hello_world», запустите модуль, создав папку в вашей установке Drupal по пути: /modules/custom/hello_world или /sites/all/modules/hello_world. Вы можете опустить /custom/subfolder и поместить свой модуль в /modules/hello_worldfolder, но часто неплохо иметь выделенное место для ваших собственных модулей, поэтому вам не придется искать их среди других, загруженных из Drupal. орг.

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

Предыдущие версии Drupal требовали, чтобы пользовательские модули были расположены в /sites/all/modules, так как основные модули были расположены в /modules. Тем не менее, в Drupal 8 /modules теперь освобожден для ваших пользовательских и дополнительных модулей. Все основные модули и файлы библиотек теперь находятся в каталоге /core. В Drupal 8 вы все еще можете использовать лучшие практики Drupal 7/6 по размещению своих пользовательских и Drupal.org, добавленных (загруженных) модулей в /sites/all/modules, но вы также можете просто поместить их в каталог / modules, который имеет тот же эффект.

Наш пример модуля еще не работает, сначала нам понадобится файл .info.yml. Узнайте больше о том, как сообщить Drupal 8 о вашем модуле с помощью файла .info.yml. Мы активируем модуль позже в руководстве.

Стандарты кодирования

Мы настоятельно рекомендуем вам придерживаться стандартов кодирования Drupal при написании собственных пользовательских модулей. Это требование для любых предложений по изменению кода ядра Drupal, а также рекомендация для размещенного кода на drupal.org.

Смотрите также

• Отображение всех ошибок при разработке
• Стандарты кодирования

Source URL:

Naming and placing your Drupal 8 module

Source authors:

Gábor Hojtsy eojthebrave heather a. ross pfrenssen sidharrell fgm ttronslien Rade tvn kunalkursija drupalisme renat rajveergang Deepak.Sharma

Drupal’s online documentation is © 2000-2020 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.0. PHP code is distributed under the GNU General Public License.

 

Правила установки модульного оборудования от Schneider Electric

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

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

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

Одним из примеров таких разработок стала DIN-рейка. Немецкие инженеры придумали конструкцию, на которую монтируются электротехнические модули при помощи специальных фиксаторов, что позволяет быстро снять или поставить оборудование. Эта концепция получилась настолько удачной, что в 1981 году Международная электротехническая комиссия (МЭК) разработала  международный стандарт, благодаря которому DIN-рейка получила широкое распространение во всем мире.

В России DIN-рейка была «легализована» в 2004 году со вступлением в силу стандарта ГОСТ Р МЭК 60715-2003. Для нашей страны официально приняты следующие типы реек: ТН15, Тh45, ТН75, С20, С30, С40, С50, G32. Первые одна-две буквы показывают форму профиля, причем эта форма как раз соответствует форме буквы, TH обозначает профиль «омега». Цифры после букв показывают округленное значение ширины передней части рейки, выраженное в миллиметрах. Наибольшее распространение получила рейка ТН35 с шириной передней части 35,3 мм, далее мы будем вести повествование на ее примере.

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

Правило 1. Обязательно составьте подробную электрическую схему собираемого щита

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

Правло 2. Заранее определите максимальное количество модулей в щите

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

Двухполюсный автоматический выключатель, АВДТ (автоматический выключатель дифференциального тока «диференциальный автомат») или ВД (выключатель дифференциальный  УЗО — «устройство защитного отключения») для однофазной сети, как правило, занимают на рейке в два раза больше места — 36 мм. Трехполюсный ВД занимает 3×18 мм = 54 мм, и т. д. Например, если заявлено, что щиток рассчитан на 12 модулей, то в него поместится 12 однополюсных автоматических выключателей или только 3 четырехполюсных автоматических выключателя.

Дифференциальные автоматические выключатели Easy9 от Schneider Electric — бюджетный вариант модульной коммутационной аппаратуры для установки на DIN-рейку

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

Рекомендуется выбирать распределительный щит с вместимостью примерно на 15 — 20% больше требуемой, чтобы при необходимости можно было осуществить модернизацию.

Убедитесь, что выбранная вами модель щита подходит по напряжению и максимальным токам, протекающим через защитный автомат на входе. Также щит должен иметь уровень защищенности от пыли и воды в соответствии с местом расположения (для улицы рекомендуется IP65).С тех сторон, где вы планируете подводить проводники, должны быть заделы под отверстия. Для щитов IP65 ввод проводником должен выполняться через герметичные кабельные вводы. Идеальный вариант (особенно для встраиваемых в стену щитов) — наличие специальной вводной камеры с отдельной крышкой.

Pragma от Schneider Electric — серия пластиковых корпусов щитов на 13, 18 и 24 модуля для предприятий сферы услуг и жилых помещений высокого класса

Правило 3. Размещайте модули в щите упорядочено

 На DIN-рейке модули можно располагать в произвольном порядке, но лучше использовать определенные сложившиеся правила, которые, хотя не закреплены напрямую в стандартах, тем не менее, приняты большинством электромонтажников (далее мы увидим, что взялись они не на пустом месте). Благодаря этому другому электрику будет проще работать с результатами вашего труда, да и вы сами, выработав определенные правила, сможете проще переходить от одного проекта к другому. В том случае, если модули соединены последовательно, они располагаются в последовательности слева-направо и снизу-вверх. Например, вводной автоматический выключатель, согласно этому правилу, всегда должен находиться на левом крае DIN-рейки, а, если в щите несколько DIN-реек — в левом верхнем углу. ВД, обслуживающие группы розеток, каждая из которых имеет свой защитный автомат, размещаются всегда левее (или выше) указанных автоматов. Если потребители группируются по типу устройств, сначала идут модули, к которым подключено освещение, потом те, к которым подключены универсальные розетки, а далее — устройства, требующие специальных мер защиты вроде нагревательного котла или стиральной машины.

Acti9 iPC — розетки для распределительных щитов

Для модулей, у которых направление подключения не играет роли, принимают, что входом является верхняя группа клемм, а выходом — нижняя. Это требование связано с тем, что у модулей верхняя группа клемм обычно соединена с неподвижными контактами. Согласно ПУЭ (правилам устройства электроустановок), издание 7, пункт 3.1.6, питающие проводники должны, как правило, подключаться к неподвижным контактам. Собственно, отсюда также и идет уже упоминавшееся правило размещение модулей в порядке сверху вниз в щитах с несколькими рейками.

Правило 4. Визуально выделяйте группы модулей

Для предотвращения сдвига модулей по рейке используются разделители (иначе именуемые стопорами) в начале и конце, чтобы предотвратить такой сдвиг. Такие разделители могут устанавливаться не только по краям рейки, но и между модулями, создавая между ними промежутки. Это позволяет использовать разделители для визуального выделения групп модулей.

Правило 5. Избегайте путаницы в межсоединениях

Специалисты-практики считают, что внутренние межсоединения в щитке лучше выполнять одножильным проводом. Благодаря дому, что одножильный провод «держит форму», разбираться в монтаже гораздо проще.

При большом количестве модулей (порядка нескольких десятков) разводить межсоединения жестким одножильным проводом неудобно, поэтому применяют гибкий многожильный провод. Для надежности контакта концы провода опрессовываются специальными колпачками. Избежать путаницы при использовании гибких многожильных проводов помогут кабельные стяжки. Особенно удобны многоразовые стяжки Schneider Electric Rapstrap. В том случае, если устанавливаются большие группы защитных автоматов, для межсоединений рекомендуется использовать специальные гребенки.

Правило 6. Снимайте изоляцию только стриппером

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

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

Правило 7. Для затягивания контактов используйте динамометрическую отвертку

Для большей надежности и меньшего электрического сопротивления нужно посильнее затягивать контакты в модулях. Модули малоизвестных производителей допускают крутящий момент 1 Нм; модули от большинства ведущих брендов — 2 Нм; некоторые модули Schneider Electric на ток 32А и выше — до 3,5 Нм. Но слишком большое усилие может привести к поломке модуля, почему неопытные электромонтажники боятся слишком сильно затягивать контакты, снижая тем самым надежность соединения.

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

Правило 8. Будьте внимательны при подключении двух проводников в одну клемму

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

Правило 9. Используйте маркировку кабелей и модулей

Даже в самом простом проекте не пренебрегайте маркировкой как кабелей, так и модулей. Не лишним будет маркировка и межсоединительных проводов внутри щита. На модулях должны быть нанесены надписи, однозначно описывающие потребителей, которые к ним подключены. Если на модулях нет места для надписей, модули нумеруются и составляется таблица соответствия номеров и предназначения модулей. Эти требования записаны в ГОСТ и Правилах технической эксплуатации электроустановок потребителей.

Цветовая маркировка нулевого и фазных проводов, а также провода защитного заземления внутри щита должна соответствовать ГОСТ Р50462-92. Например, при однофазной системе голубым цветом обозначают нулевой провод, сочетанием желтого и зеленого — провод заземления. В том случае, если ГОСТ допускает вариативность цветовой маркировки провода (например, для фазного провода в однофазной системе допускаются белый, коричневый, а в ряде случаев и некоторые другие цвета), маркировка в щите должна быть единообразной — должен использоваться только один из допустимых цветов. Действующие ПУЭ допускают цветовую маркировку провода только на концах, но мы настоятельно рекомендуем использовать провода в цветной изоляции, благо, в продаже сейчас есть установочные провода всех стандартных цветов.

Правило 10. После окончания сборки щита сохраните его схему

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

11.9. [DKSF 60.5 IU] Примеры настройки модуля «Логика»

На данной странице представлены несколько простейших примеров настройки модуля «Логика».

Настройка термостата

Устройство NetPing с подключенным к нему внешним термодатчиком позволяет выполнять функции термостата, поддерживая указанный ему диапазон температур путём включения/выключения устройства подогрева и/или охлаждения в автоматическом режиме.

Задача: В помещении необходимо постоянно поддерживать температуру 20°C.

Решение: Предположим, что к управляемой розетке №1 устройства NetPing подключен электрический нагреватель, который отапливает некое помещение. В помещении установлен кондиционер, который управляется внешним модулем ИК управления IRC-TR v2. Чтобы автоматизировать управление нагревателем и кондиционером для поддержания необходимой температуры необходимо зайти на страницу «ЛОГИКА» web-интерфейса устройства:

Активировать чек-боксами четыре первых правила и выполнить следующие настройки:

Данные правила означают, что, если установленная температура в термостате 1 (TSTAT1) будет выше заданной (то есть, выше 20°C), произойдет автоматическое выключение электрического нагревателя (RELAY 1) и включение кондиционера (IR 1) (правила №1 и №3). Чтобы не происходило частое включение/выключение нагревателя и кондиционера в термостате присутствует гистерезис переключения, об этом ниже. Если установленная температура будет ниже заданной произойдет выключение кондиционера (IR 2) и включение нагревателя (RELAY 1) (правила №2 и №4).

После настройки правил необходимо нажать кнопку «Применить изменения».

Следующим этапом необходимо настроить модуль «ТЕРМО(ГИДРО)СТАТ», на основании которого будут отрабатывать уже настроенные правила логики:

Для измерения температуры в помещении используется термодатчик №3. В модуле «ТЕРМО(ГИДРО)СТАТ» нужно настроить TSTAT1, выбрав из выпадающего списка датчик №3. Далее указать порог 20°C и гистерезис переключения 2°C.

Гистерезис задаёт «коридор» вблизи заданной температуры, в пределах которого термостат не реагирует на колебания температуры. Эта функция позволяет избежать частых случайных переключений нагревателя (охладителя) из-за естественных спонтанных колебаний измеряемой датчиком температуры.

Если текущий статус термостата «выше», то порогом переключения статуса служит заданная температура, пониженная на значение гистерезиса. И наоборот, если текущий статус «ниже», порогом переключения служит заданная температура, повышенная на значение гистерезиса. Как только температура, повышаясь или понижаясь, достигает значения порога с учётом гистерезиса и, таким образом, выходит за пределы «коридора», статус термостата изменяется на противоположный.

После настройки термостата необходимо нажать кнопку «Применить изменения».

Запись, сохранение и воспроизведения ИК команд для управления кондиционером указана в соответствующем разделе руководства (справедливо для устройств с поддержкой модуля ИК управления IRC-TR v2).

Помимо указания реле в качестве «выхода» правила, необходимо указать, что данное реле будет использоваться совместно с модулем логики. Для этого необходимо перейти на страницу «УПРАВЛЕНИЕ 220V» web-интерфейса устройства и выбрать режим управления реле «Логика»:

После выбора режима управления реле необходимо нажать кнопку «Применить изменения».

Завершающим этапом настройки является запуск логики на соответствующей странице web-интерфейса путем нажатия кнопки «Пуск»:

Пример оповещения звуковой сигнализации при срабатывании датчика удара

Устройство NetPing, к которому подключены датчик удара PI-90D и сигнальная сирена АС-10, может выполнять охранные функции на удаленных объектах и в шкафах с оборудованием.

Задача: Организация звукового оповещения на пульт диспетчера охраны при взломе коммутационного шкафа с оборудованием.

Решение: Предположим, что к IO линии №2 устройства NetPing подключен датчик удара PI-90D, который установлен в шкафу с оборудованием, а к Реле 1 подключена сигнальная сирена АС-10, которая выведена на пульт диспетчера охраны. Чтобы настроить NetPing для охранных мероприятий, необходимо в модуле «Логика» настроить соответствующие правила:

Данные правила означают, что при срабатывании датчик удара PI-90D (IO 2) будет активирована сигнальная сирена АС-10 (RELAY 1) (правило №1) на время, пока уровень IO линии №2 не будет равен значению «лог.1» (правило №2).

После настройки правил необходимо нажать кнопку «Применить изменения».

Следующим этапом необходимо настроить режим работы IO линии на странице «ВВОД-ВЫВОД» web-интерфейса устройства. IO линия должна работать в режиме «вход»:

Помимо указания реле в качестве «выхода» правила, необходимо указать, что данное реле будет использоваться совместно с модулем логики. Для этого необходимо перейти на страницу «УПРАВЛЕНИЕ 220V» web-интерфейса устройства и выбрать режим управления реле «Логика»:

 После выбора режима управления реле необходимо нажать кнопку «Применить изменения».

 

Завершающим этапом настройки является запуск логики на соответствующей странице web-интерфейса путем нажатия кнопки «Пуск»:

 

Пример оповещения звуковой сигнализацией при срабатывании датчика дыма

Ознакомиться с данным примером можно в официальном блоге компании по следующей ссылке: http://www.netping.ru/Blog/primer-opoveshheniya-zvukovoj-signalizaciej-pri-srabatyvanii-datchika-dyma

погрузчиков | webpack

Загрузчики — это преобразования, применяемые к исходному коду модуля. Они позволяют предварительно обрабатывать файлы по мере их импорта или «загрузки». Таким образом, загрузчики похожи на «задачи» в других инструментах сборки и предоставляют мощный способ обработки этапов сборки интерфейса. Загрузчики могут преобразовывать файлы с другого языка (например, TypeScript) в JavaScript или загружать встроенные изображения в виде URL-адресов данных. Загрузчики даже позволяют вам делать такие вещи, как , импортировать файлов CSS прямо из ваших модулей JavaScript!

Пример

Например, вы можете использовать загрузчики, чтобы указать веб-пакету загрузить файл CSS или преобразовать TypeScript в JavaScript. Для этого вы должны начать с установки необходимых загрузчиков:

 npm install --save-dev css-loader ts-loader 

А затем указать веб-пакету использовать css-loader для каждого файла .css . и ts-loader для всех файлов .ts :

webpack.config.js

 module.exports = {
  модуль: {
    правила: [
      { тест: /\.css$/, используйте: 'css-loader' },
      { тест: /\.ts$/, используйте: 'ts-loader' },
    ],
  },
}; 

Использование загрузчиков

Существует два способа использования загрузчиков в приложении:

• Конфигурация (рекомендуется): укажите их в файле webpack. config.js .
• Встроенный: Укажите их явно в каждом операторе import .

Обратите внимание, что загрузчики можно использовать из CLI в webpack v4, но эта функция устарела в webpack v5.

Конфигурация

module.rules позволяет указать несколько загрузчиков в конфигурации вашего веб-пакета. Это лаконичный способ отображения загрузчиков, помогающий поддерживать чистоту кода. Он также предлагает вам полный обзор каждого соответствующего погрузчика.

Загрузчики оцениваются/выполняются справа налево (или снизу вверх). В приведенном ниже примере выполнение начинается с sass-loader, продолжается с помощью css-loader и, наконец, заканчивается с помощью style-loader. См. «Возможности загрузчика» для получения дополнительной информации о порядке загрузчиков.

 модуль.экспорт = {
  модуль: {
    правила: [
      {
        тест: /\.css$/,
        использовать: [
          // [загрузчик стилей](/загрузчики/загрузчик стилей)
          {загрузчик: 'стиль-загрузчик'},
          // [css-загрузчик](/loaders/css-загрузчик)
          {
            загрузчик: 'css-загрузчик',
            опции: {
              модули: правда
            }
          },
          // [sass-загрузчик](/loaders/sass-загрузчик)
          {загрузчик: 'sass-загрузчик'}
        ]
      }
    ]
  }
}; 

Встроенный

Можно указать загрузчики в операторе import или любом эквивалентном методе «импорта». Отделите загрузчики от ресурса с ! . Каждая часть разрешается относительно текущего каталога.

 импортировать стили из 'style-loader!css-loader?modules!./styles.css'; 

Можно переопределить любые загрузчики, preLoaders и postLoaders из конфигурации, добавив префикс встроенного оператора import :

• С префиксом ! отключит все настроенные обычные загрузчики

   импорт стилей из '!style-loader!css-loader?modules!./styles.css'; 

• С префиксом !! отключит все настроенные загрузчики (preLoaders, loaders, postLoaders)

   импорт стилей из '!!style-loader!css-loader?modules!./styles.css'; 

• Префикс с -! отключит все настроенные preLoaders и loaders, но не postLoaders

   импортировать стили из '-!style-loader!css-loader?modules!./styles.css'; 

Параметры могут быть переданы с параметром запроса, например. ?key=value&foo=bar или объект JSON, например. ?{"ключ":"значение","foo":"бар"} .

Особенности загрузчика

• Загрузчики могут быть объединены в цепочку. Каждый загрузчик в цепочке применяет преобразования к обрабатываемому ресурсу. Цепочка выполняется в обратном порядке. Первый загрузчик передает свой результат (ресурс с примененными преобразованиями) следующему и так далее. Наконец, webpack ожидает, что последний загрузчик в цепочке вернет JavaScript.
• Загрузчики могут быть синхронными или асинхронными.
• Загрузчики запускаются в Node.js и могут делать там все, что возможно.
• Загрузчики можно настроить с помощью объекта options (использование параметров запроса для установки параметров по-прежнему поддерживается, но не рекомендуется).
• Обычные модули могут экспортировать загрузчик в дополнение к обычному main через package.json с полем loader .
• Плагины могут предоставить загрузчикам больше возможностей.
• Загрузчики могут создавать дополнительные произвольные файлы.

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

Разрешение загрузчиков

Загрузчики соответствуют стандартному разрешению модуля. В большинстве случаев он будет загружен из пути к модулю (например, npm install , node_modules ).

Ожидается, что модуль загрузчика экспортирует функцию и будет написан на совместимом с Node.js JavaScript. Чаще всего они управляются с помощью npm, но вы также можете иметь собственные загрузчики в виде файлов внутри вашего приложения. По соглашению загрузчики обычно называются xxx-loader (например, json-loader ). См. «Написание загрузчика» для получения дополнительной информации.

Редактировать эту страницу · Напечатать эту страницу

15 Участники

Правила модуля для ставок в заголовке

• Основные ценности Prebid. org
• Правила модуля
  • Глобальные правила модуля
  • Правила адаптера претендента
  • Правила адаптера аналитики
  • Правила субмодуля идентификатора пользователя
  • Правила модуля данных реального времени
  • Прочие модули
• Раскрытие информации
• Дополнительное чтение

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

Тип модуля	Описание	Прицел
Адаптер для ставок	Получает ставки открытого рынка или частного рынка для текущего запроса объявления.	Prebid.js, сервер Prebid
Аналитический адаптер	Прослушивает события аукциона и отправляет отчеты в аналитическую систему.	Prebid.js, сервер Prebid
Субмодуль идентификатора пользователя	Получает идентификатор для этого пользователя и делает этот идентификатор доступным для других типов модулей.	Prebid.js
Субмодуль данных реального времени	Получает данные для контекста текущего пользователя, которые могут представлять интерес для рекламодателей.	Prebid.js
Прочее	Модули, которые не попадают ни в одну из других категорий.	Prebid.js

Основные ценности Prebid.org

Необходимы специальные технические правила для управления разработкой и рассмотрением модулей, чтобы гарантировать их соответствие Основным ценностям Prebid. Основная цель Prebid.org — сделать замечательную технологию Header Bidding доступной для веб-издателей и разработчиков мобильных приложений. Мы считаем, что передовые технологии это:

• Эффективность — Продукты, предлагаемые Prebid. org, не должны нагружать пользовательское устройство, сеть или сервер компании.
• Безопасный — Программное обеспечение Prebid.org не должно открывать двери для угроз безопасности, включая электронные атаки, отказ в обслуживании, мошенничество или утечку данных.
• Прозрачный — Наши продукты разрабатываются открыто и проверяются сообществом. Изменения в программном обеспечении и модулях Prebid должны быть открыты для проверки до и после выпуска.
• Удовлетворительно — Платформа Prebid.org не отдает предпочтение какой-либо одной организации перед другой. Ни одна сущность не может быть предпочтительнее другой в техническом заказе или статусе в качестве значения по умолчанию. Ни один объект не может получить информацию о другом объекте без одобрения.
• Совместная работа . Взаимодействие с людьми на форумах и мероприятиях Prebid.org должно быть вежливым.
• Конфиденциальность . Наши продукты созданы для издателей, чтобы поддерживать конфиденциальность пользователей и соответствовать отраслевым стандартам.

Правила модуля

Адаптеры ставок, адаптеры идентификаторов пользователей, адаптеры аналитики и другие модули будут проверены на соответствие Основным ценностям Prebid.org.

Этот набор правил модуля применяется как к Prebid.js, так и к Prebid Server. Однако эти правила не обязательно применяются к инструментам или Prebid Mobile SDK. Правила и рекомендации для этих продуктов будут определяться соответствующими комитетами по мере необходимости.

Использование терминов «должен» и «следует» в этом документе преднамеренно. Тем не менее, некоторые из правил являются «желательными», поскольку мы знаем, что существуют существующие исключения из правила, которые со временем необходимо будет устранить. Они отмечены звездочкой (*). Цель:

• Каждый новый модуль соответствует всем необходимым правилам.
• Даже устаревшие модули должны соответствовать всем правилам Prebid.
  js 5.0.

Глобальные правила модуля

1. Модули не должны (*) загружать внешние файлы кода, если эти библиотеки не одобрены и не имеют открытого исходного кода.
   1. Внешние модули могут использоваться во время сборки по усмотрению соответствующего предтендерного комитета. Модули времени сборки должны быть привязаны к конкретной версии, поэтому любые обновления должны выполняться через запрос на включение Prebid.
   2. Исключения могут быть сделаны в следующих случаях:
      • Когда издатель контролирует, загружается ли файл и какая его версия, базовый модуль должен иметь возможность работать без вспомогательного файла.
      • Если для аукциона не требуется исполняемый код, он должен поддерживать отложенную загрузку. Например. Модули идентификатора пользователя.
      • Загружаемый файл должен быть привязан к определенной версии, чтобы любые обновления выполнялись с помощью запроса на вытягивание Prebid.
      • Необходимо сделать заметное сообщение о загрузке файла и о том, зачем им нужен файл, а также предоставить предупреждение о размере, если он превышает 10 КБ.
   3. Если функциональность поддерживается ядром Prebid или существующим модулем, модули Prebid должны отдавать предпочтение версии Prebid этой функциональности, а не версии с внешним кодом.
   4. Должна быть раскрыта информация о загрузке обязательных или необязательных внешних файлов во время сборки или во время выполнения. (См. раздел раскрытия информации ниже.)
   5. Модули не должны импортировать другие модули Prebid во время сборки.
2. Модули не должны (*) добавлять какие-либо пиксели, iframe, файлы cookie или локальное хранилище непосредственно на страницу. Скорее, они должны использовать предоставляемые оболочкой механизмы для синхронизации пользователей, файлов cookie и локального хранилища.
3. Модули должны использовать функции связи, предоставляемые ядром Prebid (как Prebid. js, так и Prebid Server) для внешней связи.
4. Модули Prebid.js не должны использовать переменную \(PREBID_GLOBAL\) или иным образом получать указатель на глобальный объект PBJS. Это сохраняет целостность данных.
5. Все модули должны поддерживать создание нескольких параллельных экземпляров. Это означает, например, что они не могут полагаться на изменяемые глобальные переменные.
   • Запись в объект глобального окна должна быть ненавязчивой, открытой и выполняться таким образом, чтобы поддерживать несколько экземпляров.
6. Все модули и любые внешние ссылки на код должны раскрывать информацию о том, что они поддерживают положения о конфиденциальности, такие как GDPR, CCPA, COPPA и т. д. (см. раздел раскрытия информации ниже).
7. Ответы на запросы аукциона или данных должны быть сжаты, если клиент поддерживает эту функцию (например, gzip, сжатие, дефляция).
8. Запросы и ответы Prebid.js должны быть защищены HTTPS. Запросы Prebid Server должны быть HTTPS.
9. Конечные точки должны использовать HTTP/2 с сообщениями проверки активности, чтобы не нужно было повторно создавать соединения.
10. Чтобы модуль был размещен на веб-сайте Prebid.org, он должен находиться в репозитории Prebid с открытым исходным кодом.
11. Каждый модуль должен содержать информацию о сопровождающем с групповым адресом электронной почты, чтобы Prebid.org мог связаться для поддержки или обслуживания.
12. Модули не должны включать полифиллы или переопределять стандартные функции или функции Prebid JavaScript.
13. Внешние модули не должны использовать функцию getEidPermissions модуля userId (например, prebidServerBidAdapter является внутренним модулем предварительной заявки).

Правила адаптера аукциона

1. Применяются все глобальные правила.
2. Адаптеры ставок должны(*) иметь возможность делать ставки. Если они не могут вернуть аукционную ставку, им следует рассмотреть возможность интеграции в качестве модуля данных в реальном времени или другого типа.
3. Сценарии рендеринга креативов должны(*) загружаться из фрейма креатива, а не непосредственно на странице. Другими словами, творческий рендеринг JavaScript не может использоваться для обхода правила «без внешнего кода».
4. Модули участников торгов не должны(*) делать запросы к конечным точкам для других функций, кроме аукционов, без:
   1. Раскрытие информации
   2. Возможность для издателя контролировать дополнительные функции.
   3. Обеспечение работоспособности аукционов, если издатель отключил дополнительный функционал; то есть адаптеры ставок могут регистрировать определенные события аналитики, но если издатель отключает их, аукцион все равно должен состояться.
   4. Создание подмодуля данных в реальном времени, который получает данные таким образом, чтобы их могли использовать и другие участники торгов, если участник торгов хочет включить выборку внешних данных, которая повлияет на аукцион.
5. Модули участника торгов не должны получать информацию о ставках от других участников аукциона или о них. Например, они не могут прослушивать события рекламного сервера и пересылать информацию с именами других участников торгов обратно на свою конечную точку — это работа модуля аналитики.
6. Модули участников торгов не должны (*) кэшировать ставки с предыдущих аукционов. Эта функциональность зарезервирована для ядра Prebid.
7. Участники торгов должны(*) принимать параметры в обычном месте, а не параметры, определенные участником торгов. Список этих параметров есть в документации к адаптеру бидера.
8. Участники торгов не должны переопределять стандартные значения таргетинга сервера объявлений: hb_adid, hb_bidder, hb_pb, hb_deal или hb_size, hb_source, hb_format.
9. Если адаптеры ставок сообщают о нескольких типах мультимедиа в формате hb_format как «баннер», они должны (*) указывать фактический тип мультимедиа в объекте метаданных. Одним из вариантов использования этого является то, что он позволяет издателям управлять тем, какие креативы поддерживают безопасные кадры.
10. Модули участника торгов должны предоставлять метаданные покупателя, включая рекламодателя, домен рекламодателя, сеть, фактический тип носителя и другие данные, определенные в документации Prebid.
11. Возвращаемые креативы должны быть полностью HTTPS.

Правила адаптера Analytics

1. Применяются все глобальные правила.
2. Адаптеры Analytics не должны делать ставки или предоставлять какие-либо параметры для аукциона.
3. Адаптеры Analytics должны быть нейтральными по отношению к адаптерам ставок — никоим образом не отдавать предпочтение какому-либо конкретному участнику торгов.
4. Адаптеры Analytics должны свести к минимуму количество обращений к своим конечным точкам, группируя данные об аукционах и событиях.

Правила подмодуля идентификатора пользователя

1. Применяются все глобальные правила.
2. Подмодули ID не должны собирать какую-либо информацию со страницы, за исключением утвержденных издателем данных ID для этого пользователя.
Подмодули идентификаторов
3. не должны сообщать аналитическую информацию своим конечным точкам, включая использование других идентификаторов пользователей, информацию об аукционах, участниках торгов, выигранных ставках и т. д. Это работа модуля аналитики.
Субмодули идентификатора
4. должны быть нейтральными по отношению к адаптерам заявок — каждый участник торгов должен иметь одинаковую возможность использовать каждый идентификатор пользователя.

Правила модуля данных реального времени

1. Применяются все глобальные правила, за одним исключением:
   • Модуль данных в реальном времени может загружать внешний код, если для этого требуется регистрация издателя, а в документации к модулю есть заметное раскрытие информации. Идея состоит в том, что издатель не будет включать модуль, если он не одобряет внешний код, а поскольку он зарегистрировался в службе, он должен одобрить его. Текст раскрытия информации может отличаться, если поставщик разрешает Prebid проводить регулярные проверки проприетарной библиотеки со строгой версией.
2. Модули данных в реальном времени (RTD) не должны участвовать в торгах. Эта функция зарезервирована для адаптеров ставок.
Модули RTD
3. не должны предоставлять конфиденциальную информацию о пользователе (включая идентификаторы) на аукционе. Эта функциональность зарезервирована для модулей User ID.
Модули RTD
4. должны по возможности предоставлять данные в перекрестном режиме. Например, передача данных через существующие механизмы, такие как First Party Data.
Модули RTD
5. могут кэшировать метаданные ставок для целей аналитики и оптимизации. Они могут использовать эти ставки для оптимизации будущих аукционов, в которых принимают участие участники торгов и адуниты. Они не должны повторно использовать определенные прошлые ставки на аукционе — эта функциональность ограничена ядром Prebid.

Другие модули

Любой другой тип модуля будет оцениваться в каждом конкретном случае. Примеры других модулей включают «Валюта», «Показ видеорекламы», «Управление согласием» и т.  д. Все эти модули должны соответствовать глобальным правилам.

Раскрытие информации

Уже есть исключения из этих правил, и мы понимаем, что, вероятно, их будет больше. Любой модуль, делающий что-то, что необходимо раскрыть, получит метку в своей документации prebid.org, например:

9.0035 Раскрытие информации: этот адаптер аукциона загружает внешний JavaScript для отображения объявлений.
• Раскрытие информации: этот участник торгов записывает события выигрыша и проигрыша с вызовом пикселя.
• Раскрытие информации: этот участник торгов напрямую прослушивает события Google Ad Manager.
• Раскрытие информации: этот участник торгов сообщает о тайм-ауте.

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

Чтобы справиться с этим, мы планируем:

1. Задокументировать отдельный набор раскрытий с руководством для рецензентов о том, как определить, какие раскрытия необходимы.
2. Создайте процесс для создания новых типов раскрытий и того, какие модули получили данное раскрытие/исключение и на какую дату.
3. Убедитесь, что раскрытие применяется ко всем существующим и новым псевдонимам адаптеров.

• Добавление адаптера ставок: Prebid.js, Prebid Server
• Добавление адаптера аналитики: Prebid.js, Prebid Server

Знакомство с модулем правил

Этот двухчасовой веб-семинар будет посвящен основам модуля правил Drupal и тому, как его можно использовать для добавления мощных настраиваемых функций на веб-сайт. На вебинаре будут представлены основные принципы модуля «Правила», включая методологию «Событие-Условие-Действие» (ECA), а также использование запланированных компонентов.

Модуль «Правила» построен на основе мощного API, позволяющего глубоко интегрировать другие модули. Drupal Commerce, Content Access, Flag и Organic Groups обеспечивают встроенную интеграцию правил.

##Что мне может сделать модуль «Правила»?

При работе с веб-сайтом Drupal администраторы обычно всегда ищут способы получить немного больше функциональности или автоматизировать повторяющиеся задачи. Часто предоставляемые модули могут обеспечить большую часть этой функциональности, но иногда желательны меньшие, более пользовательские части функциональности. В то время как пользовательские модули часто пишутся, чтобы заполнить эту пустоту, не все умеют писать PHP-код или знакомы с Drupal API. К счастью, модуль «Правила» иногда может заполнить пробел.

На этом вебинаре мы рассмотрим основные принципы модуля «Правила», а затем создадим различные примеры, демонстрирующие впечатляющие возможности этого модуля.

Основные понятия

Зависимости

Для модуля «Правила» требуется модуль Entity API. Модуль Views также рекомендуется при использовании модуля Rules Scheduler (часть основного пакета модуля Rules).

Событие-Условие-Действие

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

• Событие: узел статьи сохранен → Условие: узел статьи не опубликован → Действие: отправьте редактору контента сообщение с просьбой просмотреть узел статьи
• Событие: узел статьи сохранен → Условие: пользователь, сохранивший узел статьи, имеет роль «администратор контента» → Действие: узел статьи опубликован
• Событие: пользователь присоединяется к органической группе → Условие: у пользователя нет роли «администратор» → Действие: отправить пользователю приветственное сообщение
• Событие: создан узел элемента календаря → Условие: узел элемента календаря не имеет заполненного поля «Повестка дня» → Действие: отправьте автору сообщение за два дня до даты элемента календаря с напоминанием о заполнении поля «Повестка дня»
• Событие: создается запись в журнале → Условие: серьезность записи в журнале «аварийная» → Действие: отправить сообщение всем пользователям с ролью «администратор сайта»
• Событие: узел будет сохранен → Условие: поле изображения пусто → Действие: отобразить сообщение с вопросом, уверены ли они, что не хотят добавлять изображение

Компоненты правил

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

Когда модуль «Планировщик правил» включен, можно запланировать запуск компонентов в будущем. Это распространенный вариант использования компонентов правил. Например:

• Событие: узел создан → Условие: узел опубликован → Действие: закрыть комментарии → Запланировано: +2 недели с момента создания узла

Интерфейс пользовательского интерфейса правил

• Конфигурация основных правил в разделе «Конфигурация | Рабочий процесс | Правила» (/admin/config/workflow/rules)
• «Проект» правил содержит три модуля: правила, пользовательский интерфейс правил и планировщик правил.
• Правила «экспортируемые» — их можно экспортировать в текстовый файл и импортировать на другой сайт. Кроме того, экспортированные правила можно сохранить в коде (с помощью компонента или пользовательского модуля).
• Правила можно отключить, не удаляя их.

Советы и подсказки

Несмотря на то, что Rules является чрезвычайно мощным модулем, для его эффективного использования обычно требуется некоторый опыт. Вот несколько советов и приемов, которые помогут вам начать.

1. Самый важный совет по Правилам! При попытке доступа к определенному полю с помощью селектора данных в «действии» обычно требуется, чтобы условие «у объекта есть поле» было установлено для того же поля, чтобы оно работало в «действии». Например, если вы пытаетесь получить доступ к полю с именем «field_last_name» в действии, обязательно добавьте условие «У объекта есть поле» для «field_last_name».
2. Эффективное использование селекторов данных — ключ к написанию эффективных правил. Этот скринкаст — хороший ресурс для начала работы.

Примеры

Первоначальная настройка на новом сайте Drupal 7:

• Создание новых ролей: администратор контента (без дополнительных прав), автор («Статья: создать новый контент», «Статья: изменить собственный контент»)
• Создать нового пользователя с ролью «автор»
• Создать нового пользователя с ролью «администратор содержимого»

Уведомлять администраторов контента, когда новый контент публикуется не администраторами контента.

1. Перейдите в admin/config/workflow/rules и нажмите «Добавить новое правило»
2. Имя: Уведомлять администраторов контента о новом контенте
3. Событие: после сохранения нового содержимого
4. Условие: сущность имеет тип узла, селектор данных = узел (созданный контент), значение типа сущности = узел
5. Условие: Пользователь имеет роль(и), Селектор данных=узел:автор, Роли:администратор, администратор содержимого, Соответствие ролям значение=любое, Отменить
6. Действие: отправить письмо всем пользователям роли:

• Роли: администратор контента
• Тема: Новый контент!
• Сообщение: На сайте есть новый контент, [узел:название], [узел:url], Автор: [узел:автор]

Уведомлять администраторов сайта, когда сообщается о записи журнала с серьезностью «предупреждение» или «ошибка»

1. Перейдите в admin/config/workflow/rules и нажмите «Добавить новое правило»
2. Название: Уведомление о чрезвычайной ситуации
3. Событие: создается запись в системном журнале
4. Условие: сравнение данных, данные для сравнения: [запись в журнале: серьезность], значение данных: ошибка
5. Условие: сравнение данных, данные для сравнения: [запись в журнале: серьезность], значение данных: предупреждение
6. Добавить оба условия в группу «ИЛИ»
7. Шаги 4–6 также можно выполнить с помощью оператора «является одним из».
8. Действие: отправить письмо всем пользователям роли:

• Роли: администратор
• Тема: Проблема с сайтом!
• Сообщение: проблема с веб-сайтом была автоматически зарегистрирована. Подробности здесь: http://rules.dev/admin/reports/dblog

Закрыть комментарии к узлам через 2 недели

Создать компонент, чтобы закрыть комментарии

1. Перейдите в admin/config/workflow/rules/components и нажмите «Добавить новый компонент»
2. Плагин компонента: набор действий (поскольку наш компонент выполняет действие)
3. Имя: Закрыть комментарий к узлу
4. Переменные: Тип данных = Узел, Метка = Узел, Имя машины = узел, Использование = Параметр
5. Добавить действие: установить значение данных, селектор данных = узел: комментарий (комментарии разрешены), значение = 1 (закрыто)
6. Сохранить изменения

Откуда берется значение = 1 (закрыто) для узла: комментарий? Если вы проверите флажок «Настройка комментариев по умолчанию для нового контента» на странице настроек любого типа контента (например, admin/structure/types/manage/article), три возможных значения:

• Скрытый=0
• Закрыто=1
• Открыто=2 ​​

Немного черной магии, я знаю. ..

Создайте правило, чтобы закрыть комментарии к новым статьям через две недели

1. Перейдите в admin/config/workflow/rules и нажмите «Добавить новое правило»
2. Имя: Закрыть комментарии к статьям через 2 недели
3. Событие: после сохранения нового содержимого
4. Условие: содержимое имеет тип, селектор данных = узел, типы содержимого = статья
5. Условие: содержимое опубликовано, селектор данных = узел
6. Действие: Запланировать оценку компонента, значение = Закрыть комментарий к узлу, Запланировать дату оценки, значение = + 2 минуты (для тестирования), Идентификатор = Закрыть комментарий к статье — идентификатор узла: [узел: nid], Селектор данных узла = узел

Чтобы проверить это правило, создайте новый узел типа «статья», подождите 2 минуты, запустите cron и подтвердите, что комментарии закрыты. После тестирования отредактируйте «действие» и установите дату оценки «+ 2 недели».

Если позволяет время, можно создать второе правило для обновления «сброса часов» при закрытии комментариев при обновлении статьи.