I like WP2.7

Все таки как бы не критиковали авторов, что они так долго тянут выпуск новой версии и многое поменяли в админке, но изменения эти очень радуют. За время тестирования новой версии она мне так понравилась что возвращаться на 2.6.3 уже не хочется. Вчера я обновился до 2.7-beta2-9665, пофиксил некоторые плагины, для которых вышли обновления и внес исправления которые нашел сам методом тыка. Все работает, да и скорость работы просто отличная. Отчего были тормоза и большое потребление памяти на «тестовом» блоге до сих пор непонятно…

31 комментарий

Снижение потребления ресурсов WordPress

Если кто знает, то одно из отличий версий WordPress 2.3.1-2.3.3 сборки Maxsite.org от оригинальной было то что использовались различные языковые файлы для админчасти блога и самого «лица» блога. Тогда это давало существенный прирост в скорости работы сайта, за счет уменьшения вызовов этих самых строк (более подробно можете почитать в его свежем посте о MaxSite CMS, где снова была затронута эта тема). Как я уже там отметился в коментах — попробовал тоже самое сделать в свежей версии 2.7 (на последней бете) на своем сайте. Результат просто поразительный.  Повторю цитаты из моих коментов по ссылке выше:

если файл локализации (полновесный ru_RU.mo весит 350кб) установлен как обычно, то
MySQL: 45запросов / 0.577 Потребление памяти: 13.3MB
а если его убрать вообще, то
MySQL: 45запросов / 0.550 Потребление памяти: 10.1MB
если подсунуть вместо «полновесного ru_RU.mo» кастрированный файл который «ru_RU_lite» переименовав его в ru_RU.mo то потребление памяти вырастает всего килобайт на 300 вместо трех мегабайт

замена в конфиге строки стандартной

define ('WPLANG', 'ru_RU');

на

if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU'); else define ('WPLANG', 'ru_RU_lite');

снизило потребление на главной странице до…7,7мб.

Пересмотрел я все плагины что у меня стоят и для перевода «лицевой» части блога потребовалось лишь скопировать несколько файлов имяплагина-ru_RU.mo в имяплагина-ru_RU_lite.mo, вообще бОльшая часть плагинов ведь переводится только в админ-части, поэтому и у вас получится всего несколько файлов отдельных переводов по 2-30кб.

В итоге получилось (для главной страницы) примерно так MySQL: 45запросов / 0.441 Потребление памяти: 8.6MB

Даже без калькулятора понятно что 8,6мб это существенно меньше оригинальных 13,3мб. Скорость загрузки страниц также повысилась

Испытание на «голом» сайте WP2.7 также показало снижение нагрузки примерно на 3мб и время генерации страницы в среднем на 0,1сек

Возник закономерный вопрос нужно ли в дистрибутив ВП сразу добавить такую опциональную строку конфиг и файлы ru_RU_lite для плагинов, чтобы желающие могли самостоятельно за пару минут путем редактирования конфига снизить потребление ресурсов.

Добавить ли такую опцию для снижения нагрузки в дистрибутив WP2.7 ?

  • Да (97%, 188 голосов)
  • Нет (3%, 6 голосов)

Всего проголосовало: 194

Загрузка ... Загрузка ...

P.S. все вышеописанное вы можете применить и к WP 2.5-2.6.3

Скачать «лайт» версии перевода ru_RU_lite.mo для различных версий вы можете по этим ссылкам

2.5.1 | 2.6.3 | 2.7

156 комментариев

Супер, супер.. ГИПЕР!

Недавно появился новый плагин для кэширования в WordPress. Когда я ставил недавно версию 1.0, то она была откровенно глючная и работало все только еще медленнее, но проблема похоже исправлена. Новая версия 2.0.1 радует!

Что делает и как работает? Да примерно точно также как и знаменитый wp-supercache, за одним исключением двух вещей:

1 позволяет ПОЛНОЦЕННО кэшировать страницы даже если указан шаблон ссылок стандартный в виде «вопросиков и параметров», т.к. не создает структуру на диске в виде папок, а просто складывает файлы .dat в свою папку с кэшем

2 кэширует даже ошибки 404, которые не кэширует вообще плагин wp-supercache

3 позволяет задавать время жизни кэша и через сколько времени очищать его, а также позволяет задавать настройку обновления кэшированной страницы только при изменении ее

4 в отличии от плагина wp-supercache тут для зарегистрированного и обычного посетителя выдается однотипный кэш

по скорости работы сайтов не уступает wp-supercache, а если учесть что только у этого плагина есть то что описано в пункте 1, то для некоторых он является единственным подходящим решением

Более подробно про плагин написано у автора

Устанавливается плагин просто

1 Скачайте плагин здесь и распакуйте папку из архива в wp-content/plugins. Если нужно скачайте мой русификатор и распакуйте файл из него в папку плагина wp-content/plugins/hyper-cache

2 Если вы ранее пользовались плагином wp-supercache, то деактивируйте его и удалите файл (символьную ссылку) advanced-cache.php

3 Установите права 777 на папку wp-content

4 Активируйте плагин и перейдите в настройки. Если сверху вы не увидите предупреждений на розовом фоне, то все нормально, если увидите — см пункт 2 и 3

5 в wp-config.php добавьте если еще нет

define( 'WP_CACHE', true );

6 Установите настройки (там все понятно даже для новичков)

7 Откройте любую страницу в браузере и посмотрите есть ли в конце исходника страницы строка типа <!— hyper cache: f94ca670035c4975bab89a1b20c31efb —> и проверьте создаются ли файлы в wp-content/hyper-cache

У себя поставил на своем блоге и на тестовом сайте. Работает пока отлично и на 2.6.3 и на 2.7бета. Скорость радует, глюков не заметил. А вообще автор пишет что работает плагин на всех версиях начиная с 2.1

64 комментария

Parasite Eliminator

Как заявляет автор плагина: «Достанет спамерские комментарии даже под ободком унитаза™»

Спамеры, сдохните

Спамеры, сдохните

10 ноября 2008 года — черный день российских блогоспамеров. Ожидаемый многими блоггерами плагин и сервис Parasite Eliminator выходит в открытое тестирование и доступен всем желающим.

присоединяйтесь!

также есть информация и обсуждение на Хабре

50 комментариев

Для любителей «минимализма» в новом дизайне админки (для WP2.7)

Новая админка содержит иконки в меню, и если вы их не любите, то можете избавиться от них с помощью вот этого плагина (иконки убираются только если «раскрыть меню». В «сложенном виде» иконки будут отображаться. В оригинальном плагине на данный момент есть баг — там папка обозвана hide-admin-icons, а должна называться mp-hide-admin-icons (что явно прописано в плагине). Напишу ка автору, пусть исправит…

2 комментария

Еще один «баг системы комментариев WP2.7»

есть у меня запись где я написал примерно 10комментов с включенными «древовидными». Затем я их отключил и когда добавляю коменты новые к записи, то они добавляется как положено последними в списке, но после отправки в браузере перескакивает на страницу-две назад (например на /comment-page-3/#comments), т.е. свои коменты ты не видишь пока не пролистаешь снова на последнюю страницу. сначала думал что баг в моем «модифицированном» comment-template но и в в чистой базе без «хакнутого» движка было тоже самое.

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

Один комментарий

Борьба с системой комментариев WP2.7 часть2

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

Копался часа три на тестовом блоге…

В итоге постраничная разбивка работает, номера страничек показываются (хотя все равно это не то что было с ранее названным плагином), древовидные комментарии также работают (но я их отрубил, т.к. понятие «работают» растяжимое). Когда недели две назад тестировал на теме Vertigio кажется то там форма коментов у меня «запрыгала» нормально (как в дефолтной теме) при ответе на какой либо комент. В моей же упорно не хочет. Перепробовал даже такой изврат как взять файлы comments.php и style.css из стандартной темы — также не работает! что то мешает и при ответе на коммент в дереве перезагружается вся страница вместо того чтобы просто переместить форму комента в нужное место. Буду разбираться дальше.

Не понравилось другое… Если вызываешь форму коммента «в дереве» и не нажмешь потом «отправить коммент» или «отменить коммент» то перестает листать по страницам пока не выполнишь одно из этих действий. точнее ВП делает вид что листает, но если посмотреть на ссылки которые получаются при этом то они ведут вникуда.

Ладно, фиг с ними древовидными. Отложил на завтра. Решил настроить вывод комментов «как было в вп 2.6.3». Для этого как я и писал вчера я открыл файл comment-template.php из wp-includes и «хирургическим вмешательством в движке» переделал все на свой вкус. Слава богу тут проблем не возникло. Теперь все выглядит практически 1в1 как на 2.6.3 (только стили местами нужно подправить) и не нашел нужного кода для раскраски коментов автора (точнее догадки есть уже где копать)

В общем лично я считаю что выносить большую часть кода из comments.php в сам движок это огромная ошибка и если не будет нормального «хака» для изменения всего что я делал сегодня через более простые способы то нафига оно вообще сдалось? То что предлагается менять через параметры вызова — лишь малая часть

walker — древовидность
max_depth — глубина древовидности
style — стиль ‘ol’ либо ‘ul’
callback — так и не понял что это
end-callback — аналогично пункту выше
type — все, комменты, трекбеки (такое было раньше тоже)
page — разбивать по страницам
per_page — сколько на страницу
avatar_size — размер аватара
reverse_top_level — обратный порядок верхнего уровня
reverse_children — обратный порядок дочерних коментов

2 комментария

Совместимость плагинов и «тем» с WP2.7

Продолжаю тестировать…

Только проверил что не работает, а Lester Chan уже сообщает как сделать пару его плагинов WP-Email и WP-Print совместимыми с WP2.7:
либо править код, либо скачать пофиксенные файлики.

На текущий момент все еще несовместим плагин Simple Tags — не работает вообще.

Решение найдено методом тыка:

открываем файл simple-tags.php  и там строку

if ( strpos($wp_version, '2.5') !== false || strpos($wp_version, '2.6') !== false  ) {

дополняем ее чтобы получилось

if ( strpos($wp_version, '2.5') !== false || strpos($wp_version, '2.6') !== false || strpos($wp_version, '2.7') !== false ) {

шпаргалку пишу больше для себя. будет дополняться по мере нахождения багов

Один комментарий