При создании фильтра он выполняется постоянно, а экшн только после определенного действия?
Нет. И фильтры, и экшны выполняются тогда, когда они вызваны. Один раз. По сути, на уровне кода это одно и тоже. Хуки - это события. WP выполняет код, доходит до места где вызывается хук Х (не фажно - фильтр или экшн). Дальше он смотрит, что на этот хук подвешено, и выполняет все коллбеки с учетом их приоритета. После этого двигается дальше в процессе выполнения. И так - очень много раз, потому что хуков в WP много.
После каких действий могут срабатывать хуки?
После очень многих. и не только после, но и перед. И в процессе. Все хуки можно посмотреть на сайте hookr.io, или в коде ядра WP.
Я знаю пока только что можно сделать при отправке формы.
Хм. А я такого не знаю. Скорее всего вы просто некорректно формулируете.
Думаю можно делать и вложенные хуки? Например один сработал, а в нем еще один и т.д.
Не совсем понятно зачем, что именно вы пытаетесь получить таким образом. Возможно, опять же, некорректно формулируете, исходя из неверного и неполного понимания архитектуры событий (ивентов, хуков). Чисто технически - да, они могут быть вложенными.
Можно ли просто по нажатию на кнопку/ссылку на сайте?
Нажатие кнопки/ссылки на сайте - это фронтенд. Это взаимодействие с пользовательским интерфейсом. Хуки выполняются на бекенде, когда эта страница с кнопкой/ссылкой генерируется. Впрочем, с помощью javascript вы можете отправить ajax запрос и на аякс-хуке его обработать и вернуть результат.
Пример очень простой: есть кнопка, при нажатии на которую я хочу чтобы у пользователя в профиле допустим к никнейму прибавилось число и увеличивалось на 1 по нажатию.
Ну или любой пример взаимодействия с БД. Еще: есть кнопка в статье, которая при нажатии берет ID поста и записывает его куда нибудь пользователю, по принципу закладок
Простой ответ в виде логики:
1. По нажатию вызывается ваш js-обработчик, который отправляет данные на бекенд, на аякс-хук
2. Код в аякс хуке принимает входящие данные, делает с ними все что надо, возвращает ответ
3. Ваш js-обработчик из п.1 получает ответ от сервера (п.2) и делает дальше что нужно на фронтенде (например, увеличивает счетчик, меняет иконку кнопки "закладка" и тд)
Думай Головой, все верно, это тоже рабочее время. Комментарий был с ноткой троллинга, к словам "трекают 30-40 и больше часов в неделю" + "За "трудные" 20 часов в неделю я делаю в десятки раз больший объем работы. Ребята откровенно халявят, "кидают" не смыслящего в коде заказчика". Парень в команде работал, скорее всего конкретно над тасками. А другие ребята в команде вполне могли еще тратить время на общение с заказчиком, постановку этих задач внутрь команды, code review, отчеты, выставление счетов, проводки платежей и прочее. А он их сразу в кидалове обвиняет. Некрасиво как-то.
brainiac26, даже если когда-то где-то вам попалась такая фраза, то это не означает что ничего с тех пор не менялось. Жизнь богата изменениями. А вот к чему и с какой радости был ваш неуместный коммент - кажется никто не понял.
А может еще те, кто имеют рейт повыше и опыта побольше, трекают не только время кодинга, но и время общения с заказчиком, переписку в тасках и прочие организационные моменты?
> почему вы решили что он не используется?
Потому что ТС пишет "в папке Woocommerce archive-product.php это главный файл типа index.php". То есть, он рассчитывает, что этот файл будет подхватываться на главной, а index.php в корне у него исключительно потому что "Без index.php тема не работает".
Руслан Галиев, мне тоже это непонятно. С иллюстратором проще, там вектор, поэтому реальные dpi не столь важны. Хотя если импортнуть растровую картинку, то результат будет как и в фотошопе. У меня есть предположение, что поскольку ФШ все же используется не только для веб и он вынужден учитывать реальный dpi документов, то приходится показывать все реальном масштабе. Впрочем, это не объясняет почему нельзя сделать простой переключатель "режим ретины для веб", и с перезагрузкой приложения, если это необходимо, подстаиваться. Хз что там в Adobe себе думают.
Соответственно, данные берутся из таблицы wp_options по ключу 'blogdescription'. Данную опцию можно фильтровать на лету через динамические хуки pre_option_blogdescription, либо option_blogdescription. Первый срабатывает до получения значения опции из базы и позволяет вообще что угодно передать, второй срабатывает в самом конце, когда опция получена из базы и позволяет модифицировать это значение.
А еще ваше вот это "echo 'Страница загружена" безбожно врет, потому что эти цифры никак не дают время загрузки страницы. Они дают время генерации страницы на сервере.
И уж тем более ставить один и тот же код каждую страницу - это как бы намекает что нету приложения, а есть какая-то каша html-php-css-js.
Дмитрий, да, точно. Совсем забыл про него. Правда, насколько мне помнится, гугль ограничивает количество запросов, за дополнительные денег тоже просит.
Вячеслав Беляев, ну вот этим кодом с curl вы можете проверять доступность и скорость ответа сервера (то есть, бекенд), сравнивая таймеры. Это достаточно простая задача. А вот замерять скорость полной загрузки с учетом фронта - вот это уже задача совершенно другого уровня.
Бесплатно вам никто спи не предоставит, потому что это ресурсы. Кто-то за них должен платить. Писать это на PHP такое себе решение... Но все же.
По аптайму:
1. Задача на кроне раз в минуту дергает php-script.
2. Скрипт запускается, берет из базы или конфига какого-нибудь список урл которые надо пингануть
3. Пингует урлы c помощью curl и каким-то разумным тайм-аутом
4. Получаем ответ, парсим заголовки если надо. Если ответ не получили - значит урл лежит.
5. Пишем результаты п.4 в лог или базу
По скорости загрузки:
Вот тут сложнее, потому что по сути мы можем только измерить время от момента отправки запроса (того же, который проверяет аптайм) до момента получения ответа от удаленного сервера. Это если по простому.
Чтобы посчитать время полной загрузки страницы, с учетом всех файлов (скрипты, стили, картинки и тд), необходимо использовать уже какой-нибудь chromium, который и будет слать запросы и обрабатывать их. По сути это движок браузера, без пользовательского интерфейса, с которым можно работать по его АПИ / из командной строки. PHP умеет в CLI работать, умеет выполнять shell команды, значит их можно подружить.
Как-то так. Но, имхо, игра не стоит свеч - задача весьма нетривиальна, и тратить на нее сотни своих рабочих часов не имеет смысла. Как я написал в ответе, лучше выбрать готовое, по принципу:
1. Денег жалко, надо бесплатно - берем google analytics и uptime monitor (или аналог). Получаем мониторинг аптайма + скорость загрузки. Но скорость загрузки (Google Analytics) будет меряться у реальных юзеров. Если надо как-то мануально раз в Х минут - нужно искать альтернативу. Уверен, что-то такое есть, с базовым набором функционала.
2. Нужен качественный и мощный инструмент - берем New Relic (платный).
Вариант с Nagios и аналогичными инструментами я не привожу, потому как он децентрализован - такие инструменты безусловно круты и удобны, но они требуют установки и настройки на сервере, а если каждый отдельный сайт, который надо тестить, находится на другом сервере - это надо делать на каждом из них, дальше это поддерживать и тд. Ну и смотреть данные надо на каждом сервере отдельно.
Нет. И фильтры, и экшны выполняются тогда, когда они вызваны. Один раз. По сути, на уровне кода это одно и тоже. Хуки - это события. WP выполняет код, доходит до места где вызывается хук Х (не фажно - фильтр или экшн). Дальше он смотрит, что на этот хук подвешено, и выполняет все коллбеки с учетом их приоритета. После этого двигается дальше в процессе выполнения. И так - очень много раз, потому что хуков в WP много.
После очень многих. и не только после, но и перед. И в процессе. Все хуки можно посмотреть на сайте hookr.io, или в коде ядра WP.
Хм. А я такого не знаю. Скорее всего вы просто некорректно формулируете.
Не совсем понятно зачем, что именно вы пытаетесь получить таким образом. Возможно, опять же, некорректно формулируете, исходя из неверного и неполного понимания архитектуры событий (ивентов, хуков). Чисто технически - да, они могут быть вложенными.
Нажатие кнопки/ссылки на сайте - это фронтенд. Это взаимодействие с пользовательским интерфейсом. Хуки выполняются на бекенде, когда эта страница с кнопкой/ссылкой генерируется. Впрочем, с помощью javascript вы можете отправить ajax запрос и на аякс-хуке его обработать и вернуть результат.
Простой ответ в виде логики:
1. По нажатию вызывается ваш js-обработчик, который отправляет данные на бекенд, на аякс-хук
2. Код в аякс хуке принимает входящие данные, делает с ними все что надо, возвращает ответ
3. Ваш js-обработчик из п.1 получает ответ от сервера (п.2) и делает дальше что нужно на фронтенде (например, увеличивает счетчик, меняет иконку кнопки "закладка" и тд)