поправка.
редактировать комментарии тут нельзя:
>надо исходить из стоимости таких правок и бизнес-логики
а теперь выяснилось, что и на rest api точка зрения практически совпадает)
Игорь Воротнёв:
> вы мою позицию немного не поняли и вцепились в REST API.
так по остальным пунктам у нас одинаковая точка зрения
>надо исходить из стоимости таких правок и бизнес-логики
а теперь выяснилось, что и с rest api практически совпадает)
>С другой стороны, расходы надо считать не тактически, на данный момент, а стратегически
при сроках жизни некоторых проектов около года (пока домен куплен), да и при текущей стоимости разработки сайта под WP, столь долгое стратегическое планирование можно в расчет не принимать
переубедить друг друга мы не сможем, хоть каждый и остался при своем мнении, предлагаю его закончить)
по теме вопроса, coderisimo чтоб конкретно в этом случае узнать, что грузится долго,
нужно посмотреть какой параметр action у запроса к admin-ajax.php
затем выполнить поиск по этому слову в папке с шаблоном и папке с плагинами
как найдете код функции, показывайте, можно будет понять, что так долго грузит.
возможно, у вас там обращение к стороннему сайту через wp http api
Игорь Воротнёв:
>Так, не надо передергивать и сравнивать с какими-то другими плагинами
пишу как раз о wp-api.org
у них, грубо говоря, две версии v1, которая стабильная, она же была в официальном репозитории как плагин, и v2, которая бета
начинал использовать этот плагин тогда, когда была только 1я версия, вторая была в очень раннем состоянии.
сейчас, если нужно будет переделывать какой-нить из проектов с той версией плагина, не уверен, что смогу быстро перейти на новую версию (тупо заменой плагина точно не обойдется)
версия плагина, что сейчас доступна, так же еще бета https://github.com/WP-API/WP-API/issues?q=is%3Aope...
периодически правят дыры в безопасности. (вот тут я слегка передергиваю)) но все равно, не уверен, что стоит ставить на рабочий проект текущую версию) тем более, что правки вроде "potential XSS" и "Fix user access security vulnerability" там действительно есть.
>Но и в 9 случаях из 10 этот нестандартный код не надо изобретать.
>REST API вполне подходит
Ага, тогда возьмем текущую ситуацию. Вон, пользователь задал вопрос "тормозит ajax".
Сейчас основная масса плагинов и шаблонов rest api не используют. На сайте у него с большой вероятностью такие "старые" плагины и шаблон стоят.
Что ему будет дешевле?
Переписать все под REST API (шаблоны, чужие плагины), повторять это же при их обновлении или воспользоваться одним из моих, местами нестандартных, советов?
С тем, что я предложил, можно вообще без вмешательства в чужой код (remove_action/add_action либо редиректить нужные обращения к admin-ajax через .htaccess на свой скрипт).
Если оценивать с позиции "как в документации", конечно, лучше ваш способ.
Если же оценивать деньгами, конкретно для этого проекта можно и отдельный staging server с WP 4.4 не использовать и от документации немного отойти - это будет быстрее, дешевле и проще в обслуживании.
Игорь Воротнёв: это не "уже". это "еще" - еще бета) прямо сейчас автор топика использовать его не сможет
было уже, что в релиз некоторый функционал из предрелизных версий не включали. не с столь поздней версии, но тем не менее.
Если ставить отдельно, как плагин, там тоже не все так хорошо: у них несколько версий/вариантов работы апи. Если не путаю, в WP включат не совсем ту версию, что в стабильной ветке плагина.
>Смысл API как раз в том, чтобы быть расширяемым и гибким и ничего не надо было переписывать по десять раз. Именно для этого и делают API.
Универсальное решение всегда проигрывает узко заточенному. При этом узко заточенное решение решение всегда проигрывает универсальному. Смотря по каким параметрам подбирать)
В основной массе проектов стоит использовать стандартные решения (их быстрее внедрять, проще поддерживать и тд и тп). Но бывают случаи, когда подойдет только нестандартный код.
И, повторюсь, тестов сравнения производительности - что быстрее, меньше грузит, кэширует ли оно и тп по api rest нет. может оно будет с такой же производительностью работать? Советовать непроверенное не хочу.
А для внедрения нужно и js будет переписывать. Смысл сейчас менять?
Я не пишу, что rest api - плохо. Я написал несколько вариантов, доступных в текущей стабильной версии WP. Которые точно снизят нагрузку. И указал, какой из вариантов предпочтительней. rest api не подходит ни под доступность в текущей версии, ни под "точно снизит нагрузку". Можно посмотреть в коде, как оно сделано, но лень) Будет релиз, буду смотреть. Пока, на мой взгляд, рабочие только 3 варианта
Игорь Воротнёв: если использовать rest api, нужно будет так же переписывать и js часть.
Если на сайте используются плагины, нужно будет править и их. А при обновлении плагинов, переписывать этот код повторно. При использовании кастомной точки входа для аякса, правок, хотя бы в части js, значительно меньше.
Ну и, честно говоря, пока не видел тестов с сравнением, что будет более прожорливо - rest api или admin-ajax. Код самого плагина так же пока не смотрел. Считаю, советовать rest к использованию можно будет, когда включат в движок.
При своем же, отдельном скрипте под обработку аякса, могу грузить только те части движка, которые нужны.
coderisimo: продолжим)
если самый тяжелый, это cron, откажитесь от использования встроенного в WP крона.
Если все эти 30 кб задач с крона решат стартовать одновременно (в некоторых случаях это возможно), сервер вероятно и не упадет, но поплохеет ему точно.
И отдельно, по поводу admin-ajax
Запросы, которые обрабатываются через этот файл, не кэшируются. Поэтому вам нужно:
1 либо принудительно класть результаты выполнения в кэш (используя WP Cache API или Transient API)
2 либо написать свою отдельную точку входа для ajax запросов.
Это может быть как обычная страница в WP, которая разбирает _GET запрос,
3 так и кастомный endpoint, который будет переправлять запрос к самостоятельному php скрипту. который, в свою очередь, будет подгружать только нужное от движка.
Я бы рекомендовал 1й вариант. Это будет ближе к стандартам WordPress и это проще.
Но 2й и 3й варианты так же могут в некоторых случаях найти применение.
WP Panda: вы не путайте оптимизацию без потери качества и оптимизацию с потерей качества. так то можно и до 20кб ужать.
На мониторе с ретиной разница при переключении на ваш вариант картинки мне заметна.
Чуть выше уже писал - Photon картинку оптимизирует. Оптимизирует без потери качества. То есть оптимизация есть.
Степень оптимизации, это уже другой вопрос. По соотношению - цена/простота и скорость установки/потребления ресурсов сервера этот вариант вне конкурентов. Можно поставить плагин, включить и оно будет работать.
Плюс оно работает еще и как cdn, снимая с сервера нагрузку на выдачу картинок.
чтоб не ходить по ссылкам - размер картинки без фотона на 9 кб больше.
другой вопрос, что через другие сервисы/библиотечки оптимизация может быть более глубокой, но таки и у самих сервисов/библиотек степень оптимизации разная.
Гриша Никольский: вы лучше создайте новый отдельный вопрос, так больше пользователей его увидят и быстрее ответить смогут.
в этом случае __FILE__ это файл, который выполняет скрипт.
пост, к которому вы обращаетесь, может быть разным. но обрабатываться эта запись может одним и тем же скриптом
Гриша Никольский: здравствуйте
добавлять "напрямую" в базу не обязательно.
если вы добавили новые кастомные типы записей и нужные таксономии (они должны были появиться в адмике), то вы можете добавлять новые записи этого типа функцией
wp_insert_post https://codex.wordpress.org/%D0%A1%D0%BF%D1%80%D0%...
это снимет с вас необходимость самостоятельно подключаться к базе данных и будет более безопасно
"wp_insert_post() передает данные через функцию sanitize_post(), которая сама по себе производит всю необходимую обработку и проверку на безопасность (kses и т.д.)."
Дмитрий Королёв:
>Или вы не умеете управлять приоритетами?
я умею. вы тоже. но в интернете кроме нас есть еще программисты, некоторые могут это не уметь. зачем создавать проблему на пустом месте для них?
>>который решил переместить скрипт в head.
>Сам себе злобный буратино?
в конце концов, сам заказчик может решить переместить скрипт (например, ему кто-то сказал, так будет лучше).
wp_localize_script решает все эти проблемы (данные всегда будут перед скриптом, не нужно изучать кастомный код).
опять же, уже писал. может быть своя логика подключения скриптов.
например, показывать скрипт только на одной странице, и только для зарегистрированных пользователей.
с вашим подходом этот код нужно будет дублировать в функции для вывода переменных.
Это так для дополнительной чистоты кода делать нужно?
и чем вам кажется "не семантичным" или "не чистым" тот код, что выводит wp_localize_script?
Что по вашему не так с функцией? Хотите в json данные выводить - берите массив, кодируйте его в json, цепляйте к этой функции, В чем проблема?
она работает, описана в документации, работу выполняет отлично, никаких дополнительных странных действий делать не нужно. почему "костыль"?
не нравится название, сделайте функцию-обертку wp_add_var_to_script, которая будет вызывать wp_localize_script)
Гриша Никольский: вообще, что-то вы не то делаете.
зачем вам дополнительные таблицы? можно жеж создать новый кастомный тип записи и туда писать команды.
Гриша Никольский: повторюсь
"в крайнем случае, если эти функции по какой-то причине не подходят, можно воспользоваться функциями движка для работы с базой данных."
функционал вордпресса позволяет добавлять кастомные таблицы/писать в них.
с текущим кодом сайт можно положить за пару минут. так в базу писать нельзя, переменные у вас без валидации.
если скрипт запустится до вывода переменных, переменные доступны не будут.
не все скрипты должны срабатывать по $(document).ready некоторые нужно запускать раньше. с вашим подходом будет ошибка.
ну и представьте ситуацию:
вы делали сайт, сделали там вывод переменных по своему, прицепили к футеру и скрипт и, чуть выше в футере, свой чудо-код.
после вас пришел другой разработчик, который решил переместить скрипт в head. С вашими гениальными наработками он не знаком, читал только кодекс WordPress.
Угадайте, будет ли скрипт работать, если подключить его в хедере, а переменные вывести в футере?
Да, эту ошибку поправить можно, но при использовании wp_localize ее бы вообще не возникло.
"гениальные" решения хороши, но в обычной жизни стоит использовать то, что написано в документации. Даже если это входит в противоречие с вашими убеждениями.
Следующий программист, взявшись за работу над сайтом написанным строго по документации, скажет вам спасибо.
Дмитрий Королёв: вы бы хоть документацию почитали, перед тем, как комментарий писать?
https://codex.wordpress.org/Function_Reference/wp_...
"Though localization is the primary use, it can be used to make any data available to your script that you can normally only get from the server side of WordPress."
именно эту функцию и нужно использовать для добавления данных. это и есть правильный способ.
представьте, у вас зарегистрирован скрипт через wp_register_script.
но выводится он только на некоторых страницах.
с вашим подходом нужно дублировать логику вывода и для добавления данных.
ну и нет гарантии, что с вашим подходом данные будут доступны скрипту.
редактировать комментарии тут нельзя:
>надо исходить из стоимости таких правок и бизнес-логики
а теперь выяснилось, что и на rest api точка зрения практически совпадает)