Рубрика: Программирование

  • 24.05.16
  • 20:50
  • 874
  • 0

За один запуск WordPress активирует не более одного хука wp_ajax_* — в случае, когда обрабатывается AJAX-запрос. При обработке не-AJAX-запросов эти хуки не активируются. Поэтому, когда количество обработчиков AJAX велико, регистрировать их все сразу нет смысла.

В самом начале обработки запроса скрипт /wp-admin/admin-ajax.php задаёт константу DOING_AJAX как true, а действие, которое должно быть обработано, находится в $_REQUEST['action']. Этого достаточно, чтобы определить обработчик, который должен быть запущен. Если имена функций-обработчиков построены в виде "myplugin_ajax_{$action}", то регистрация нужного хука может выглядеть так:

После этого для добавления нового обработчика AJAX потребуется просто определить функцию с соответствующим именем.

  • 13.04.16
  • 21:52
  • 3799
  • 0

Ограничить выдачу скриптов и стилей определённым экраном можно так:

Список идентификаторов экранов WordPress приведён в конце заметки.

  • 09.04.16
  • 19:35
  • 1973
  • 0

Основное отличие заключается в методе отправки данных: в случае GET данные размещаются в URL, в случае POST — в теле запроса.

GET используется, когда

  • запрос не изменяет данных на сервере;
  • допустимо или желательно кеширование результата запроса браузером;
  • серверу передаётся небольшой набор данных — в URL-кодировании он должен заведомо умещаться в 2048 байт вместе с путём к скрипту, обрабатывающему запрос (для WordPress это /wp-admin/admin-ajax.php, поэтому длина URL-кодированных данных — не более 2023 байт);

    Такой предел задан браузером IE, ограничивающим длину URL 2083 знаками, из которых под путь и параметры отводится не более 2048.

    Если данные динамичны и могут не поместиться в URL, следует использовать метод POST.

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

    Единственным аргументом в пользу скорости GET-запросов является возможность их кеширования. В отсутствие кеширования скорости приблизительно равны.

  • 07.04.16
  • 17:32
  • 1971
  • 0

Помогает определить, насколько сильно скорость получения ответа сервера зависит от метода AJAX-запроса — GET или POST.

Результаты экспериментов показывают, что в firefox’е >=38, хроме >=48, старых операх (на presto; новые — на chrome) и IE 9-11 различия между GET и POST пренебрежимо малы — средняя разница редко превышает несколько десятков миллисекунд.

Иногда могут возникать неясные задержки, проявляющиеся в одном браузере и отсутствующие в других. В подобных случаях рекомендуется воспользоваться сниффером (напр. wireshark).

  • 20.06.15
  • 09:05
  • 676
  • 0

Автор: Pippin Williamson.
Оригинал: Using the WordPress Heartbeat API.

Замечание: перевод вольный, некоторые высказывания заменены на более понятные (на мой взгляд), и добавлены примечания. Все примечания опираются на WP 4.2.2.

— Г.К.

В WordPress 3.6 был введён новый API, называемый «WordPress Heartbeat». На нём основано множество сделанных в этой версии изменений, включая более развитую систему отслеживания ревизий, улучшенное управление пользовательскими сессиями и многое другое. Я собираюсь показать краткий пример использования этого API.

  • 07.06.15
  • 09:52
  • 983
  • 0

Эти функции похожи:

  • get_the_terms возвращает информацию о термах заданной таксономии, привязанных к заданному посту;
  • wp_get_object_terms возвращает информацию о термах одной или нескольких таксономий, привязанных к одному или нескольким постам, а также имеет ряд дополнительных опций.

Кроме этого каждая из них обладает другими особенностями, о которых надо знать.

  • 04.06.15
  • 15:13
  • 444
  • 0

Большинство параметров термов хранится в БД — они всегда присутствуют в объекте терма. Некоторые параметры добавляются функциями и в БД отсутствуют (на момент WordPress 4.2.2 таких параметров два — filter и object_id).

  • 03.06.15
  • 19:05
  • 1735
  • 2

В БД хранятся только термы и их метаданные. Информация о таксономиях находится на стороне PHP-кода.

Каждый терм имеет идентификатор, ярлык, имя и группу, а также связан со своей таксономией. Эта связь — «терм-таксономия» — обладает собственным идентификатором и привязывается к постам в качестве терма. К ней же относится его описание. Сам терм непосредственной связи с постами не имеет.

  • 13.05.15
  • 23:30
  • 478
  • 0

Одна из тем имеет сайдбары, оформление любого виджета или типа виджетов в которых задаётся на соотв. экране настройки. Интерфейс экрана должен содержать выпадающие списки виджетов и их типов.

Задача: составить списки виджетов и типов виджетов. При этом

  1. список всех зарегистрированных виджетов требуется в виде хеша $id_base => $name;
  2. список всех размещённых на сайдбарах виджетов должен быть сгруппирован по сайдбарам:
    Текст пунктов списка имеет вид "{$name} ({$title})", пустой заголовок не приводится; значения пунктов — идентификаторы виджетов.
  • 12.05.15
  • 21:44
  • 755
  • 0
Правый сайдбар

Правый сайдбар

Задача: сайдбары темы должны поддерживать несколько вариантов оформления виджетов (см. рис.) Соответствие вариантов виджетам задано в виде двухуровневого хеша:

id сайдбара => id_base типа виджета => вариант оформления.

Т. е. режим отображения виджета следует получать так:

Все режимы являются частью шаблонов (содержат фрагменты вёрстки) и не имеют настраиваемых параметров. Поэтому они заданы в виде массива $AVAILABLE_MODES прямо в коде темы.

Массив соответствия вариантов виджетам $a_widget_modes является настраиваемым и каким-либо образом задаётся администратором.

Решение задачи сводится к коррекции передаваемых виджету параметров сайдбара before_widget, after_widget, before_title и after_title.

Корректировка проводится фильтром 'dynamic_sidebar_params'. Фильтруемым значением является числовой массив, содержащий два элемента:

  • [0] — параметры сайдбара, идентификатор и имя виджета;
  • [1] — хеш с номером виджета.