Блокнот Готтфрида Квадратного

Ноябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
	1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Про @font-face с пояснениями

26.05.16
14:27
4079
1

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

@font-face {
    font-family: 'FontFamily';
    /* остальные атрибуты */
    src: url('font.eot');   /* IE9-11, режимы совместимости 5-8 */
    src: url('font.eot?') format('embedded-opentype'), /* IE 6-8 */
         url('font.ttf')  format('truetype'),   /* Android, iOS, Safari */
         url('font.woff') format('woff'),
         url('font.svg#fontId') format('svg');  /* iOS */
}

1

2

3

4

5

6

7

8

9

@font-face {

font-family: 'FontFamily';

/* остальные атрибуты */

src: url('font.eot'); /* IE9-11, режимы совместимости 5-8 */

src: url('font.eot?') format('embedded-opentype'), /* IE 6-8 */

url('font.ttf') format('truetype'), /* Android, iOS, Safari */

url('font.woff') format('woff'),

url('font.svg#fontId') format('svg'); /* iOS */

}

Как обходиться с большим количеством AJAX в WordPress

24.05.16
20:50
2477
0

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

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

if (defined('DOING_AJAX') && DOING_AJAX && !empty($_REQUEST['action']))
    // выполняется AJAX-запрос
    add_action('plugins_loaded', 'myplugin_init_ajax');

function myplugin_init_ajax () {
    // определить обработчик по идентификатору действия
    // если подходящего обработчика нет, значит запрос принадлежит другому плагину
    // и его следует игнорировать;
    $action = $_REQUEST['action'];
    $fn = 'myplugin_ajax_' . $action;   // определить имя функции
    if (!is_callable($fn))              // и проверить её существование
        return; // нет такого обработчика - проигнорировать запрос
    // зарегистрировать хук в соответствии с авторизованностью посетителя:
    $hook = is_user_logged_in() ? 'wp_ajax_' : 'wp_ajax_nopriv_';
    add_action($hook . $action, $fn);
}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

if (defined('DOING_AJAX') && DOING_AJAX && !empty($_REQUEST['action']))

// выполняется AJAX-запрос

add_action('plugins_loaded', 'myplugin_init_ajax');

function myplugin_init_ajax () {

// определить обработчик по идентификатору действия

// если подходящего обработчика нет, значит запрос принадлежит другому плагину

// и его следует игнорировать;

$action = $_REQUEST['action'];

$fn = 'myplugin_ajax_' . $action; // определить имя функции

if (!is_callable($fn)) // и проверить её существование

return; // нет такого обработчика - проигнорировать запрос

// зарегистрировать хук в соответствии с авторизованностью посетителя:

$hook = is_user_logged_in() ? 'wp_ajax_' : 'wp_ajax_nopriv_';

add_action($hook . $action, $fn);

}

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

Про старые IE, EOT и CSS3111

18.05.16
18:22
7087
0

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

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

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

Прицельное размещение скриптов на экранах админки WordPress

13.04.16
21:52
6901
0

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

add_action('admin_enqueue_scripts', function () {
    $scr = get_current_screen();
    if ($scr->id == 'screen_id') {
        // поместить в очередь скрипты для экрана 'screen_id':
        wp_enqueue_style( ... );
        wp_enqueue_script( ... );
        ...
    }
});

1

2

3

4

5

6

7

8

9

add_action('admin_enqueue_scripts', function () {

$scr = get_current_screen();

if ($scr->id == 'screen_id') {

// поместить в очередь скрипты для экрана 'screen_id':

wp_enqueue_style( ... );

wp_enqueue_script( ... );

...

}

});

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

Про GET и POST для AJAX

09.04.16
19:35
4761
0

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

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

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

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

Простой измеритель скорости GET/POST AJAX-запросов

07.04.16
17:32
4200
0

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

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

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

Генератор рыбы

03.11.15
12:41
421566
0

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

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

Симптомы потери автоинкремента таблицами WordPress

19.07.15
12:15
46232
2

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

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

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

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

Восстановление ключей в таблицах WordPress

19.07.15
12:14
10368
14

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

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

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

Require all denied

1	Require all denied

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

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

Order Deny,Allow
Deny from all

1 2	Order Deny,Allow Deny from all

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

Починка ключей у таблиц WordPress при коллизиях

19.07.15
12:14
5582
0

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

mysql> ALTER TABLE wp_comments CHANGE comment_ID 
    -> `comment_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY;
ERROR 1062 (23000): ALTER TABLE causes auto_increment resequencing, resulting in duplicate
entry '1' for key 'PRIMARY'

1

2

3

4

mysql> ALTER TABLE wp_comments CHANGE comment_ID

-> `comment_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY;

ERROR 1062 (23000): ALTER TABLE causes auto_increment resequencing, resulting in duplicate

entry '1' for key 'PRIMARY'

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