Дикий пионер: Ну и это, WP через какой-нибудь PHPCS или PHPMetrics не гоняли? Любопытно бы было посмотреть.
У WordPress есть свои, вполне адекватные стандарты оформления кода: WordPress Coding Standards, которые есть и в виде правил для PHPCS.
mendel: Никто не соблюдает даже рекомендации ВП, а они "несколько" слабоваты и так.
Здесь я с вами не соглашусь. Многие популярные плагины разрабатываются целыми командами разработчиков в соответствии со стандартами оформления кода и с использованием систем контроля версий. При длительной командной разработке без этого не обойтись. Можете, например, взглянуть в репозитории CMB2, Polylang, Yoast SEO, WooCommerce и многие другие.
Разработчики WordPress также используют систему контроля версий для разработки, достаточно качественно документируют свой код и уделяют достаточно много времени его тестированию.
Что значит подключен wp-admin.php или нет? Описанная функция выводит ссылку на обработчик AJAX. Если вы используете вывод скриптов как есть прямо в коде, то это достаточно неплохое решение.
Если вы хотите все делать правильно, то скрипты нужно выносить в отдельные файлы и подключить вместе с зависимостями и переменными. Это подробно описано в документации.
Сначала скрипты нужно вынести в отдельный файл, зарегистрировать его вместе с зависимостями, подключить через wp_localize_script нужные переменные и только после этого подключить сам скрипт через wp_enqueue_script на нужной странице. Как это все делается в случае с AJAX хорошо показано в последнем примере по ссылке выше.
В вашем примере вообще никак не проверяется подключен ли jQuery и локализация почему-то зазывается на него. Также не уделяется внимание очередности вывода. Сначала регистрация, потом локализация и только потом вывод.
SeVlad: Ё! Ты же работаешь с файлами? Я правда не понимаю как можно работать с файлами не имея управления над ними. Ок.. В ФМ я сразу вижу инфу о них, состав (сразу привет вирям и левым файлам), могу быстро перейти в нужный каталог (история+закладки+вкладки). Из него же могу и просто посмотреть в реадонли (F3), а могу править (F4) в нужном мне редакторе. Могу отсортировать в каталоге по критериям (по дате), могу отобрать по критериям (по маске) в неск каталогах, могу найти нужный текст в файлах с кучей условий, включая регулярки. Могу распаковать/упаковать могу посмотреть состав файлов и их содержимое без предварительной распаковки архива. Могу переименовать файлы хоть по одному, хоть скопом, хоть по множеству условий и возможностей. Могу закачать/скачать по ФТП и синхронизировать. И ещё 100500 операций над файлами и каталогами и не только.
Это да, без Total Commander работать лично мне крайне сложно. Пользуюсь этой программой уже лет 15, даже лицензию в свое время купил :) Пакетное переименование, поиск по содержимому, быстрый просмотр, показ всех файлов в подпапках, фильтры, сортировки, работа с выделением... В общем, штука очень полезная.
Sly32: А на кодексе нет ничего подходящего
Информации по AJAX в документации более чем достаточно: AJAX in Plugins. Там же есть ссылки для более плотного знакомства.
Sly32: SCP опять же тупо загонит по нужному мне адресу всю папку, не разбираясь что и как, а зачем?
Вы можете включить сортировку по дате в WinSCP, выделить и загрузить только измененные файлы.
Если это кажется слишком сложным способом, то можете настроить PhpStorm: Deployments in PhpStorm. Эта IDE умеет кучу вещей, включая автоматический запуск синхронизации после коммита. Во время синхронизации загружаются только измененные файлы.
Если речь идет о банальной синхронизации темы для WordPress, то можно просто копировать измененные файлы на сервер с помощью WinSCP.
Можно также в настройках PhpStorm-а настроить меппинг путей и по необходимости запускать синхронизацию содержимого папки с темой через соответствующий пункт в контекстном меню.
Завершили итерацию по доработкам - загрузили на тестовый сервер. Заказчик одобрил - сделали коммит в локальный репозиторий.
Sly32: Он позволяет мне как раз не гонять каждый раз на рабочий сервер весь сайт, а оперативно добавлять только то, что изменено, что как раз актуально при маленькой скорости доступа.
Позвольте поинтересоваться, а зачем каждый раз гонять весь сайт на рабочий сервер? Вы правите системные файлы WordPress?
livetv: 1. В одном файле не стоит держать 10к строк, его легко можно и нужно разбить. 2. CSS нужно группировать и комментировать 3. Ад еще из-за того, что стили по дурному названы, допустим длинная цепочка .style1 .style2 div .style3 a.style4{
} или использование #id
Бардак возможен и на препроцессорах.
Интересно, а зачем вы мне эти банальные вещи рассказываете? ;)
1. Да, действительно, разработку больших проектов уместно разбить на несколько файлов, но на боевом сервере их лучше объединять в один для ускорения загрузки страницы. Все современные препроцессоры достаточно хорошо с этим справляются.
2. Никто с этим и не спорит, на самом деле. Код действительно нужно разбивать на более-менее независимые блоки и сопровождать комментариями. Препроцессоры это упрощают за счет поддержки вложенности.
3. К сожалению, если человек изначально не умеет верстать и как-то организовывать свой код, то тут никакой препроцессор не поможет.
livetv: Я в этих препроцессорах смысла не вижу. Это нужно учить еще один язык. Проще на php написать генерацию, если так нужно
Разработчик на них скорее всего будет стоить дороже, а результат хз.
На самом деле там нечего учить.
Синтаксис SCSS очень похож на CSS с добавлением вложенности, импортов, переменных, миксинов и других плюшек. Именно они помогают ускорить разработку, уменьшить количество ошибок и более явно структурировать код. Это особенно важно на средних и больших проектах, где более чем 5-10 тысяч строк CSS. Если вы с такими сталкивались, то наверняка знаете в какой ад превращается их дальнейшая разработка и поддержка после десятка сверстанных страниц.
Stek: Действительно, фигня ведь полнейшая. Теперь для CSS надо ставить Node.js, уметь работать с консолью. Скоро стили будут распостранять через docker и требовать минимум vps для деплоя
Таблица A Таблица B Таблица связей AB (a_id, b_id,value)
JOIN-ы по many-to-many таблицам работают гораздо быстрее чем запросы с LIKE. Для еще большего ускорения можно разбить один сложный запрос c JOIN-ами на несколько более простых. Грубо говоря, сначала вы получаете список ID пользователей, которые содержат нужные опции, а потом производите по ним выборку. Подобный подход применяется в Yii2.
Ну и это, WP через какой-нибудь PHPCS или PHPMetrics не гоняли? Любопытно бы было посмотреть.
У WordPress есть свои, вполне адекватные стандарты оформления кода: WordPress Coding Standards, которые есть и в виде правил для PHPCS.
Никто не соблюдает даже рекомендации ВП, а они "несколько" слабоваты и так.
Здесь я с вами не соглашусь. Многие популярные плагины разрабатываются целыми командами разработчиков в соответствии со стандартами оформления кода и с использованием систем контроля версий. При длительной командной разработке без этого не обойтись. Можете, например, взглянуть в репозитории CMB2, Polylang, Yoast SEO, WooCommerce и многие другие.
Разработчики WordPress также используют систему контроля версий для разработки, достаточно качественно документируют свой код и уделяют достаточно много времени его тестированию.
Что значит подключен wp-admin.php или нет? Описанная функция выводит ссылку на обработчик AJAX. Если вы используете вывод скриптов как есть прямо в коде, то это достаточно неплохое решение.
Если вы хотите все делать правильно, то скрипты нужно выносить в отдельные файлы и подключить вместе с зависимостями и переменными. Это подробно описано в документации.
Сначала скрипты нужно вынести в отдельный файл, зарегистрировать его вместе с зависимостями, подключить через wp_localize_script нужные переменные и только после этого подключить сам скрипт через wp_enqueue_script на нужной странице. Как это все делается в случае с AJAX хорошо показано в последнем примере по ссылке выше.
В вашем примере вообще никак не проверяется подключен ли jQuery и локализация почему-то зазывается на него. Также не уделяется внимание очередности вывода. Сначала регистрация, потом локализация и только потом вывод.
Ё! Ты же работаешь с файлами? Я правда не понимаю как можно работать с файлами не имея управления над ними.
Ок.. В ФМ я сразу вижу инфу о них, состав (сразу привет вирям и левым файлам), могу быстро перейти в нужный каталог (история+закладки+вкладки). Из него же могу и просто посмотреть в реадонли (F3), а могу править (F4) в нужном мне редакторе. Могу отсортировать в каталоге по критериям (по дате), могу отобрать по критериям (по маске) в неск каталогах, могу найти нужный текст в файлах с кучей условий, включая регулярки. Могу распаковать/упаковать могу посмотреть состав файлов и их содержимое без предварительной распаковки архива. Могу переименовать файлы хоть по одному, хоть скопом, хоть по множеству условий и возможностей. Могу закачать/скачать по ФТП и синхронизировать.
И ещё 100500 операций над файлами и каталогами и не только.
Это да, без Total Commander работать лично мне крайне сложно. Пользуюсь этой программой уже лет 15, даже лицензию в свое время купил :) Пакетное переименование, поиск по содержимому, быстрый просмотр, показ всех файлов в подпапках, фильтры, сортировки, работа с выделением... В общем, штука очень полезная.
А на кодексе нет ничего подходящего
Информации по AJAX в документации более чем достаточно: AJAX in Plugins. Там же есть ссылки для более плотного знакомства.
Для получения ссылки просто меняете
на
Эта функция уже используется у вас в коде, но в другом месте.
SCP опять же тупо загонит по нужному мне адресу всю папку, не разбираясь что и как, а зачем?
Вы можете включить сортировку по дате в WinSCP, выделить и загрузить только измененные файлы.
Если это кажется слишком сложным способом, то можете настроить PhpStorm: Deployments in PhpStorm. Эта IDE умеет кучу вещей, включая автоматический запуск синхронизации после коммита. Во время синхронизации загружаются только измененные файлы.
Не утрируйте.
Я процитировал ровно то, что вы написали.
Если речь идет о банальной синхронизации темы для WordPress, то можно просто копировать измененные файлы на сервер с помощью WinSCP.
Можно также в настройках PhpStorm-а настроить меппинг путей и по необходимости запускать синхронизацию содержимого папки с темой через соответствующий пункт в контекстном меню.
Завершили итерацию по доработкам - загрузили на тестовый сервер. Заказчик одобрил - сделали коммит в локальный репозиторий.
Он позволяет мне как раз не гонять каждый раз на рабочий сервер весь сайт, а оперативно добавлять только то, что изменено, что как раз актуально при маленькой скорости доступа.
Позвольте поинтересоваться, а зачем каждый раз гонять весь сайт на рабочий сервер? Вы правите системные файлы WordPress?
1. В одном файле не стоит держать 10к строк, его легко можно и нужно разбить.
2. CSS нужно группировать и комментировать
3. Ад еще из-за того, что стили по дурному названы, допустим длинная цепочка
.style1 .style2 div .style3 a.style4{
}
или использование #id
Бардак возможен и на препроцессорах.
Интересно, а зачем вы мне эти банальные вещи рассказываете? ;)
1. Да, действительно, разработку больших проектов уместно разбить на несколько файлов, но на боевом сервере их лучше объединять в один для ускорения загрузки страницы. Все современные препроцессоры достаточно хорошо с этим справляются.
2. Никто с этим и не спорит, на самом деле. Код действительно нужно разбивать на более-менее независимые блоки и сопровождать комментариями. Препроцессоры это упрощают за счет поддержки вложенности.
3. К сожалению, если человек изначально не умеет верстать и как-то организовывать свой код, то тут никакой препроцессор не поможет.
Я в этих препроцессорах смысла не вижу.
Это нужно учить еще один язык.
Проще на php написать генерацию, если так нужно
Разработчик на них скорее всего будет стоить дороже, а результат хз.
На самом деле там нечего учить.
Синтаксис SCSS очень похож на CSS с добавлением вложенности, импортов, переменных, миксинов и других плюшек. Именно они помогают ускорить разработку, уменьшить количество ошибок и более явно структурировать код. Это особенно важно на средних и больших проектах, где более чем 5-10 тысяч строк CSS. Если вы с такими сталкивались, то наверняка знаете в какой ад превращается их дальнейшая разработка и поддержка после десятка сверстанных страниц.
Действительно, фигня ведь полнейшая. Теперь для CSS надо ставить Node.js, уметь работать с консолью. Скоро стили будут распостранять через docker и требовать минимум vps для деплоя
Работать с консолью нужно учиться в любом случае.
Самым лучшим будет вариант:
Таблица A
Таблица B
Таблица связей AB (a_id, b_id,value)
JOIN-ы по many-to-many таблицам работают гораздо быстрее чем запросы с LIKE. Для еще большего ускорения можно разбить один сложный запрос c JOIN-ами на несколько более простых. Грубо говоря, сначала вы получаете список ID пользователей, которые содержат нужные опции, а потом производите по ним выборку. Подобный подход применяется в Yii2.