vvvadimos: тогда свою проблему на вас хочет переложить не только тех.поддержка, но и ваш начальник.
и решение этой проблемы уже выходит за рамки вопроса)
Роман Краббз: а почему вы это у меня спрашиваете?)
вы лучше у топик стартера спросите.
Но в его ситуации не важно, где и как он держит сайт. Если у него нет доступа к CDN, то установка той штуки по ссылке проблему решит - файлы будут грузится с его сервера, а не через интернет.
Если не работает, проверьте, включены ли mod_headers, mod_expires и прочее подобное.
Ну и, на всякий случай, все-таки перепроверьте, действительно ли статику отдает апач. Вдруг хостер что-то внезапно поменял?
Heronix: вполне вероятно, что разработчики этого шаблона решили не пользоваться стандартными средствами и вывели миниатюру как-то по своему.
Сможете показать полностью код этой страницы?
Zakonoposlushniy: деньги тоже находятся в свободном доступе. Там, правда, тоже какой-то копирайт есть, но вам жеж это не помешает?)
Если по теме
Основная масса "отвечающих" тут получает деньги за продажу своего кода. Вы приходите и спрашиваете, как этот код украсть. Не совсем та аудитория для таких вопросов.
поправка.
редактировать комментарии тут нельзя:
>надо исходить из стоимости таких правок и бизнес-логики
а теперь выяснилось, что и на 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й варианты так же могут в некоторых случаях найти применение.
