• 26.05.16
  • 14:27
  • 147
  • 0

Блок @font-face, не содержащий шрифтов в виде base64 и ориентированный на поддержку в IE6-8, выглядит так:

  • 24.05.16
  • 20:50
  • 142
  • 0

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

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

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

  • 18.05.16
  • 18:22
  • 261
  • 0

Проблема: шрифт, преобразованный в формат EOT, не воспринимается браузерами IE6-8, а IE9+ выдают ошибку вида "CSS3111: В @font-face обнаружена неизвестная ошибка.":

CSS3111: В @font-face обнаружена неизвестная ошибка.

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

  • 13.04.16
  • 21:52
  • 185
  • 0

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

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

  • 09.04.16
  • 19:35
  • 175
  • 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
  • 173
  • 0

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

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

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

  • 03.11.15
  • 12:41
  • 398
  • 0

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

Генерация обычной рыбы также возможна, но, в отличии от, например, lipsum.org, «неудобные» термины — способные напоминать нечто осмысленное (а то и вовсе нецензурное) — из словарей не выбирались, поэтому нейтральность рыбы-текста не гарантирована.

  • 19.07.15
  • 12:15
  • 3900
  • 2

У одного ресурса, работающего на WordPress, возникли такие проблемы:

  • невозможно создать пост любого типа;
  • пользователи не могут зарегистрироваться;
  • при комментировании WordPress заявляет, что посетитель «комментирует слишком быстро» или что «комментарий сохранить не удалось», хотя сам комментарий после создания может корректно отображаться;
  • ни манипуляции с плагинами/темами, ни переустановка/обновление WordPress результата не дают.

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

Лечение описывается в заметке о лечении, а симптомы выглядят так:

  • 19.07.15
  • 12:14
  • 1543
  • 6

Дан ресурс на WordPress, у таблиц которого отсутствует автоинкремент и первичный ключ. Как так получилось — неизвестно, предполагать не буду. Ресурс проработал в таком состоянии почти месяц, в течение которого пользователи не могли регистрироваться, невозможно было создавать новые посты, наблюдались проблемы с комментированием.

Симптомы описаны здесь.

На время починки ресурса его следует запереть при помощи .htaccess, размещённом в корне сайта. Для apache 2.4 в .htaccess следует добавить строку

и закомментировать строку "Require all granted", если таковая имеется.

Для apache 2.2 и более старых версий .htaccess должен содержать

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

  • 19.07.15
  • 12:14
  • 482
  • 0

При починке таблиц после потери автоинкремента переопределение полей идентификаторов может привести к коллизиям. Выглядит это так:

Перенумеровать таблицу в этом случае можно обходным путём: