У WordPress есть свои, вполне адекватные стандарты оформления кода: WordPress Coding Standards, которые есть и в виде правил для PHPCS.
Здесь я с вами не соглашусь. Многие популярные плагины разрабатываются целыми командами разработчиков в соответствии со стандартами оформления кода и с использованием систем контроля версий. При длительной командной разработке без этого не обойтись. Можете, например, взглянуть в репозитории CMB2, Polylang, Yoast SEO, WooCommerce и многие другие.
Разработчики WordPress также используют систему контроля версий для разработки, достаточно качественно документируют свой код и уделяют достаточно много времени его тестированию.
Что значит подключен wp-admin.php или нет? Описанная функция выводит ссылку на обработчик AJAX. Если вы используете вывод скриптов как есть прямо в коде, то это достаточно неплохое решение.
Если вы хотите все делать правильно, то скрипты нужно выносить в отдельные файлы и подключить вместе с зависимостями и переменными. Это подробно описано в документации.
Сначала скрипты нужно вынести в отдельный файл, зарегистрировать его вместе с зависимостями, подключить через wp_localize_script нужные переменные и только после этого подключить сам скрипт через wp_enqueue_script на нужной странице. Как это все делается в случае с AJAX хорошо показано в последнем примере по ссылке выше.
В вашем примере вообще никак не проверяется подключен ли jQuery и локализация почему-то зазывается на него. Также не уделяется внимание очередности вывода. Сначала регистрация, потом локализация и только потом вывод.
Это да, без Total Commander работать лично мне крайне сложно. Пользуюсь этой программой уже лет 15, даже лицензию в свое время купил :) Пакетное переименование, поиск по содержимому, быстрый просмотр, показ всех файлов в подпапках, фильтры, сортировки, работа с выделением... В общем, штука очень полезная.
Информации по AJAX в документации более чем достаточно: AJAX in Plugins. Там же есть ссылки для более плотного знакомства.
Для получения ссылки просто меняете
url: "/wp-admin/admin-ajax.php",
на
url: "<?php echo admin_url('admin-ajax.php'); ?>",
Эта функция уже используется у вас в коде, но в другом месте.
Вы можете включить сортировку по дате в WinSCP, выделить и загрузить только измененные файлы.
Если это кажется слишком сложным способом, то можете настроить PhpStorm: Deployments in PhpStorm. Эта IDE умеет кучу вещей, включая автоматический запуск синхронизации после коммита. Во время синхронизации загружаются только измененные файлы.
Я процитировал ровно то, что вы написали.
Если речь идет о банальной синхронизации темы для WordPress, то можно просто копировать измененные файлы на сервер с помощью WinSCP.
Можно также в настройках PhpStorm-а настроить меппинг путей и по необходимости запускать синхронизацию содержимого папки с темой через соответствующий пункт в контекстном меню.
Завершили итерацию по доработкам - загрузили на тестовый сервер. Заказчик одобрил - сделали коммит в локальный репозиторий.
Позвольте поинтересоваться, а зачем каждый раз гонять весь сайт на рабочий сервер? Вы правите системные файлы WordPress?
Интересно, а зачем вы мне эти банальные вещи рассказываете? ;)
1. Да, действительно, разработку больших проектов уместно разбить на несколько файлов, но на боевом сервере их лучше объединять в один для ускорения загрузки страницы. Все современные препроцессоры достаточно хорошо с этим справляются.
2. Никто с этим и не спорит, на самом деле. Код действительно нужно разбивать на более-менее независимые блоки и сопровождать комментариями. Препроцессоры это упрощают за счет поддержки вложенности.
3. К сожалению, если человек изначально не умеет верстать и как-то организовывать свой код, то тут никакой препроцессор не поможет.
На самом деле там нечего учить.
Синтаксис SCSS очень похож на CSS с добавлением вложенности, импортов, переменных, миксинов и других плюшек. Именно они помогают ускорить разработку, уменьшить количество ошибок и более явно структурировать код. Это особенно важно на средних и больших проектах, где более чем 5-10 тысяч строк CSS. Если вы с такими сталкивались, то наверняка знаете в какой ад превращается их дальнейшая разработка и поддержка после десятка сверстанных страниц.
Работать с консолью нужно учиться в любом случае.
Самым лучшим будет вариант:
JOIN-ы по many-to-many таблицам работают гораздо быстрее чем запросы с LIKE. Для еще большего ускорения можно разбить один сложный запрос c JOIN-ами на несколько более простых. Грубо говоря, сначала вы получаете список ID пользователей, которые содержат нужные опции, а потом производите по ним выборку. Подобный подход применяется в Yii2.
