i

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

* Кэш должен очищаться по двум условиям (не по одному из, а именно по двум):
- Время.
- Протухание по бизнес логике.
Разрешается по только времени в безвыходных ситуациях, но тогда время - короткий период.
- При расчете ключей кэша должна использоваться переменная из конфигурации приложения (на случай обновлений кэш сбрасывается кодом, а не флашем кэш-сервера). В случае использования множества серверов - это очень удобный и гибкий инструмент при диплое.

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Проблема решена:
Переустановил NodeJS
Обновил версию npm

Нашел сам.Возможно это не правильно,но решение работает.Может кому пригодится.

Путь /public_html/classes/modules/filemanager
Файл class.php

Строка $block_arr['download_link'] = $this->pre_lang."/filemanager/download/$element_id/";

У БЭМ не существует глубокой вложенности!
Блок -> Элемент
Всё.

Из этого и исходите.

Например

<div class="section">
  <div class="title">
    <h2>Заголовок</h2>
    <div class="title__subtitle">Подзаголовок</div>
  </div>
  <div class="inner features">
    <div class="features__item">
      <div class="block">
        <div class="block__icon">
          <img class="block__image" src="images/icon1.png" alt="" />
        </div>
        <div class="block__text">Текст текст текст текст текст</div>
      </div>
    </div>
    <div class="features__item">
      <div class="block">
        <div class="block__icon">
          <img class="block__image" src="images/icon1.png" alt="" />
        </div>
        <div class="block__text">Текст текст текст текст текст</div>
      </div>
    </div>
  </div>
</div>

Попробуйте давать путь:
$photo = "./image/dtgf/hg.jpg";

Нет, так как у вас получаются элементы__элементов.

Можно почитать:
Соглашение по именованию
Почему в БЭМ не рекомендуется создавать элементы э...

В вашем случае, это выглядело бы так:

<header>
    <div class="wrapper">
        <div class="header-topblock clearfix">
            <div class="header-topblock__logo">
                <p class="header-topblock__slogan">текст»</p>
            </div>
                
            <div class="header-topblock__searchform"></div>
                
            <div class="header-topblock__contacts">
                <a href="tel:54545" class="header-topblock__contacts_tel">54545</a>
            </div>       
        </div>
    </div>
</header>

Блок:
header-topblock

Элементы:
header-topblock__logo
header-topblock__searchform
header-topblock__contacts

Элемент с модификатором
header-topblock__contacts_tel

Во-первых, если request - это одноименный модуль из npm - то в параметр body он передает Buffer, если там json, то его надо спарситьvar clients = JSON.parse(body.toString()).data
Во-вторых, сам запрос асинхронный, проще всего обернуть его в промис, итого будет что-то вроде этого:

modules.define('clients', function(provide){

  provide({

    getClients() { //неименнованные функции - плохо для отладки, поэтому меняем на es2015 метод

      /* Получаем список суб-клиентов агенства (или представителей) */

        var sendQ = {
           "method": "GetClientsList",
           "token": ""
        };

        var options = {
          url: "САЙТ",
          method: "POST",
          headers: {
              'Content-Type': 'application/json; charset=utf-8',
              'Authorization': 'Bearer'
          },
          json: true,
          body: sendQ
        };

        //удалить, оно тут не надо
        //var clients = '';

        return new Promise((resolve, reject) => request(options, (err, res, body) => {
          if(err) {
            return reject(err); //прокидываем ошибку в промис
          }
          var clients = JSON.parse(body.toString()).data;
          var client = clients.map(a => a.Login);

          if(!client[0]) {
            console.log('Client list getty - OK - ' + client[0]);
            resolve(client[0]); //возвращаем client[0] из промиса
          } else {
            console.log('some problems');
            reject(new Error('some problems'));
          };
        })).then(client => {
      /* Список получен переходим к дальнейщим действиям */
        }).catch(err => {
          /* здесь обрабатываем ошибку */
        });
    }
  });
});

Данные для запроса /udata/content/menu/ берутся из модуля структура, выбираются все страницы у которых стоит галочка показывать в меню.
dev.docs.umi-cms.ru/spravochnik_makrosov_umicms/st...

Попробуйте посмотреть модуль Меню (если он есть в вашей редакции) /admin/menu/lists/

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

Для решения Вашей задачи я бы предложил найти в админке справочник "Наименование в заказе" и добавить в него поле auto и далее вести все операции с этим полем.

После колонок есть иконка редактирования состава колонок. Возможно, вам подойдет?

Если блоки одинаковые, и отличаются лишь содержанием, то это один блок с разным содержанием. Я так считаю.

У вас здесь 2 проблемы:

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

Проблема структуры не относится к BEM, она относится к семантике и SEO.

Если же не смотреть на структуру и тэги (использовать ли small внутри или span, заворчивать ли в article) — то вопрос в сущности нужны ли классы на динамическом контенте или нет. Учитывая, что контент динамический, и нет необходимости иметь классы на тэгах, то допустимо сделать каскад на тэги от некоторого блока: например, dynamic-content или content, text.

Почему именно теги? Потому что WYSIWYG по умолчанию генерирует теги. Но вы можете использовать какие-то доп. инструменты, которые подправят итоговый html, расставят классы и т.д. (например, с помощью инструментов типа https://github.com/posthtml/posthtml ).

При необходимости можно дополнительно пометить стили тегов классами.

<div class="text">
  <h1>Caption <small>Some Foo Bar</small></h1>
  <article>
    <p>Lorem ipsum...</p>
    <div class="text__p">Dolor sit...</div>
  </article>
</div>

.text h1, .text__title { /* main title styles */ }
.text h1>small, .text__sub-title { /* sub-title styles */ }
.text p, .text__p { /* paragraph styles */ }

Таким образом вы инкапсулируете все пользовательские стили в одном месте (одном блоке) и не имеете проблем с созданием контента.