Archive for Май, 2010
Absolute links or Relative links, что выбрать
В восьмой части статьи Wordpress – атака клонов. я немного коснулся темы абсолютных (Absolute links) и относительных (Relative links) ссылок. Вообще понятие абсолютных и относительных ссылок касается не только интернета. Например в Microsoft Excel формулы, реализующие вычисления в таблицах, для адресации ячеек используют ссылки на ячейку, которые могут быть относительными или абсолютными.
Нас же эти ссылки интересуют применительно к работе с файлами на сайте.
Прописывая ссылки мы должны помнить, что везде есть т.н. корень, в нашем компьютере в файловой системе это корень файловой системы на диске а на сайте нет никакого диска это корень веб-сервера.
В Windows нет единого корня всей файловой системы, их столько, сколько разделов или отдельных жестких дисков столько и корней, т.е. все исчисления путей будут идти от каждого конкретного диска(C:\ D:\ E:\).
Мы уже поняли что там и там ссылки могут быть абсолютными и относительными. Везде как и в жизни надо плясать от “печки”, и у нас это пресловутый корень.
На сайте для скриптов, физически находящихся на диске и работающих с реальными файлами исчисление путей может быть примерно таким /godu/www/mysite, где “mysite” это корневая папка веб сервера.
То что касается сайтов как виртуальных субстанций у них и адреса виртуальные, при просмотре в браузере, который не находится непосредственно на сайте, нужно прописывать только абсолютные ссылки, которые и являются виртуальными адресами(URL).
К примеру корнем для браузера будет http://moisite.com/ являющийся виртуальным адресом. Почему при наборе этого адреса мы на странице видим реальный контент? А потому что в настройках сервера при наборе этого адреса подразумевается вызов реальной страницы index.php или index.html.
В данном случае нас этот вопрос интересует с практической точки зрения, как на сайте правильно прописать пути к файлам.
Когда веб мастер прописывает ссылки у себя на сайте у него два варианта:
1 Прописать перед папкой с нужным нам файлом(неважно это .php, .jpg и.т.д) полный путь включая http://, допустим вызываемый объект image.jpg находится в папке “images”, тогда путь примерно такой: http://moisite.com/images/image.jpg. Тут мы обозначили корень так же как его видит браузер, для которого это единственный вариант – абсолютный путь который прописан от корня сайта.
Если же этот абсолютный путь прописывается внутри структуры сайта, получается некая двусмысленность, мы задействуем протокол HTTP.
Соответственно исполняемому скрипту(программе то бишь) необходимо задействовать web-сервер для подгрузки, создается повышенная нагрузка на сервисы nginx и apache, которым требуется обработать запрос к картинке.
Мы то путь к этому рисунку прописали не для того чтобы серфер набрал адрес у себя в браузере и скачал себе на комп. Этот рисунок(файл) должен обработаться каким нибудь скриптом(например галереи) находящемся тут же на сайте и лечь в определенное место на странице ему прописанное, он может ресайзиться, меняться на другой и.пр.
По идее мы тут имеем локальный адрес и его можно прописать без указания протокола и домена, то есть можно подойти к этому файлу впрямую. .
2 Это как раз тот случай где на локальный адрес можно в начале пути корень не прописывать, тогда этот путь к файлу будет относительным, и он достраивается от текущего положения скриптом. Вид у ссылки в нашем примере /images/image.jpg, путь к корню /godu/www/mysite или http://moisite.com мы не прописываем.
Вот тут мы и подошли к тому, ради чего и написан этот пост.
Интуитивно я всегда склонялся к относительным ссылкам, как не крути а путь короче. Проявлялись правда иногда кое какие несоответствия в путях, иногда перед папкой или файлом надо было проставлять “/” иногда нет, это случай когда адрес внутри темы прописывался. Но я везде, например вставляя в пост миниатюру, которая ведет к большой картинке все таки прописывал относительные пути. Да и некоторые скрипты, где надо было много картинок вызывать, я применял на разных хостах и удобно было применять относительные ссылки, чтобы лишний раз их не переписывать шаблон.
Тут в форуме “WordPress – форум поддержки” на MyWordPress.ru тему прочитал, где хостер объясняет, что нормальным способом является тот, при котором картинка загружается напрямую, внутри сервера по относительной ссылке. Ну, думаю хорошо, прав я что относительным ссылкам верю. Правда авторитеты, например “Ю.Б” раскритиковали претензии хостера, но это вроде касалось чисто зависимости вида ссылок на нагрузку сервера.
И вдруг, в один прекрасный момент захожу я на на свой и, о ужас, ни одной картинки. Хорошо еще Altы прописывал, хоть что то видно, но в любом случае хороший “подарочек” для подписчиков – статьи без картинок. Смотрю а у меня ссылки вида hppp://bloginf.com/wp-content/uploads/image.jpg заменены на hppp://feeds.feedburner.com/wp-content/uploads/image.jpg. А ведь тот же “Ю.Б” предупреждал, цитирую: “Только имейте в виду, что браузер, если не указан полный URL, подставляет текущий протокол, текущий домен и, если нужно (для относительных url) текущий путь.”
Поменял в постах все ссылки на картинки на абсолютные. Проблема ушла, но так как любовь к относительным ссылкам осталась, решил я поставить плагин relative-links, который на лету меняет все ссылки с абсолютных на относительные, если они ведут по внутренним путям блога. Плагин v 1.1 в версии WordPress 2.8.4 работает, картинки на feeds.feedburner не исчезли, все вроде нормально.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama
Новости “Planeta WordPress”,убрать и забыть
Выбирая WordPress в качестве движка для блога мы как бы сразу соглашаемся на некоторые неудобства, связанные с его бесплатностью. Речь идет о огромном количестве рекламы в админке, когда я впервые увидел сколько “левого” кода прописано в базе данных свежеустановленного движка то был, мягко говоря, неприятно удивлен. Ну что ж делать, бесплатный сыр…. Далее, когда все чаще сталкиваешься с “тормозами” возникает и нарастает раздражение. Чаще правда мы сами виноваты, плагины ведь ставим без разбору, ленимся заглянуть лишний раз в базу данных, в исходный код страницы, посмотреть сколько мусора тот или иной плагин туда вносит. Поначалу мы соблюдаем порядочность, и упаси боже даже подумать о том, чтобы какую нибудь ссылку внешнюю на Вордпрессовский ресурс убрать(видели бы вы сколько их в базе данных). Потом бывшая советская ментальность побеждает и мы, забывая о ней(порядочности) начинаем потихонечку убирать то, что по нашему мнению нам мешает жить. А очень мешает обилие новостей “планеты WordPress”, различные ссылки, которые нам впихивают на странице админки называемой Dashboard. И что делать? Убирать. Как? Сейчас попробуем, только не бейте сильно, я успокаиваю себя тем, что чайник и после моей подсказки не разберется, а опытный все равно и без меня, если надо это сделает.
Первым делом убираем показ новостей с “планеты WordPress”. Вообще есть специальные плагины для этого, но при ближайшем рассмотрении они не оправдали надежд. В разных версиях WordPress, разные косяки.
Пойдем другим путем, для этого откроем файл index.php в каталоге wp-admin и начиная со строки 11 уберем скрипт вызова новостей:
jQuery(function($) {
var ajaxWidgets = {
dashboard_incoming_links: ‘incominglinks’,
dashboard_primary: ‘devnews’,
dashboard_secondary: ‘planetnews’,
dashboard_plugins: ‘plugins’
};
$.each( ajaxWidgets, function(i, a) {
var e = jQuery(’#’ + i + ‘ div.dashboard-widget-content’).not(’.dashboard-widget-control’).find(’.widget-loading’);
if ( e.size() ) { e.parent().load(’index-extra.php?jax=’ + a); }
} );
});
</script>
Напоминаю речь идет только о версии 2.5.1 WordPress.
На этом можно успокоиться, грех на душу взяли уже, но нет, чешется еще что нибудь испортить. В принципе, этого вроде достаточно так что дальнейшию кастрацию файла index.php можно не делать.
Начиная со строки 30 убрал:
<h2><?php _e(’Dashboard’); ?></h2>
<div id=”rightnow”>
<h3 class=”reallynow”>
<span><?php _e(’Right Now’); ?></span>
<?php if ( $can_edit_posts = current_user_can( ‘edit_posts’ ) ) : ?>
<a href=”post-new.php” class=”rbutton”><strong><?php _e(’Write a New Post’); ?></strong></a>
<?php endif; if ( $can_edit_pages = current_user_can( ‘edit_pages’ ) ) : ?>
<a href=”page-new.php” class=”rbutton”><?php _e(’Write a New Page’); ?></a>
<?php endif; ?>
<br class=”clear” />
</h3>
Со строки 38
$num_pages = wp_count_posts( ‘page’ );
$num_cats = wp_count_terms(’category’);
$num_tags = wp_count_terms(’post_tag’);
$post_type_texts = array();
Строка 72
Строка76
Строка77 убираем:
<?php
$ct = current_theme_info();
$sidebars_widgets = wp_get_sidebars_widgets();
$num_widgets = array_reduce( $sidebars_widgets, create_function( ‘$prev, $curr’, ‘return $prev+count($curr);’ ) );
$widgets_text = sprintf( __ngettext( ‘%d widget’, ‘%d widgets’, $num_widgets ), $num_widgets );
if ( $can_switch_themes = current_user_can( ’switch_themes’ ) )
$widgets_text = “<a href=’widgets.php’>$widgets_text</a>”;
?>
<p class=”youare”>
<?php printf( __( ‘You are using %1$s theme with %2$s.’ ), $ct->title, $widgets_text ); ?>
<?php if ( $can_switch_themes ) : ?>
<a href=”themes.php” class=”rbutton”><?php _e(’Change Theme’); ?></a>
<?php endif; ?>
<?php update_right_now_message(); ?>
</p>
Со строки 86:
<div id=”dashboard-widgets-wrap”>
<?php wp_dashboard(); ?>
</div><!– dashboard-widgets-wrap –>
В результате кастрации файла страница админки приобрела из такого:
вот такой вид:
Пугаться не надо, остальные страницы выглядят как обычно:
Можно скачать файлик index.php, но перед заменой в папке wp-admin сохраните оригинальный, если что не так вернете обратно.
Далее, надо бы почистить от уже существующего мусора и оптимизировать базу данных. Дело в том, что отдельные таблицы, созданные однажды активироваными плагинами при необходимости можно удалить ручками, для этого заходим в phpMyAdmin, отмечаем таблицы этих плагинов и в выпадающем окне жмем удалить. А вот мусор оставляемый ими в штатной таблице wp_options не так легко удалить, для этого нужен определенный опыт или плагин. Мы для чистки базы применим плагин CleanOptions, который освободит ее от неиспользуемых данных. В нашей версии WordPress 2.5.1 он чудненько работает.
Установка плагина стандартная, настроек нет, в созданной кнопке Manage/CleanOptions отражается количество найденных мусорных опций, далее будем их называть “осиротелые опции”. Вернее здесь отражено количество всех найденных опций в таблице wp_options, среди которых есть принадлежащие движку WordPress, часть принадлежит активированным плагинам, поэтому после всех чисток это число не будет равняться нулю. Про то, что надо сделать бекап базы данных перед работой с плагином надеюсь Вы знаете. Работу начинаем с вызова страницы плагина, для этого жмем Manage/CleanOptions, и получаем первое окошко:
Здесь информация автора, просьба поделиться деньгами и пр., нас интересует кнопка “Find Orphaned Options”, ставим один или два чека, жмем на нее(кнопку) и видим другое окно:
Здесь нам показывают найденные опции среди них не все “осиротелые”, поэтому внимательно изучите список, небольшого опыта вполне достаточно, чтобы понять какому плагину, например, принадлежит та или иная. Вот пример:
Вижу знакомое название плагина Pretty Link. Я даже подзабыл, что когда то ставил этот плагин, затем деактивировал, а хвосты оказывается остались. Вот prli_link под сомнением, жму ссылку после кнопки “Google it”, все ясно – тоже концы от этого плагина. После просмотра, отмечаем выбранные значения или если решили все удалить, находим кнопочку Wiew Selected Options Information, жмем ее:
Получаем длиннющюю страницу с найденным (по мнению плагина) мусором:
Если согласны все это удалить, в самом низу кнопка, которую жмем, перед этим ставим чек на Yes, кнопка называется Submit:
И в следующем окошке видны результаты:
Жмем CleanOptions вверху и видим что количество найденных опций изменилась:
Плагин не обязательно держать в активном состоянии, можно включать его периодически, или когда явно намусорили в базе установленными а затем деактивированными плагинами.
После чистки плагином можно сделать SQL запрос к базе данных в phpMyAdmin, для того чтобы проверить работу плагина.
Действительно кое что осталось:
Отмечаем и удаляем:
Далее оптимизируем базу данных, для этого заходим в PHPADMIN – Выполнить SQL-запрос(ы) к базе данных. В поле вводим запрос “OPTIMIZE TABLE wp_options” без кавычек.
Из 4.7мб получилось 3.7мб
Можно сделать по другому, в выпадающем окошке выбрать “оптимизировать таблицу” в результате:
Проверяем блог, все нормально функционирует.
Результат всех действий такой: было в базе данных 526500 знаков стало 130100.
Я думаю в плане уменьшения нагрузки для сплогов на базе WP 2.5.1 на грошовых, а тем паче на бесплатных хостингах польза будет большая. А вот если мы имеем крутой блог на хорошем хосте, свежую версию WP, админу удобно просматривать в “доске обьявлений” последние комментарии, он пользуется быстрой публикацией, может быть все это и не надо.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama
