Глобальные переменные в WordPress

Содержание материала:

Глобальные переменные в плагине WordPress

Я пытаюсь создать свой первый плагин WordPress. Даже пытаясь создать функцию установки, все становится больно. Я хочу установить некоторые глобальные переменные, специфичные для моего плагина, вместо того, чтобы помещать буквальные значения во все функции. Однако моя функция установки не подбирает эти глобальные переменные. Вот мой код:

Очевидно, это довольно прямо на моем конце. Любые идеи, что здесь происходит не так?

Получается, что если вы хотите использовать глобальную переменную для вашей функции установки, вы должны объявить ее глобальной.

Глобальные переменные в WordPress

Итак, у меня есть переменная, которая устанавливается, когда массив возвращает значение, идентичное сильному. это самая сложная вещь, с которой я имел дело. Теперь у меня есть еще одна цель.

Видите, мой сайт является сайтом WordPress. все эти вычисления выполняются в заголовке, но код, который я хочу изменить, находится в нижнем колонтитуле. Ответ, который я, кажется, нахожу, заключается в том, что мне нужно превратить переменную в глобальную переменную. Я пытался в течение нескольких часов, но я не могу понять это правильно.

Может кто-нибудь сказать мне, что мне нужно сделать? Я пробовал решения, которые можно найти в других вопросах здесь, но никакие решения не работают для меня.

Вот код для заголовка. С помощью этого сайта он затрагивает основные сообщества популярной серии. Чтобы сайт оставался в основном нераскрытым до запуска, я изменил некоторые URL и идентификаторы!

А вот код у меня в нижнем колонтитуле

Стоит отметить, что когда я добавляю $ GLOBALS в заголовок, все мои тесты (мой тест, чтобы убедиться, что код действительно обнаружил правильную строку) перестают работать, указывая, что переменная перестает работать. Таким образом, код, который я представил, не работает, но если я удаляю тег globals, он отлично работает только для одного заголовка. Есть идеи, что я могу сделать?

Решение

Вы не справляетесь с этим хорошо.

Это даже не правильный синтаксис. Вы должны установить это к чему-то по крайней мере.
Что бы я делал вместо $GLOBALS это использовать константу, которая является глобальной для всех областей

Практическое руководство. Проверка глобальных переменных в WordPress

Люди часто путаются о том, как получить данные из глобальных объектов /переменных

Вопрос: . Каким образом вы можете проверять глобальные переменные?

Этот Q был написан, потому что он очень часто встречается здесь в WA. Я просто хотел иметь это как fav для ссылки здесь (люди часто не смотрят на github gist links).

Не стесняйтесь модифицировать пример, если что-то не так, или вы думаете, что в объяснении чего-то не хватает. Если вы хотите добавить другие полезные материалы, добавьте их как один ответ. Спасибо.

3 ответа

Как проверить данные:

Используйте это, чтобы получить представление о том, что вы можете использовать из текущего запроса /wp_query.

‘; > // If you’re looking at other variables you might need to use different hooks // this can sometimes be a little tricky. // Take a look at the Action Reference: http://codex.wordpress.org/Plugin_API/Action_Reference add_action( ‘shutdown’, ‘inspect_wp_query’, 999 ); // Query on public facing pages add_action( ‘admin_footer’, ‘inspect_wp_query’, 999 ); // Query in admin UI

Как получить данные:

Примеры
Список всех имен боковой панели?
(Создайте выпадающий /выберите объект со всеми боковыми панелями внутри global $wp_registered_sidebars ).

Или, если вы ленивы, просто установите плагин Отладка> .

Он добавляет кнопку в панель администратора, которая при нажатии открывается панель со всеми полезными сведениями, включая уведомления об исключении, переменные WP_Query и журнал запросов SQL.

В зависимости от того, где в процессе загрузки скриптов и получения окончательного вывода некоторые из перечисленных выше переменных могут отсутствовать. Если вы хотите довольно инклюзивный вид, возможно, немного экстремальный, попробуйте:

var_dump также хорош в том, что говорит вам тип и форматы данных немного.

Как использовать глобальные переменные в WordPress?

У меня есть форма поиска на моей домашней странице с двумя полями в ней, и я выполнил действие для страницы 2 и использовал переменные сеанса в коде страницы 2 для хранения значения, полученного с помощью этой формы, через метод post для доступа к этим переменным сеанса на странице 4 . Это работает, только если пользователь вошел в систему. Поэтому у меня есть еще один вариант, который использует « глобальный ». Я пытался с помощью

Использование глобальной переменной в WordPress

Есть своя таксономия, в которой выводятся посты. У каждого поста есть custom fields с определенными данными (например, с ценами). В сайдбаре на странице хочу сделать вывод максимальной и минимальной цены, но получается только вывести максимальную из первых 10 постов. Как сделать, чтобы выводилась максимальная и минимальная со всей выборки?

1 ответ 1

Надо делать запрос на все посты, а выводить только 10. Например, так:

Всё ещё ищете ответ? Посмотрите другие вопросы с метками wordpress или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2020 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2020.11.6.35358

Недостатки WordPress — техническая сторона

Прежде всего, считаю нужным уточнить несколько моментов:

  1. Эта статья не про какие-либо возможные недостатки интерфейса панели администрирования, тем оформления, готовых плагинов для wordpress или что там еще может интересовать типичного веб-мастера? Со всем этим как раз, на мой взгляд, у WordPress всё относительно в порядке. Эта статья про код.
  2. Статья во многом опирается на материалы, мною собранные воедино, вольно переведенные и от себя значительно дополненные. Ссылки представлены в конце статьи.
  3. Популярность — не синоним качества. Не нужно использовать этот довод как доказательство качества технического исполнения. WordPress популярен явно по совершенно иным причинам.

Глобальные переменные это так классно, не правда ли?

Нет. Глобальные переменные это плохо и нужно стараться их избегать всегда, когда это возможно. Это утверждение подробно раскрыто во множестве иных статей и не является чем-то новым или удивительным для опытного программиста. Если коротко, то глобальные переменные могут быть изменены в любой точке программы, что может повлиять на работу других частей программы. По этой причине глобальные переменные имеют неограниченный потенциал для создания взаимных зависимостей, что приводит к усложнению программы. Глобальные переменные также затрудняют интеграцию модулей, поскольку код, написанный ранее, может содержать глобальные переменные с теми же именами, что и во встраиваемом модуле.

Так вот, WordPress использует их везде и для всего. К примеру, The Loop или Цикл, если по-русски. Используя его, WordPress обрабатывает каждый пост для вывода на текущей странице. Он может быть с легкостью сломан внедрением следующего кода:

И попробуй догадайся где была объявлена или перезаписана глобальная переменная. Тяжело представить как у кого-то вообще могла родиться мысль о том, что вот такое использование глобальных переменных это чертовски хорошая идея.

А пригодился бы разработчику слой абстракции базы данных?

Определенно да. В WordPress не используется концепция моделей и каких-либо сущностей (ладно, есть WP_Post, но это смешно). Как насчет ORM и ActiveRecord? Забудьте. Вся работа с базой данных устроена с помощью отдельных специальных объектов для запросов, вроде WP_Query и WP_User_Query. В придачу к ним идет безумное количество неэффективной логики для поддержки пагинации, фильтрации, санитайзинга, установки связей и т.д. И в довершение ко всему перечисленному, каждый раз, когда осуществляется запрос, он изменяет глобальный объект (см. предыдущий пункт). Нет, серьезно, почему вообще результат запроса к базе должен храниться глобально?

У разработчиков также есть доступ к таким функциям, как query_posts() и get_posts() . Первая строго не рекомендуется к использованию в официальной документации и в статьях вроде этой. И обе являются обертками, вызывающими внутри себя WP_Query .

Предлагаю также читателю постараться не засмеяться и не заплакать во время ознакомления со следующей иллюстрацией-объяснением работы WP_Query:

Всех этих проблем не было бы, если бы под капотом у нас присутствовал бы какой-нибудь адекватный слой абстракции БД. У WordPress есть глобальный объект (да, опять) wpdb , который пытается подражать слою абстракции. Пытается.

Другой важный момент — WordPress не подразумевает, что разработчик может захотеть создать произвольные таблицы в БД для своих нужд. По какой-то причине нужно хранить все данные только в заранее предусмотренных таблицах. Далее представлена схема БД WordPress версии 3.8:

Топ-пост этого месяца:  Как создать почту со своим доменом сервисы Яндекс и Google

WordPress очень полагается на сущность post и типы этих постов (post types). Тут прослеживается наследие WordPress как изначально движка только для блогов. По умолчанию у нас есть следующий список типов постов:

  • post — запись в блоге, пост
  • page — страница
  • attachment — медиафайл (то есть изображение, загруженное и прикрепленное к посту с помощью кнопки «Добавить медиафайл», в терминологии WP это тоже в свою очередь пост)
  • revision — разные редакции одного и того же поста
  • nav_menu_item — элемент меню (ага, значит ссылка в меню тоже является постом, прекрасно)

Если вы делаете плагин и вам нужно объявить свою собственную сущность, например «выполненный проект», вы регистрируете новый тип поста. Такая возможность появилась с версии 3.0 и именуется custom post types.

Так вот, всё это должно храниться в одной единственной таблице БД и имя ей posts. Также у нас есть таблица postmeta. Несложно догадаться, что там нужно хранить всю мета информацию, относящуюся к постам. Таблица options предполагает хранение раличных настроек самого WordPress и всех установленных плагинов. В итоге, рано или поздно мы получим раздутые таблицы, поиск или сортировка по которым может стать проблемой.

Теоретически разработчик может создать свои произвольные таблицы в БД, но WordPress не будет о них ничего знать и не сможет организовать никакого интерфейса для управления данными, хранящимися в такой таблице. Всё, что останется разработчику — это PDO и MySQL запросы.

Создавать для всего кастомные типы постов и таксономий это не решение проблемы, это и есть проблема.

Маршрутизация с помощью mod_rewrite

Само по себе это не плохо. Плохо это измененять правила mod_rewrite посредством обновления .htaccess файла когда ядро или какой-либо плагин добавляют или переопределяют правила маршрутизации и только тогда, когда вы нажмете на кнопку обновления настроек на странице настроек маршрутизации в панели администратора (головная боль при отладке).

В мире уже достаточно давно изобретены, широко известны и широко используются такие подходы к маршрутизации как например у Symfony. Большинство, если не все проблемы WordPress с маршрутизацией могли бы быть решены с помощью маршрутизатора, работающего на уровне PHP. Все эти «полезные» функции вроде is_page() , is_single() и is_category() стали бы ненужными, т.к. маршрутизатор бы отвечал за весь mapping и scoping.

Чтобы понять насколько всё печально, предлагаю заглянуть на соответствующую страницу документации.

Как насчет файловой архитектуры?

Первый релиз WordPress состоялся 27 мая 2003го года, более 11 лет назад (представьте себе). Архитектура MVC тогда еще не была широко известна и используема, соответственно WordPress просто разбит на множество неких отдельных файлов, разложенных по неким директориям, в привычном ключе для PHP разработчика того времени. Этот подход находит свое отражение в устройстве шаблонов оформления, в которых страницы с определенными ролями имеют соответствующие PHP файлы: index.php, archive.php, single.php, и т.д. — вместо использования толковой маршрутизации (см. пункт выше). Да, это всё наследие с незапамятных времен, но от этого оно не перестает быть проблемой сейчас. Если у вас достаточно свободного времени, то можете ознакомиться с видеозаписью доклада, который иллюстрирует с какими вопросами сегодня приходится сталкиваться профессиональным WordPress разработчикам. Там человек 40 минут рассказывает как он организовал архитектуру тем оформления чтобы она была, скажем так, несколько удобнее. Круто, но почему ему вообще приходится этим заниматься и потом рассказывать об этом на конференции?

А вот еще маленькая и не очень существенная деталь, но заставляющая каждый раз страдать мое чувство прекрасного. Название шаблона оформления и прочая мета информация о нем хранятся в файле style.css, лежащем в корневой директории шаблона. Там же обычно хранятся и стили. Что если мы хотим использовать scss, задействовать сборщик, минифицирующий, конкатенирующий и укладывающий весь css код куда нибудь в файл app.css в папке build? Окей, но от style.css в корневой директории нам всё равно так просто не избавиться. WordPress жестко привязывается к названию шаблона, хранящемся в этом файле. Там может не быть ни единой строчки css, но должна быть строка с названием шаблона. Если этот файл удалить или переимновать — всё сломается.

Перейдем от архитектуры шаблонов к остальной кодовой базе. Большинство функционала предоставляется посредством глобальных функций (это плохо, см. пункт выше) и не инкапсулировано в классах / не организовано посредством неймспейсов. Расписывать почему это было бы хорошо — не буду, это широко распространенный и известный подход. Доходит до того, что создатели сколько-нибудь значительных плагинов организуют свою собственную mvc архитектуру с преферансом и барышнями в рамках директории своего плагина.

Любые стандартные класс или функция WordPress могут быть найдены в директории wp-includes в одном из множества файлов, что безусловно служит некоторой организации кода. По крайней мере они попытались.

Пусть архитектура и не так хороша, по крайней мере шаблонизация хорошо работает

Шаблонизация в WordPress? Нет, никаких шаблонизаторов не используется. Вы можете возразить, ведь PHP сам по себе является шаблонизатором и вообще изначально задумывался как язык-шаблонизатор. Что же, это так, но он не используется тут так, как обычно используют шаблонизаторы. Я про то, что нет никаких layout’ов, переиспользуемых частей (partials), автоматического экранирования и т.д. и т.п.

WordPress существует уже больше 11 лет. Smarty больше 12 лет. Twig больше 4 лет. Не вижу ни единой причины почему нельзя было использовать стороннюю библиотеку или даже придумать что-то своё. Сам факт того, что в шаблонах приходится использовать все эти get_header() , get_sidebar() , и get_footer() — жалок.

Механизм action и filter хуков — достаточно мощный и удобный

Давайте не будем обращать внимания на то, что по сути все эти экшены и фильтры — это практически одно и то же, только называется по-разному.

Давайте также закроем глаза на то, что принцип работы всех этих экшенов и фильтров давно известен миру, и название давно придумано — events, события. Только недоделанные, к примеру процесс «всплытия» события не может быть остановлен.

В WordPress данный механизм хуков используется, как и глобальные переменные, везде и для всего. Вся система построена таким образом, что по мере выполнения кода происходят определенные события, на которые повешены определенные функции. Вы можете сказать, что это классно, ведь разработчик может как угодно переопределить поведение системы, без надобности вносить изменения непосредственно в ядро. Да, любой плагин или тема оформления могут нести в себе хуки, которые изменяют какие-либо данные, переопределяют логику и, вместе с тем, вызывают проблемы в последствии по мере продолжения выполнения кода. Другая особенность состоит в том, что количество аргументов, передаваемых в обработчики событий, по умолчанию обрезается до одного, если явно не указано иное (отсылка к $accepted_args выше в коде). В каком таком случае мне вообще может это понадобиться и я не захочу получить все аргументы?

Оба этих момента иной раз приводят к кошмару во время процесса отладки.

Как насчет обработки ошибок?

Вместо использования встроенного в PHP стандартного механизма обработки ошибок и исключений, WordPress использует свой собственный велосипед. Получите, распишитесь. Вместо выбрасывания исключений и предоставления разработчику возможности поймать их и как следует обработать, WordPress возвращает (именно return, а не throw) экземпляр класса WP_Error , содержащий сообщение и код ошибки, ну вы знаете, прямо как исключение.

Что делает ситуацию еще смешнее — некоторые функции принимают аргумент, позволяющий выбрать что она будет возвращать при ошибке — WP_Error или false . Без комментариев.

Зато у WordPress куча классных плагинов и шаблонов оформления!

Возьмите всё то, что было перечислено до этого момента, добавьте всё то, что еще будет перечислено, затем умножьте на два. Вот что из себя представляют готовые сторонние плагины и шаблоны. Вас встретят: плохая и несогласованная между различными плагинами архитектура, злоупотребление экшенами и фильтрами, неэффективная работа с БД, в целом низкосортное качество кода.

Для меня самым занимательным тут кажется то, что в случае возникновения каких-либо проблем, связанных с поведением самого WordPress или одного из уже установленных плагинов, пользователь, как правило, думает, что установка еще одного плагина решит вопрос.

Ах, да. С каждым новым установленным плагином вы также повышаете шанс вот такого развития событий: «Критическая уязвимость в популярном плагине FancyBox for WordPress». Плагин с более 500 000 скачиваний. Любой мог просто отправить составленный определенным образом анонимный POST запрос WordPress’у, тем самым как угодно изменяя опции уязвимого плагина, среди которых есть опция вывода дополнительного содержания. XSS готов.

Стандарты написания кода

Вместо того, чтобы поддержать весь остальной PHP мир в использовании стандартов PSR или PEAR, разработчики WordPress решили написать свой собственный стандарт, который во многом противоположен вышеупомянутым.

Псевдо Cron задачи

Вместо того, чтобы использовать настоящий планировщик cron, для WordPress создали свой собственный, работающий на уровне PHP. Он сохраняет ссылки на колбэки в БД, а затем при помощи PHP запускает их при определенных событиях. Само собой он не работает всё время в фоновом режиме, как можно было бы подумать. Каждый раз когда кто-то заходит на сайт, происходит проверка cron задач и, если пришло время для какой-то из них, то она выполняется. Может на минуту позже, может на несколько часов.

В результате можно найти кучу заметок о том, как отключить wp_cron и подключить настоящий. И еще вот такие: Why WP-Cron sucks. Там уже про негативное влияние WP-Cron на скорость работы высоконагруженных сайтов.

Нарезка изображений

При загрузке изображения в библиотеку медиафайлов WordPress нарезает его на разные размеры. По умолчанию жестко заданы 3 размера: миниатюра (150х150), средний размер (300х300), крупный размер (1024х1024). В панели управления можно изменить ширину и высоту каждого из этих размеров, но не удалить или добавить новый размер. Для добавления размера нужно залезть в код и воспользоваться функцией add_image_size().

Представим, что мы установили тему оформления, разработчик которой добавил следующий код в файл темы functions.php, в котором предлагается описывать дополнительные функции для работы темы и устанавливать параметры ядра WordPress:

Теперь загрузим, к примеру, фотографию foobar.jpg размером 1600х1600. Вне зависимости от вашего желания и не предоставляя какой-либо возможности выбора, WordPress создаст в директории wp-uploads следующие файлы: foobar.jpg (оригинальный загруженный файл), foobar-150×150.jpg, foobar-300×300.jpg, foobar-1024×1024.jpg, foobar-400×400.jpg, foobar-220×180.jpg. То есть в нашем случае по 6 файлов на 1 загруженное изображение, даже если вы просто хотели вставить на страницу оригинальное изображение и вам не нужна вся остальная нарезка. Когда мы загрузим еще 300 изображений, файлов будет уже 1800, большая часть которых никогда не будет использована и просто мертвым грузом будет лежать на жестком диске. А если у нас еще установлены плагины, которые тоже добавляют свои размеры? Сколько тогда файлов будет создаваться на 1 изображение?

Если мы захотим поменять тему оформления на новую, которая задает уже свои, другие размеры и предполагает использование именно их, то всё сломается. Ведь ранее загруженные изображения уже нарезаны иначе. В этом случае предлагается решать проблему с помощью стороннего плагина, например Regenerate Thumbnails, который удалит всю старую нарезку и из хранящихся оригиналов изображений сделает новую по обновленным правилам. Почему такой в общем-то несложный и достаточно важный функционал не встроен в сам WordPress — для меня загадка.

Топ-пост этого месяца:  иерархическое меню в сайдбаре (виджет)

Заключение

Может показаться, что я ненавижу WordPress. Вовсе нет. Я имею дело с этой CMS с 2.* версий, приблизительно с 2009го года, с её помощью за прошедшее время мне довелось сделать не один десяток сайтов, за это я благодарен. Мы активно используем WordPress в студии, где я сейчас работаю и вряд ли сможем в скором времени его заменить на что-то более эффективное, хотя с интересом наблюдаем за развитием October CMS (CMS на базе PHP фреймворка Laravel) и фантазируем о миграции после выхода стабильной версии.

Сайт w3techs приводит следующую статистику на январь 2015го года — WordPress используют 23% сайтов из проанализированных топ 10 миллионов сайтов по рейтингу Alexa. Доля среди других CMS по этой выборке равна 60%. Следом идет Joomla с 7.5%, отрыв огромен. Откуда такая популярность? Почему я в своё время и огромное количество других людей выбрали WordPress? Видимо играет роль большая дружественность интерфейса управления сайтом, простота установки и использования, все эти тысячи готовых плагинов и шаблонов, низкий порог вхождения для того чтобы, простите, наговнокодить что-то своё. Эти качества отвечают всему тому, что так важно типичному веб-мастеру или человеку, которому просто нужен свой блог с фотографиями котиков. Людям, которые и близко не являются инженерами и не хотят ничего слышать про какие-то архитектуры, хуки и т.д.

Не стоит также забывать про сервис wordpress.com, позволяющий быстро создать сайт на основе WordPress, не заботясь о покупке хостинга и самостоятельной установке CMS. Обслуживает более 60 миллионов сайтов. Сервис создан в 2005м году компанией Automattic, которая вносит огромный вклад в развитие WordPress. И, как мне кажется, это напрямую связано с тем, что в новости об очередном грядущем обновлении WordPress указаны такие вещи, как новая тема оформления, улучшения в интерфейсе работы с текстом, удобное выравнивание изображений, новая вкладка «рекомендованные плагины» и прочая мишура. Это то, что нужно целевой аудитории. А в разделе для разработчиков написано, что поправлено куча багов. И никакого намека на глобальное улучшение ситуации. Это можно понять, нельзя так просто взять и всё отрефакторить, да и, опять же, целевой аудитории это не нужно. Поэтому я не верю в какие-либо действительно значимые позитивные изменения в техническом отношении.

В завершение приведу цитату из интервью с Алексеем Бобковым, разработчиком October CMS. Цитату, которая, на мой взгляд, очень точно описывает ситуацию с WordPress:

С какими CMS ты до этого работал и почему решил написать свою CMS?
Приходилось работать с разными CMS. Интерфейс многих CMS выглядит так плохо, что руки опускаются с ними работать. Я не люблю ругать чужие продукты, поэтому не буду перечислять названия, кроме одного. WordPress неплох, но уже видно, что это приложение старой школы. Даже лучшие (популярные) плагины для него это чистейшее спагетти из кода PHP и разных файлов. Чтобы разобраться что к чему и что-то починить требуется уйма времени и каких-то специальных знаний, для получения которых нужно перелопачивать форумы и блоги, в которых люди в основном задают такие же вопросы и не получают внятных ответов.
Хочется иметь что-то простое и гибкое, настоящую платформу для разработки сайтов и приложений, с красивым интерфейсом и продуманным подходом к расширяемости. Нечто такое, что можно описать несколькими страницами документации и чтобы люди, которые будут это использовать, могли тратить время на более приятные вещи, чем решение простых задач сложным способом.

WordPress. Порядок загрузки страницы

Итак, пользователь набрал в адресной строке браузера URL WordPress-сайта и нажал Enter. Произошел резолвинг доменного имени, и браузер обратился по конкретному IP-адресу к хостинг-серверу с запросом на загрузку сайта. Что происходит дальше в последующие доли секунды, пока сайт не отобразится в окне браузера?

1. Загрузка файла wp-load.php

Все начинается с загрузки файла wp-load.php в корневом каталоге сайта.

2. Загрузка файла wp-config.php

Это главный конфигурационный файл, содержит информацию для подключения к базе данных и устанавливает некторые константы.

3. Загрузка файла wp-settings.php

Установка значений констант WP_MEMORY_LIMIT , WP_MAX_MEMORY_LIMIT , WP_DEBUG , SCRIPT_DEBUG , WP_CONTENT_DIR , WP_CACHE и других.

4. Загрузка файла advanced-cache.php

Загрузка advanced-cache.php , если этот файл существует. В терминологии плагинов WordPress этот файл является так называемым «вкраплением». Он создается автоматически, если на сайте установлен один из кеш-плагинов. Этот файл содержит конфигурационную информацию для работы кеширования.

5. Загрузка файла wp-content/db.php

WordPress позволяет разработчикам создавать свои абстрактные слои БД и загружать их через файл db.php . Как правило, этот файл используется кеш-плагинами для оптимизации работы БД. Поэтому, если такой файл существует, он загружается на этом этапе.

6. Подключение к базе данных

Соединение с сервером MySQL и подключение к указанной в wp-config.php или db.php базе данных. Если по какой-то причине WordPress не удается подключиться к БД — будет выдано сообщение «Error establishing database connection».

7. Загрузка файла object-cache.php или wp-includes/cache.php

Загрузка файла object-cache.php , если такой есть. Если нет, попытка загрузить файл cache.php в директории wp-includes . Если и этого файла нет, то следующий шаг.

8. Загрузка файла wp-content/sunrise.php

Если сайт является частью сети (режим Multisite), то будет загружен файл wp-content/sunrise.php .

9. Загрузка библиотеки локализации

Загрузка файла wp-includes/l10n.php для включения системы локализации. На данном этапе будет учтен выбранный язык, региональные параметры и файлы для перевода.

10. Загрузка must use плагинов

Загрузка обязательных к использованию плагинов. Это плагины, которые устанавливаются в специальную папку mu-plugins и которые всегда активны для сайта и сайтов сети.

11. Запуск события muplugins_loaded

Т.е. будет вызвана функция do_action() с параметром muplugins_loaded . Как следствие — будут вызваны все функции, привязанные к этому событию с помощью add_action() .

12. Загрузка всех активированных плагинов

Список активированных плагинов хранится в таблице wp_options базы данных, имя опции — active_plugins . Таким образом на этапе загрузки игнорируются все установленные, но неактивные плагины.

13. Загрузка файла pluggable.php

Файл pluggable.php хранит функции, которые могут быть переопределены WordPress-плагинами. WordPress проверит, определены ли функции из файла pluggable.php какими-то другими активными плагинами. Если нет, будут определены функции из pluggable.php .

14. Запуск события plugins_loaded

Т.е. будет вызвана функция do_action() с параметром plugins_loaded . Как следствие — будут вызваны все функции, привязанные к этому событию с помощью add_action() .

15. Загрузка Rewrite Rules

Будут загружены правила преобразования ссылок. Другими словами, на сайте все ссылки будут search engine friendly, вместо ссылок вида www.server.com/?p=12345

16. Инициализация $wp_query, $wp_rewrite, $wp

Инициализация глобальных переменных:

  • $wp_query — содержит экземпляр класса WP_Query
  • $wp_rewrite — содержит экземпляр класса WP_Rewrite
  • $wp — содержит экземпляр класс WP

17. Запуск события setup_theme

Т.е. будет вызвана функция do_action() с параметром setup_theme . Как следствие — будут вызваны все функции, привязанные к этому событию с помощью add_action() .

18. Загрузка файла functions.php дочерней темы

Файл functions.php содержит набор функций, применимых для каждой темы оформления индивидуально. При использовании дочерней темы, на на данном этапе будет загружен functions.php именно дочерней темы.

19. Загрузка файла functions.php родительской темы

Если используется дочерняя тема, то после загрузки functions.php из дочерней темы будет загружен functions.php родительской темы.

20. Запуск события after_setup_theme

Событие запускается после того, как WordPress определился с тем, какая тема оформления активна на данный момент, и загрузил ее файл functions.php .

21. Настройка текущего пользователя

Теперь WordPress загружает объект текущего пользователя. Это позволяет понять, какие запросы могут быть выполнены в дальнейшем в соответствии с текущей ролью пользователя и его привилегиями.

22. Запуск события init

На данном этапе WordPress загрузил уже все необходимое для работы. Это самое популярное событие у разработчиков — ядро загружено, плагины и тема активированны, пользователь авторизован, но на экран еще ничего не выведено.

23. Запуск события widget_init

Событие позволяет регистрировать виджеты и выполнять код, необходимый для их работы.

24. Выполнение функции wp()

Теперь WordPress вызывает функцию wp() из файла wp-includes/functions.php . Эта функция устанавливает основной запрос, т.е. среду WordPress.

Посмотрим на код, как устанавливается среда WordPress:

Фильтр request срабатывает в конце метода WP::parse_request() , позволяя изменить свойство WP::query_vars , которое содержит переменные запроса, используемые в методе WP::query_posts() .

Фильтр parse_request срабытывает в конце метода WP::parse_request() , сразу после фильтра request . В фильтр передается экземпляр класса WP по ссылке, так что можно изменить не только переменную класса $query_vars , но и другие переменные.

Фильтр pre_get_posts срабатывает абсолютно для всех запросов, не только для основного. Для основного запроса (из кода выше) он срабатывает во время вызова метода WP::query_posts() , т.е. после request и parse_request .

Фильтр wp срабытывает в конце метода WP::main() , в этот момент записи уже получены. В фильтр передается экземпляр класса WP по ссылке. Это самое раннее событие, когда работают условные теги.

25. Запуск события template_redirect

Событие происходит прямо перед тем, как WordPress определяет, какой шаблон должен быть использован.

26. Загрузка feed-шаблона для RSS

Если запрашиваемый контент относится к RSS-feed, WordPress загружает соответствующий feed-шаблон.

27. Загрузка основного шаблона (темы)

WordPress начинает загружать файлы текущей активной темы в соответствии с ее иерархией. Как правило, все начинается с файла, который содержит главный цикл.

28. Запуск события shutdown

В самом конце, перед завершением исполнения всего PHP-кода WordPress запускает последнее событие shutdown . На этом этапе работа WordPress закончена.

Практическое руководство. Проверка глобальных переменных в WordPress

Люди часто путаются о том, как получить данные из глобальных объектов /переменных

Вопрос: . Каким образом вы можете проверять глобальные переменные?

Этот Q был написан, потому что он очень часто встречается здесь в WA. Я просто хотел иметь это как fav для ссылки здесь (люди часто не смотрят на github gist links).

Не стесняйтесь модифицировать пример, если что-то не так, или вы думаете, что в объяснении чего-то не хватает. Если вы хотите добавить другие полезные материалы, добавьте их как один ответ. Спасибо.

3 ответа

Как проверить данные:

Используйте это, чтобы получить представление о том, что вы можете использовать из текущего запроса /wp_query.

‘; > // If you’re looking at other variables you might need to use different hooks // this can sometimes be a little tricky. // Take a look at the Action Reference: http://codex.wordpress.org/Plugin_API/Action_Reference add_action( ‘shutdown’, ‘inspect_wp_query’, 999 ); // Query on public facing pages add_action( ‘admin_footer’, ‘inspect_wp_query’, 999 ); // Query in admin UI

Как получить данные:

Примеры
Список всех имен боковой панели?
(Создайте выпадающий /выберите объект со всеми боковыми панелями внутри global $wp_registered_sidebars ).

Топ-пост этого месяца:  Реклама у блогеров в Инстаграм сколько стоит, как заказать

Или, если вы ленивы, просто установите плагин Отладка> .

Он добавляет кнопку в панель администратора, которая при нажатии открывается панель со всеми полезными сведениями, включая уведомления об исключении, переменные WP_Query и журнал запросов SQL.

В зависимости от того, где в процессе загрузки скриптов и получения окончательного вывода некоторые из перечисленных выше переменных могут отсутствовать. Если вы хотите довольно инклюзивный вид, возможно, немного экстремальный, попробуйте:

var_dump также хорош в том, что говорит вам тип и форматы данных немного.

Доступ к глобальной переменной в «CSS» (style.php)

Я делаю CSS-файл style.php, поэтому я могу использовать некоторые динамические переменные в CSS в рамках установки WordPress:

Как получить доступ к глобальной переменной из файла style.php или передать ей переменную?

Код, который я пытаюсь работать в CSS, похож на

  • Игнорируйте проблему кэширования. Это всего лишь личный проект.
  • Передача переменной в ссылке на таблицу стилей слишком сложна для этого (на мой взгляд).

EDIT: Как немного больше объяснений: то, что я делаю, генерирует целую тему, основанную на нескольких цветах, и вычисляет оттенки для эффектов зависания и т. Д. Примерно 50% стилей имеют в себе некоторый PHP. Все работает отлично, если я вручную вводить цвета в style.php, но я пытаюсь сделать его еще проще для менее искусных людей и использовать подборщик цветов.

Для доступа к функциям wordpress вам необходимо включить следующие строки поверх вашего файла style.php.

Первая строка сообщает wordpress не запускать связанные с темой процессы, а вторая строка запускает механизм wordpress. После этого вы получите доступ к функциям wordpress и глобальным переменным.

Вот альтернативное решение для встраивания php в таблицу стилей WordPress .css (полезность, на которую я не уверен), которая не требует манипуляции с ядром WordPress.

Просто создайте встроенный CSS-файл php в директории темы, содержащей обычный код:

10 полезных приемов по работе с hook’ами в WordPress

Механизм hook’ов (перехватчиков событий) — крайне полезная вещь в WordPress. Они позволяют «подцепить» к некоторым функциям свои собственные, а значит — откорректировать функции WordPress без редактирования базовых файлов. В этой статье мы собрали 10 действительно полезных hook’ов вместе с примерами и объяснениями кода.

Что такое Hook?

Чтобы добиться в блоге WordPress определенного эффекта, нужно изменить способ его работы. В таких случаях зачастую вносятся модификации в файлы, которые разработчики WordPress именуют базовыми — необходимыми для корректной работы WordPress.

Редактирование базовых файлов всегда чревато неприятностями, включая появление брешей в безопасности. Кроме того, после обновления WordPress все изменения будут утеряны.
И все же некоторые функции разработчикам WordPress приходится переписывать, поэтому и появились программные надстройки Plugin API.

Hook’и — один из основных «строительных материалов» для программных модулей WordPress. Практически все модули переписывают базовые функции WordPress с помощью hook`ов.

Как использовать hook’и в блоге WordPress

Все hook`и прописываются в файле «functions.php» (если только речь не идет о создании программного модуля). Данный файл можно найти в папке «wp-content/themes/yourtheme».

Как мы уже говорили, hook`и-перехватчики переопределяют одни функции на другие. Так, например, создав собственную функцию, можно подключить ее к одной из базовых функций WordPress.

В нашем случае мы переопределяем собственную функцию на программную функцию публикации записей «publish-post». Каждый раз при выполнении «publish-post» WordPress будет выполнять и связанную с ней функцию.

Само собой, любые hook`и можно удалить посредством функции «remove_action()».

1. Отключение автоматического форматирования WordPress

Проблема. Возможно, вы заметили, что по умолчанию WordPress заменяет прямые кавычки “парными” и выполняет некоторые другие незначительные действия по форматированию при отображении записи.

Для публикующих нормальное наполнение такая опция удобна, но любого, кто в собственном блоге обсуждает код, это серьезно раздражает: при вставке в текстовый редактор парные кавычки возвращают синтаксическую ошибку.

Решение. Достаточно вставить в файл «functions.php» представленный ниже код:

После этого можно использовать в записях сокращение «[raw]».

Анализ кода. Первым шагом мы создаем функцию, с помощью обычного выражения ищущую в наполнении записей сокращение «[raw]».

После привязываем функцию «my_formatter()» к программной функции «the_content()». Соответственно, каждый раз при обращении к функции «the_content()» автоматически будет вызываться и «my_formatter()».

Для удаления автоматического форматирования воспользуемся функцией «remove_filter()», позволяющей избавиться от hook’а для конкретной функции.

2. Распознавание браузера посетителя с помощью hook’а

Проблема. Кросс-браузерная совместимость — едва ли не самая распространенная проблема веб-разработчиков. Возможность распознавать браузеры посетителей веб-сайта снимет массу вопросов — если после распознавания создать собственный класс, заключенный в тэг «body». Хотя об этом знают немногие, в WordPress уже реализована возможность распознавания браузеров плюс предусмотрено несколько глобальных переменных.

Решение. Ничего сложного: вставьте представленный ниже код в файл «functions.php». Теперь осталось его просто сохранить!

После сохранения файла функция будет автоматически добавлять класс таблиц стилей к тэгу «body», как в приведенном ниже примере:

Анализ кода. Глобальные переменные WordPress возвращают «true» при использовании посетителем определенного браузера. Если это Google Chrome, значение «true» вернет переменная «$is_chrome». Поэтому мы создаем функцию «browser_body_class()», возвращающую название браузера пользователя. После этого достаточно переопределить ее на программную функцию «body_class()».

3. Распознавание текста в редакторе TinyMCE

Проблема. Многие блоггеры почти во всех записях используют один и тот же стиль. Записи в моем собственном блоге WpRecipes.com всегда выводятся одинаково: часть текста, часть кода, потом еще текст.
Возможно, стоит сэкономить время, сделав так, что текст по умолчанию будет отображать tinyMCE (визуальный редактор WordPress).

Решение. И снова на помощь приходят hook’и. Откройте файл «functions.php», вставьте код — и предоставьте все остальное им!

Анализ кода. Несмотря на широкие возможности кода, сам метод достаточно просто. Просто создайте функцию, которая возвращает нужный текст (в нашем примере простой текст с предложением о подписке на RSS-ленту блога). Теперь достаточно «подцепить» ее к программной функции «default_content()».

4. Автоматическая вставка наполнения после каждой записи

Проблема. Для вставки после записи текста, изображений или рекламы в блогах чаще всего используется шаблон «single.php». Само собой, для этого можно открыть «single.php» и после функции «the_content()» внести нужный текст. Но что если текст не отображается в RSS-ленте? Решить проблему помогут hook’и и описанный ниже прием.

Решение. И снова просто вставьте код в относящийся к нужной теме файл «functions.php». Вот и все.

Анализ кода. Задача функции «insertFootNote()» предельно ясна: она сцепляет определенный текст с переменной «$content», включающей содержимое записи.

Затем наша функция «insertFootNote()» переопределяется на функцию «the_content()», автоматически вызываясь каждый раз при обращении к «the_content». Принцип работы с данной функцией аналогичен набору текста в конце каждой записи.

Обратите внимание на условие «(!is_feed)» в строке 2, препятствующее вставке текста в RSS-ленту. Чтобы снять это ограничение, замените строку 2 на следующий код:

5. Отключение сообщения «Please Update Now» на консоли WordPress

Проблема. При выходе новой версии WordPress консоль автоматически дает об этом знать, выводя сообщение в верхнюю часть интерфейса администратора. Вещь это, конечно, нужная, ведь для блога обновления — это новые функции и доработки по безопасности. Но если блог делается под заказ, сообщения об обновлениях уместны далеко не всегда.

Решение. В файл «functions.php» достаточно добавить четыре строки кода.

После сохранения файла «functions.php» сообщения на консоли вы больше не увидите.

Анализ кода. Первым делом нужно убедиться, что у текущего пользователя есть права администратора, достаточные для обновления WordPress. После этого создаем два hook’а, переписывающие автоматическую проверку обновлений с выводом сообщений.

6. Отключение автосохранения записей в WordPress

Проблема. При наборе записи через консоль WordPress периодически сохраняет ее наполнение. Это полезная функция, но иногда возникает потребность ее отключить.

Решение. Для отключения автосохранения в WordPress откройте файл «functions.php» и вставьте следующую функцию:

Анализ кода. И вновь ничего сложного. Мы просто создаем действие (в строке 4) и переопределяем созданную в строке 1 функцию «disableAutoSave()» на программную «wp_print_scripts()».

В результате наша функция «disableAutoSave()» вызывается при каждом выполнении программой «wp_print_scripts()». Тем самым мы отключаем автосохранение в WordPress.

7. Борьба с дублированием наполнения на странице комментариев

Проблема. Дублирование наполнения — SEO-проблема многих сайтов. Она может стать актуальной и для вашего блога, если только не воспользоваться некоторыми хитростями.

Появившийся в версии 2.7 постраничный вывод комментариев (paged comments) стал ценным дополнением к WordPress, поскольку теперь блоггеры получили возможность разбивать массу комментариев на несколько страниц. Единственная проблема при этом, как уже упоминалось выше, — риск дублирования наполнения.

Чтобы избежать дублирования в постраничных комментариях, воспользуемся новым атрибутом rel=»canonical».

Решение. Просто вставьте представленный ниже код в файл «function.php».

Анализ кода. Первым шагом создаем функцию, добавляющую к комментариям страниц (за исключением страницы 1) атрибут rel=»canonical». После переориентируем ее на программную функцию «wp_head()». Только и всего!

8. Превращение записи или страницы в PHP-переменную

Проблема. Возможность превратить текущую запись или страницу в PHP-переменную определенно полезна. Среди прочего можно, например, заменить часть наполнения с помощью PHP-функции «str_replace()».

Решение. И снова ничего сложного. Просто вставьте код в файл «functions.php».

Анализ кода. Для этого приема нам понадобятся три функции:
— callback(): данная функция возвращает страницу целиком в виде переменной «$buffer». Перед этим можно модифицировать ее с помощью стандартных выражений.
— buffer_start(): данная функция просто запускает буфер, переопределяясь на программную функцию «wp_head()».
— buffer_end(): данная функция очищает буфер, переопределяясь на программную функцию «wp_footer()».
Как только наша функция будет готова, просто свяжем ее с программными функциями WordPress.

9. Планирование событий с помощью Cron и hook’ов

Проблема. Как вы, возможно, знаете, в WordPress есть возможность планировать события, например, публикуя записи в предварительно заданные дни и часы. С помощью hook’ов и «wp-cron» легко запланировать свои собственные события. В нашем примере блог WordPress раз в час будет отправлять нам электронное сообщение.

Решение. Вставьте блок с приведенным ниже кодом в относящийся к нужной теме файл «functions.php».

Анализ кода. Первым делом, мы, конечно же, создали функцию, выполняющую нужное действие. В данном примере это функция «my_task_function()», которая просто отправляет сообщение на указанный адрес электронной почты.

Чтобы запланировать событие, воспользуемся функцией «wp_schedule_event()». Последним аргументом должен быть hook, вот почему мы переопределяем функцию «my_task_function()» на «my_task_hook».

10. Вывод всех функций с hook’ами

Проблема. Если что-то пошло не так, при отладке удобно видеть список всех связанных функций.

Решение. Как и в предыдущих примерах, достаточно вставить предложенный код в файл «functions.php». По окончании отладки не забудьте удалить его из файла, иначе служебное сообщение будет появляться и дальше.

Сделав это, просто вызовите функцию «list_hooked_functions()», как показано ниже, для вывода на экран всех функций WordPress с hook’ами.

Анализ кода. Если в качестве аргумента функции не дается имя hook’а, то hook’и выводятся на экран посредством глобальной переменной «$wp_filter». Альтернативный вариант: отображение в списке конкретного hook’а при передаче его имени в качестве атрибута:

Добавить комментарий