В этой статье освещены следующие темы:
-
Тайм-аут при загрузке файлов с удаленных хостов
-
Отложенная публикация
-
Удаление черновиков
-
Статический блок в начале каждого поста
-
Подсветка кода
-
Проблемы с установкой плагинов
-
Отключение авто-замены
-
Запрет запуска скриптов из директории uploads
-
Сброс пароля пользователя
- Столкнулся с проблемой: когда пытался обновить wordpress до последней версии через админку, кликая по ссылке «обновить автоматчески», получал ошибку примерно такого содержания: «за 30 секунд скачано только 1700000 байт из 2600000, неудача». Оказалось, что шейпер на входящий трафик моего хостера не позволял за 30 секунд (а именно такой timeout был установлнен по умолчанию) стянуть весь диструбитив wordpress-а. Чтобы поменять этот тайм-аут, нужно в файле wp-admin/includes/file.php найти строку
-
$response = wp_remote_get($url, array('timeout' => 30));
и поменять ее, например, на
-
$response = wp_remote_get($url, array('timeout' => 60));
Таким образом, мы вдвое увеличили время ожидания отработки запроса.
Дополнение от 2010-01-24. Начиная с версии 2.9.1, таймаут по умолчанию в 300 сек (или 5 минут). Так что теперь эта проблема будет встречаться намного реже.
-
- Отложенная публикация в wordpress 2.7. Чтобы заметки, запланированные на публикацию в будущем таки появлялись в блоге, нужно в cron добавить вызов скрипта wp-cron.php c параметром check. Значение параметра легко определить, временно добавив перед строкой
-
if ( $_GET['check'] != wp_hash('187425') );
что-то типа
-
echo(wp_hash('187425'));
Тогда, набрав в адресной строке броузера http://<вашблог>/wp-cron.php, можно увидеть значение хеша (46cbe1674da1d2888104482d6ed4f87f). Следовательно, из крона обращаться к http://<вашблог>/wp-cron.php?check=46cbe1674da1d2888104482d6ed4f87f. Естественно, для предотвращения DoS-атак лучше заменить стандартную последовательность 187425 на что-то другое. В WordPress 2.8.2 в файле wp-cron.php уже нет такой проверки, поэтому достаточно его просто вызывать без параметров, например добавив в системный cron что-то такое:
-
wget http://avz.org.ua/wp-cron.php -O /dev/null 2> /dev/null
-
- Чтобы удалить из базы данных ревизии постов (промежуточные их версии, которые образовываются в результате внесения изменений и дополнения постов), нужно выполнить такой простой SQL-запрос:
-
DELETE FROM wp_posts WHERE post_type='revision';
Есть еще и более изящный и правильный метод удаления черновых заметок, который описан ниже в комментариях. Другие возможные значения поля ‘post_type’ – attachment, page, post (для версии 2.8.4). Чтобы вообще запретить создание ревизий, нужно в файл wp-config.php добавить строку
-
define('WP_POST_REVISIONS', false);
-
- Если нужно, чтобы вверху над каждым постом отображался один и тот же блок HTML-кода, можно сделать так. Находим файл /wp-content/themes/<имя_темы>/content/content-default.php, и вставляем в него перед вот этой 25-ой строкой
content-default.php
-
<div id="post-content-<?php the_ID() ?>" class="hentry full <?php sandbox_post_class() ?>">
нужный нам html-блок. Этот блок удобно заключить в конструкцию <div id="myblock">…</div> и в файле со стилями CSS определить атрибуты для нашего блока. CSS-файл находится в директории /wp-content/themes/<имя_темы>/css/ и имеет имя, совпадающее с именем темы и расширение .css. Пример опеределения атрибутов:
-
div#myblock {padding-top: 10px; text-align: center}
-
- Если хотим, чтобы блоки с программным кодом красиво выделялись, как в этом посте – качаем и устанавливаем plugin . Поддерживает более 90 языков, включая HTML, PHP, Perl, bash, CSS. Пример использования можно посмотреть на .
- Если при установке плагинов WordPress ничего не качает и вместо этого спрашивает «информацию для соединения», как , то это означает, что он не может получить доступ на запись в каталог /wp-content/plugins и надо проверить права доступа. Запрашиваемая информация для соединения – это атрибуты доступа к FTP-серверу, на котором работает WordPress. Это таким образом WordPress пытается пойти по обходному пути когда видит, что у него нет прямого доступа к файловой системе.
- Если нужно отключить авто-замену двойного дефиса на красивое тире (а это бывает нужно, например, при публикации документации по linux-командам, ключи (параметры) которых часто именно и начинаются с ‘--’, т.е. двух дефисов подряд), то нужно немного модифицировать код функции wptexturize. Для этого этот код
/wp-includes/formatting.php
-
$static_characters = array_merge(array('—', ' -- ', '--', ' — ', 'xn–', '…', '«', '\'s', '\'\'', ' ™'), $cockney);
-
$static_replacements = array_merge(array('—', ' — ', '–', ' – ', 'xn--', '…', $opening_quote, '’s', $closing_quote, ' ™'), $cockneyreplace);
меняем на этот код:
/wp-includes/formatting.php-
$static_characters = array_merge(array('—', ' — ', 'xn–', '…', '«', '\'s', '\'\'', ' ™'), $cockney);
-
$static_replacements = array_merge(array('—', ' – ', 'xn--', '…', $opening_quote, '’s', $closing_quote, ' ™'), $cockneyreplace);
Похоже, что и в этой же функции происходит замена трех точек на unicode-символ троеточия и еще какие-то манипуляции с кавычками.
-
- Если WordPress живет на сервере с Apache, то для запрета выполнения PHP- и CGI-скриптов в директории, куда wordpress сохраняет пользовательские файлы (/wp-content/uploads), достаточно положить туда файл .htaccess следующего содержания:
/wp-content/uploads/.htaccess
-
<FilesMatch "\.(phtml|php3?|pl|cgi)$">
-
Deny from all
-
</FilesMatch>
Это весьма рекомендуется сделать, поскольку снижает риск успешного взлома в случае, если злоумышленнику каким-то образом удастся загрузить php-shell или другие инструменты для своих темных делишек – запустить он их так просто не сможет. Также очень рекомендуется по возможности запрещать в firewall-е установку исходящих соединений с сервера хостинга на удаленные ресурсы.
-
- Для изменения пароля пользователя (например, если он был успешно забыт) достаточно одного простого SQL-запроса. Например, чтобы установить для пользователя admin пароль Gyhusdf3f, делаем так:
-
UPDATE wp_users SET user_pass=MD5('Gyhusdf3f') WHERE user_login='admin';
-
Популярность: 3%

Комментариев: 5
Чтобы быть всегда в курсе здесь происходящего, Вы можете подписаться на RSS feed для комментариев на эту заметку.
От души желаю автору успешного развития блога. Почитал-посмотрел, очень всё понравилось. Побольше бы таких ресурсов в сети и не пришлось бы перебирать тонны никчёмных сайтов, а порой и с вирусами что бы найти нужную информацию. Удачи, бро :)
>> DELETE FROM wp_posts WHERE post_type = «revision»;
не совсем правильно
Лучше так
DELETE `p`, `pm`, `c`, `tr`
FROM `wp_posts` AS `p`
LEFT JOIN `wp_postmeta` AS `pm`
ON `p`.`ID` = `pm`.`post_id`
LEFT JOIN `wp_comments` AS `c`
ON `p`.`ID` = `c`.`comment_post_ID`
LEFT JOIN `wp_term_relationships` AS `tr`
ON `p`.`ID` = `tr`.`object_id`
WHERE
`p`.`post_type` = ‘revision’;
Похоже на то.
запрос DELETE FROM wp_posts WHERE post_type = «revision» находит 46 строк. А при выполнении запроса, предложенного Igor Bredikhin, mysql сказал «92 rows affected», то есть в 2 раза больше. Посты после этого проверил — вроде все на месте, ничего лишнего не удалилось.
Запрос
DELETE FROM wp_posts WHERE post_type = «revision»
оставляет осиротевшими связанными записи в wp_postmeta и wp_term_relationships
Интересно, я попробую.