Столкнулся с проблемой: когда пытался обновить wordpress до последней версии через админку, кликая по ссылке "обновить автоматчески", получал ошибку примерно такого содержания: "за 30 секунд скачано только 1700000 байт из 2600000, неудача". Оказалось, что шейпер на входящий трафик моего хостера не позволял за 30 секунд (а именно такой timeout был установлнен по умолчанию) стянуть весь диструбитив wordpress-а. Чтобы поменять этот тайм-аут, нужно в файле wp-admin/includes/file.php найти строку
Таким образом, мы вдвое увеличили время ожидания отработки запроса.
Дополнение от 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 что-то такое:
Чтобы удалить из базы данных ревизии постов (промежуточные их версии, которые образовываются в результате внесения изменений и дополнения постов), нужно выполнить такой простой SQL-запрос:
DELETEFROM 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
нужный нам html-блок. Этот блок удобно заключить в конструкцию <div id="myblock">...</div> и в файле со стилями CSS определить атрибуты для нашего блока. CSS-файл находится в директории /wp-content/themes/<имя_темы>/css/ и имеет имя, совпадающее с именем темы и расширение .css. Пример опеределения атрибутов:
div#myblock{padding-top:10px;text-align:center}
Если хотим, чтобы блоки с программным кодом красиво выделялись, как в этом посте – качаем и устанавливаем plugin Highlight Source Pro. Поддерживает более 90 языков, включая HTML, PHP, Perl, bash, CSS. Пример использования можно посмотреть на скриншоте.
Если при установке плагинов WordPress ничего не качает и вместо этого спрашивает "информацию для соединения", как на этом скриншоте, то это означает, что он не может получить доступ на запись в каталог /wp-content/plugins и надо проверить права доступа. Запрашиваемая информация для соединения – это атрибуты доступа к FTP-серверу, на котором работает WordPress. Это таким образом WordPress пытается пойти по обходному пути когда видит, что у него нет прямого доступа к файловой системе.
Если нужно отключить авто-замену двойного дефиса на красивое тире (а это бывает нужно, например, при публикации документации по linux-командам, ключи (параметры) которых часто именно и начинаются с '--', т.е. двух дефисов подряд), то нужно немного модифицировать код функции wptexturize. Для этого этот код
Похоже, что и в этой же функции происходит замена трех точек на unicode-символ троеточия и еще какие-то манипуляции с кавычками. Update от 2014-12-11: Все вышесказанное, начиная с версии 4.0, уже не актуально, так как formatting.php переписали почти с нуля и ранее упомянутого кода там уже нет. Более идеологически правильный способ избавиться от авто-замены (если честно, меня она просто ужасно бесит – я хочу видеть текст именно в том виде, в котором я его написал) – это добавить в начало файла /wp-content/themes/<ИМЯ_ВАШЕЙ_ТЕМЫ>/functions.php вот такой код:
Прелесть такого подхода в том, что эти правки не потеряются при очередном обновлении.
Если 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';
По-умолчанию в исходном коде страниц сайта присутствует META-тег generator, в котором указывается версия WordPress. Выглядит он примерно так:
От души желаю автору успешного развития блога. Почитал-посмотрел, очень всё понравилось. Побольше бы таких ресурсов в сети и не пришлось бы перебирать тонны никчёмных сайтов, а порой и с вирусами что бы найти нужную информацию. Удачи, бро :)
>> 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 раза больше. Посты после этого проверил - вроде все на месте, ничего лишнего не удалилось.
Кстати, еще полезняшка недавно пригодилась: если при обновлении WP пишет "Another update is currently in progress" и это напрягает, то можно выполнить такой SQL-запрос:
DELETE FROM wp_options WHERE option_name='core_updater.lock'
Чтобы wordpress "забыл", что он уже обновляется и чтобы можно было запустить процесс с нуля еще раз.
От души желаю автору успешного развития блога. Почитал-посмотрел, очень всё понравилось. Побольше бы таких ресурсов в сети и не пришлось бы перебирать тонны никчёмных сайтов, а порой и с вирусами что бы найти нужную информацию. Удачи, бро :)
>> 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
Интересно, я попробую.
Кстати, еще полезняшка недавно пригодилась: если при обновлении WP пишет "Another update is currently in progress" и это напрягает, то можно выполнить такой SQL-запрос:
DELETE FROM wp_options WHERE option_name='core_updater.lock'
Чтобы wordpress "забыл", что он уже обновляется и чтобы можно было запустить процесс с нуля еще раз.