coderiter

Все комментаторы совершили одни и те же ошибки управления потому что, при всем уважении, скорее всего за эти ошибки (в стратегировании) они не платят из своего кармана.

На пальцах отвечаю на ваш вопрос:

1) По структуре - при проверки качества кода / решения / задачи / продукта / настройки сервера и так далее нужно проходить по списку (чеклист) критериев контроля качества - обычно они выглядят как списки определенных параметров которые может замерить третье лицо или сама система - формат проверяемого параметра прямо вот соответсвует / не соответсвует. На сколько процентов пройден чеклист - на столько процентов результат "качественный"
2) Почему ребята ошиблись - потому что стали приводить конкретные списки. Дело в том что у каждого проекта / сиутации / команды / набора компетенций - свои наборы таких чеклистов на разные ситуации. В больших командах сущесвтует основной чеклист который регламентирует CodeReview - и за него отвечает как правило тим лид - он его обновляет, развивает, обосновывает внесенные правила и следит за тем чтобы ПЕРЕД началом разработки все разработчики были ЗАРАНЕЕ ОЗНАКОМЛЕНЫ с этим порятком проверки качества, а все потому что:
3) Количество стайлгайдов и критериев в приципе существует огромное количество - и то как каждому в одной части света / компании удобно делать одно дело - не регламентирует ни разу что именно так же другому человеку в другой ситуации применять эти правила к своему контексту. В виде открытых стайлгайдов они существуют для накопления практик и навыков в первую очередь для их же развития (процесс формулировки наводит порядок в голове) а также дают возможность "на них конкретно" нанизать точечные ответы огромного сообщества людей, и получить те самые разные взгляды на ситуации, и по возможности опять же привести к общему знаменателю. Но это все мелочи жизни, а в вашем случае вы совершите серьезную ошибку если прямо сейчас возьметесь (примите на себя ответственность) проверять чужой код на предмет оценки, потому что:
4) Вас явно используют как внешнего эксперта на которого можно сослаться, от которого можно получить якобы аргументацию для давления на свою позицию при решении какой-то возникшей ситуации во взаимоотношениях клиент-разработчик на проекте куда вас приглашают за экспертизой.
Если вы, не предупредив, о том что "качество кода" начинается с декларации этого качества (в случае если речь идет о проверке этого внутреннего качества в рамках сотрудничества, а не самих задач которые поставлены перед создаваемой системой - фичесов) - любая ваша оценка будет недостоверна контексту ее применения (вы напишете про строки или еще что-то - а у человека будут либо взыскивать деньги / либо недоплатят за работу / или инкапсулируют в договоренности пост фактум за те же деньги работу над соотвествием определенным стилям - это все работа которая должна быть оплачена). Поэтому вот вам вилка ваших дейсвтий:

1) Если у вас просто просят менторства молодые коллеги - дайте им ссылку на гугл и ключевое словосочетание php style guide github
2) Если вас спрашивают (либо вы сами являетесь таким заказчиком который ищет за что зацепиться в коде чтобы продавить свою позицию) - нет критериев качества кода ДО начала работ подписанных на бумаге / пересланных по почте - никакие критерии не могут быть применены к текущим отношениям - только к следующей итерации за следующие деньги.
3) Если вы все же разработчик и вас попросили оценить код - донесите данную ситуацию до стадии корректного закрытия текущего этапа работ - но дальше предложите уже введение стайл гайда если оно того требует. Я полагаю что на самом деле нет. Дав сейчас ответ на вопрос в виде оценки качества кода вы сделаете только одно - абсолюно необоснованно дадите агрумент в явно перекошенном споре, и просто возьмете на себя еще один мешок кармогрязи которую будуете еще сколько-то положенного времени отрабатывать.

Подумайте хорошо на эту тему - придется выбрать свою сторону.

Я делаю так:
- переношу файлы в нужную директорию
- изменяю домен в БД на новый, закидываю *.sql на хост
- прогоняю через Fix-Serialization
чтобы сериализованные данные восстановились
- заливаю *.sql в БД.

Все операции выше легко выполняются через SSH.

Не использую и всячески избегаю, как чумы. Проектов с page builder'ами не беру, независимо от бюджета.
Для создания гибкого flow под клиента использую ACF Pro.
В скором времени в процесс будет включен Gutenberg.

Не использую их.

Пейдж билдеры, это как adobe dreamweaver в 2004-м году. Много мусора, медленные. Не предсказуемые и глючные в самый неподходящий момент. Сейчас форумы поддержки завалены вопросами "стоит пейдж билдер, плагин не работает..." - и такие темы содержат либо ответ в стиле - "отключайте пейджбилдер - конфликт с ним", либо просто темы без ответа. Техподдержки по билдерам вам не дадут.

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

Если вы слышите совет: их использовать - то это совет человека далекого от сайтостроения. Просто такой же домохозяйка.

Но если мы будем переводить проект на реакт, то как мы будем писать php в нем?

Что это вообще может значить? PHP у вас это server side, а React это клиентское приложение.... Блин, я даже не знаю что дальше спросить... вы PHP в браузере собрались исполнять или JS интерпритатором PHP?
Это вот вопрос он лишен смысла чуть более чем полностью.

Ведь синтаксис реакта ( jsx ) не предусматривает php.

Да причем тут синтаксис? Среда исполнения не предусматривает php, а вы про синтаксис.

И мне кажется, так просто взять за неделю и перевести проект на реакт не получится. Наверное будем частями переводить.

Если это сайт среднего размера, то нужно заложить не неделю, а несколько месяцев.

Т.е. получается одна часть проекта будет написана на реакте, а другая - нет? Это вообще как?

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

У кого то есть подобный или близкий к этому опыт? Что посоветуете? Как грамотно перевести проект на реакт в таком случае?

Выше написал:
1 Сначала разрабатываете шаблон для одного раздела сайта на React, так как буд-то других разделов просто не существует.
2 Пишите соотвествующий бэкенд который будет отдавать данные для этого вашего шаблона.
3 Переводите этот раздел сайта на React.
4 Эксплуатируете неделю, подчищая косяки.
5 Выбираете еще один раздел сайта поменьше и переводите его аналогичным образом.
6 В этом месте у вас уже должно быть понимание где вы наложали с архитектурой, какие накопились костыли, и в чем фундаментальные изъяны того что вы сделал. Тут вы должны остановиться и выкинуть всё что сделали раньше. Я не шучу - просто выкинуть и начать перерабатывать эти разделы с нуля...
7 Теперь вы знаете что делать дальше.

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

По второй ссылке, что указал Дмитрий в комментариях пример такого "творчества". Там используются вот эти команды: https://github.com/zendframework/zend-expressive-s... документация по которым есть на сайте композера: https://getcomposer.org/doc/articles/scripts.md#co... где вызываются вот эти методы во время установки: https://github.com/zendframework/zend-expressive-s...

А дальше дёргается API композера и творится всякое непотребство. Документации по нему нету, но методом тыка можно попытаться разобраться самостоятельно.

add_action('init', 'register_script');
function register_script() {
    wp_register_script( 'custom_jquery', plugins_url('/js/custom-jquery.js', __FILE__), array('jquery'), '2.5.1' );
    wp_register_style( 'new_style', plugins_url('/css/new-style.css', __FILE__), false, '1.0.0', 'all');
    wp_enqueue_script('custom_jquery');
    wp_enqueue_style('new_style' );
}