(Не)идеальный интернет

С каждой новой версией браузера от Microsoft мир веб-разработчиков напрягается - чего они там еще нового придумали? Пользователи-новаторы радостно перескакивают на новые версии, пользователи-консерваторы довольствуются тем, что есть. Статистика используемых браузеров начинает колебаться, а за кулисами происходит настоящая борьба за приличный вид страниц. Потому что каждый новый Internet Explorer показывает один и тот же код страницы по разному, и не всегда так, чтобы можно было закрывать на это глаза.

В браузерах, живущих "по понятиям" - то есть поддерживающих стандарты наиболее полным образом, "проблема обновления" практически отсутствует - их механизм отрисовки страницы изначально максимально соответствует стандартам и новая версия предлагает в первую очередь новые удобства пользования браузером, а не нововведения в плане отображения страницы. Так происходит с Mozilla Firefox, с Opera и многими другими браузерами. Страница, сверстанная по стандартам, отображается в них коректно. Отрадно, что недавно появившийся Google Chrome продолжает эту традицию и головных болей верстальщикам почти не добавил.

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

Одним из таких хаков является условное включение в страницу HTML-кода, действующего только для IE старых версий - 6й и ниже:

<!--[if lte IE 6]>
            <link rel="stylesheet" type="text/css" href="/css/ie6.css" media="screen" />
            .....

<![endif]-->

Это замечательное решение, которое используется массой людей, в том числе и мной. Однако существует ситуация, в которой оно не срабатывает:

Если у вас, как и у многих добропорядочных верстальщиков, на рабочем компьютере основной версией IE, которая установлена в системе, является Internet Explorer 7, и для полного счастья установлен набор старых версий IE под названием Multiple IEs, то при попытке посмотреть страницу через IE 6 из этого набора описанный выше хак не сработает. Из-за того, что в проверке условия будет фигурировать основная (системная) версия Internet Explorer, то есть "семерка", а не та, которая указывается в User-Agent. Чтобы обойти это ограничение, в процессе отладки кода страницы для IE 6 и меньше придется ставить в код такое условие:

<!--[if lte IE 7]>

При этом необходимо помнить о том, что такую страницу не следует смотреть в IE 7 из-за того, что код будет срабатывать и для него

После того, как код будет отлажен, возвращаем в условие шестерку, удостоверяемся в корректном отображении в IE 7 и остальных браузерах - и смело выкладываем код на сайт.

С некоторых пор я использую в своих разработках очень хороший и функциональный WYSIWYG-редактор Spaw. Он требует минимум времени на настройку, но при этом поволяет множество замечательных функций. Пожалуй, самая ценная из которых - это возможность быстрой закачки изображений (и любых других файлов) на сайт для последующей вставки в редактируемый текст. И что особенно приятно, этот редактор прекрасно русифицирован.

Однако есть небольшой подводный камень, на который обязательно найдет коса разработчиков, которые используют этот редактор для русскоязычных сайтов, да еще и с кодировкой UTF-8. Конечно, кодировка прекрасно выставляется в настройках Spaw, и проблем с отображением, редактированием русских символов нет. Однако при закачке файла, названного русскими символами, Spaw проверяет лишь его расширение на соответствие разрешенным типам файлов, но само имя файла так и остается состоящим из русских символов. И очень вероятно, что нормально его скачать потом не удастся, хотя добавить в текст - пожалуйста.

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

открываем файл spaw/plugins/spawfm/class/spawfm.class.php

и добавляем в класс SpawFm следующую функцию:

function transliterateFilename($input, $mode=1)
{
$trans=array(
   ' ' => '_',
   'А' => 'A', 
   'Б' => 'B',
   'В' => 'V',
   'Г' => 'G',
   'Д' => 'D',
   'Е' => 'E',
   'Ё' => 'YO',
   'Ж' => 'ZH',
   'З' => 'Z',
   'И' => 'I',
   'Й' => 'J',
   'К' => 'K',
   'Л' => 'L',
   'М' => 'M',
   'Н' => 'N',
   'О' => 'O',
   'П' => 'P',
   'Р' => 'R',
   'С' => 'S',
   'Т' => 'T',
   'У' => 'U',
   'Ф' => 'F',
   'Х' => 'H',
   'Ц' => 'TS',
   'Ч' => 'CH',
   'Ш' => 'SH',
   'Щ' => 'SCH',
   'Ъ' => '',
   'Ы' => 'Y',
   'Ь' => '',
   'Э' => 'E',
   'Ю' => 'YU',
   'Я' => 'YA',
   'а' => 'a',
   'б' => 'b',
   'в' => 'v',
   'г' => 'g',
   'д' => 'd',
   'е' => 'e',
   'ё' => 'yo',
   'ж' => 'zh',
   'з' => 'z',
   'и' => 'i',
   'й' => 'j',
   'к' => 'k',
   'л' => 'l',
   'м' => 'm',
   'н' => 'n',
   'о' => 'o',
   'п' => 'p',
   'р' => 'r',
   'с' => 's',
   'т' => 't',
   'у' => 'u',
   'ф' => 'f',
   'х' => 'h',
   'ц' => 'ts',
   'ч' => 'ch',
   'ш' => 'sh',
   'щ' => 'sch',
   'ъ' => '',
   'ы' => 'y',
   'ь' => '',
   'э' => 'e',
   'ю' => 'yu',
   'я' => 'ya',
   '№' => 'No.',
   //ukranian symbols added
   'Ї' => 'I',
   'І' => 'I',
   'Є' => 'E',
   'ї' => 'i',
   'і' => 'i',
   'є' => 'e',
   );
$input=strtr($input, $trans);
if($mode==1) //lowercase mode
{
   return utf8_strtolower($input, 'utf-8');
}
return $input;
}
   

после чего находим строку

$uplfile_name = $uplfile['name'];
   

и заменяем ее на эти строки

$uplfile_name = $this->transliterateFilename($uplfile['name'],0);
$transliterated_name = $uplfile_name;
   

Нуль, передаваемый последним параметром, означает, что конверсия в нижний регистр не требуется. Если передать не ноль - имя файла будет преобразовано в нижний регистр. $translierated_name сохраняем для того, чтобы использовать для автоматического переименования файла, если такой файл уже существует на сервере.

Чтобы автопереименование использовало транслитерированный вариант, необходимо найти строку

$uplfile_name = ereg_replace('(.*)(\.[a-zA-Z]+)$', '\1_'.$i.'\2', $uplfile['name']);
   

и заменить ее на

$uplfile_name = ereg_replace('(.*)(\.[a-zA-Z]+)$', '\1_'.$i.'\2', $transliterated_name);
   

Естественно, в массив $trans можно передавать любые правила конверсии, которые вам будут угодны. Как нетрудно заметить в приведенном коде, лично я добавил, кроме транслитерации, перевод пробелов в символы подчеркивания, а также символы украинского алфавита, которых нет в русском. Так что украинские девелоперы также могут использовать этот код ;) 

Все управление транслитерацией ссылок находится в libs\utils.php. Кроме него, есть еще правила переадресации в .htaccess, но до него мы доберемся чуть позже.

За транслитерацию отвечают вызовы transliterate_for_urls() в функциях makeCategoryFriendly() и makeUrlFriendly() (транслитерация названий рубрик и заголовков соответственно)

Отключение транслитерации названий рубрик:

Закомментируйте следующую строку в функции makeCategoryFriendly():

$input=transliterate_for_urls($input,1);

Отключение транслитерации заголовков:

Закомментируйте следующую строку в функции makeUrlFriendly():

$output=transliterate_for_urls($output,0);

Прежде всего, настройка регистра при транслитерации: вторым параметром в функцию transliterate_for_urls() передается настройка регистра - если вы хотите, чтобы заголовки транслитерировались в нижнем регистре, точно так же, как для рубрик, то в функции makeUrlFriendly() нужно поменять второй параметр на 1. Ее вызов будет выглядеть так:

$output=transliterate_for_urls($output,1);

Естественно, если вы отключили транслитерацию, смена регистра не будет происходить. Но в этом случае вы можете просто добавить следующую строку после закомментированной строки вызова transliterate_for_urls():

$output = utf8_strtolower($output, 'utf-8');

и название рубрики или заголовок будут переводиться в нижний регистр. Если вы БОЛЬШОЙ оригинал, можете вместо utf8_strtolower() использовать utf8_strtoupper(), но я надеюсь, что вы до этого не дойдете :)

Если вы хотите, чтобы пробелы или любые другие символы заменялись на отличные от тех, что стоят по умолчанию, измените правила замены в соответствующих функциях (как вы уже поняли, задавать правила формирования адресов для названий рубрик и заголовков нужно отдельно - в функциях makeCategoryFriendly() и makeUrlFriendly() соответственно). Правила замены находятся в строках подобного вида:

$output = preg_replace("/\s/e" , "_" , $output); // это замена пробелов на подчеркивания
$output = str_replace("?", "", $output); //это удаление (замена на пустую строку) знаков вопроса

Как известно, при использовании "дружественных" URL при каждом добавлении новых рубрик в .htaccess необходимо изменять строки, находящиеся в самом конце секции перенаправления. Код для этих строк показывается в самом низу страницы управления рубриками. При использовании транслитерированных названий рубрик его можно смело брать и вставлять в свой .htaccess Если же вы пользуетесь нетраслитерированными названиями рубрик, то возможна ситуация, когда вы этот код вставили, а при переходе по URL-encoded адресу с русскими буквами вы получаете ошибку 404. Я решил эту проблему заменой URL-encoded представлений рубрик на обычный русскоязычный текст. То есть вместо строк вида

RewriteRule ^(all|%D0%98%D0%BD%D1%82.........)/([^/]+)/?$ story.php?title=$2 [L]

я использовал такие конструкции:

RewriteRule ^(all|Интернет|pligg|МояЧудеснаяРубрика)/([^/]+)/?$ story.php?title=$2 [L]

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

И напоследок - не забудьте проводить редактирование .htaccess в режиме UTF-8!

Надеюсь, эта статья поможет вам разобраться с ссылками в русском Pligg. Если остались еще какие-то вопросы - можете их задавать в комментариях.

Не так давно мне поступило несколько жалоб на то, что после установки моей сборки Pligg 9.90 появлялась ошибка при обращении к базе данных, характерной чертой которой был вывод строки "There is a problem with the categories table. Error CA:001".

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

Что я сделал, чтобы избавиться от нее?

Во первых, убедился, что в базе данных есть таблица pligg_categories и в ней есть корректные данные - присутствуют все рубрики (категории), включая категорию all.

Во вторых проверил настройки в файле settings.php, чтобы они соответствовали тому, что находится в БД:

$dblang = 'ru';

define('table_prefix', 'pligg_');

Данные оказались верны, но ошибка все равно наблюдалась. После этого осталось заключить, что причина кроется в кэшировании результатов запросов к БД.

После того, как я очистил кэш (у Pligg есть два кэша - один для БД, другой для отображаемых данных, они находятся в каталогах cache и teplates_c соответственно), все заработало нормально.

Однако, если вы очистите кэш и при этом у вас будут стоять неверные установки в settings.php, очистка кэша не даст результата. Поэтому обязательно проверьте эти установки.

Если вы вносите изменения в работу системы, не забывайте очищать кэш - это избавит вас от подобных проблем. Можно также отключить кэш на время подобных работ, изменив в options.php  строку

define('caching', 1);

на

define('caching', 0); 

Для апгрейда необходимы - установленная система Pligg 9.90 Beta английской версии (естественно!) и PHPMyAdmin, настроенный на работу с базой данных вашей системы Pligg. Через него мы будем осуществлять насилие над базой данных ;)

Первым делом сделайте резервную копию БД и файлов. Мало ли что, нужно иметь возможность для отката. Также может быть полезным записать на лист бумаги настройки системы, которые вы изменяли - в процессе русификации все настройки, кроме настроек сервера, будут сброшены на значения по умолчанию (это будут полностью рабочие значения, поэтому работа вашей системы не будет повреждена). В английской версии будет сложно переписать текстовые значения, например, в группе настроек рекомендаций (Recommend), так как они отображаются в админке в неверной кодировке. Но тут уж ничего не поделаешь, зато после установки русской версии вы сможете легко их задать заново, если значения по умолчанию вас чем-то не устроят)

Простота перехода зависит от того, в каком виде хранятся данные в вашей БД. Существует хак, позволяющий использовать русский язык в Pligg, известный еще со времен Pligg RSE и я надеюсь, что вы им воспользовались перед тем, как ваша система наполнялась данными. Я веду речь о хаке для установки кодировки UTF8 при общении системы с БД, заключающемся в добавлении в libs/db.php этих четырех строк:

mysql_query("SET NAMES utf8_general_ci");
mysql_query("SET CHARSET utf8");
mysql_query("SET CHARACTER SET utf8");
mysql_query("SET SESSION collation_connection = 'utf8_general_ci'");

в район 100й строки libs/db.php прямо перед строками

            return $return_val;
        }

        /**********************************************************************
        *  Try to select a mySQL database
        */

Если вы использовали этот хак с самого начала использования английской версии, то вы избежали массы проблем. Если не использовали - сливайте дамп к себе, перекодируйте данные в дампе в кодировку UTF8 и заливайте на место старых. После этого применяйте хак, указанный выше. Если хак работает и данные корректно отображаются на сайте (а заодно они корректно отображаются и в PHPMyAdmin), вы готовы для апгрейда . Если нет - значит, вы неправильно перекодировали данные. Перекодируйте данные правильно и залейте в БД.