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

Судя по всему, сайты на основе Pligg стали довольно популярны в интернете. На эту мысль меня натолкнула гора спама, обрушившаяся недавно на мой проект под управлением этой CMS. Не иначе, спамеры наконец написали роботов, которые могут "читать" стандартную защиту от автоматических регистраций Pligg и благополучно заполнять ни в чем не повинные сайты своими грязными предложениями.

Скажу, это было немудрено - встроенный в Pligg графический тест на "разумность" (он же "капча") довольно прост, ибо не использует различных ухищрений вроде warp'инга текста и сложного "замусоривания" изображения. Такие капчи долго не живут - по крайней мере, на популярных системах.

Я решил проблему довольно просто: использовал систему reCaptcha, которая может легко быть активирована на на любом современном сайте под управлением Pligg. Просто зайдите в Панель управления->Защита от автоматических регистраций и выберите reCaptcha. Чтобы использовать ее, вам потребуется зарегистрировать свой сайт в системе reCaptcha, после чего останется ввести в настройки антиспам-защиты выданные вам публичный и приватный ключи, а затем, собственно, активировать эту защиту.

Результат вас приятно порадует - за прошедший месяц у меня зарегистрировался только один спамер, да и тот наверняка делал это вручную.

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

Замените файл /modules/captcha/captchas/reCaptcha/libs/recaptchalib.php файлом из этого архива (4.15 Kb) - и у вас будет лаконично выглядящая и русскоязычная (кроме аудиотестов, естественно - но тут я поделать ничего не могу) капча, через которую злобные спамботы не пройдут. Или пройдут, но не так просто, как было до этого.

Удачи вам в борьбе со спамом!

Сегодня помогал одному хорошему человеку с установкой Pligg на одном из популярных хостингов, а именно - на Majordomo. Обнаружил, что на виртуальном хостинге по умолчанию стоит кодировка win-1251, но директива AddDefaultCharset UTF-8 в .htaccess, которая всегда помогала мне в таких случаях, на этом хостинге не работает.

Зато там прокатывает такая конструкция:

CharsetSourceEnc UTF-8
CharsetDefault UTF-8

Если вы используете Majordomo, рекомендую сразу прописывать эти две строки в .htaccess еще до инсталляции на хостинге, чтобы не читать "кракозябры".

Многие разработчики сайтов, которые имеют дело с отправкой писем в CodeIgniter через библиотеку Email, сталкиваются с проблемой корректного отображения имени отправителя и темы письма, написанных простым русским языком. Грубо говоря, прочитать их невозможно вовсе. А все из-за того, что стандартная CodeIgniter-библиотека Email вставляет кириллицу, которую вы ей подсовываете в $this->email->from() и $this->email->subject(), прямо в заголовки, что представляет собой грубое некомильфо. (оговорюсь, что речь идет о CodeIgniter версии 1.6.3 и ниже)

Чтобы избежать этого, требуется совсем немного - преобразовать критичные к кириллице параметры заголовков письма в специальную кодировку Base64.

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

А чтобы вам не пришлось делать то же самое, я решил ее выложить сюда: скачать библиотеку.

Установить ее проще простого: разархивируйте файл Email.php в каталог /system/application/libraries вашей установки Codeigniter

По умолчанию Codeigniter отправляет все письма в кодировке UTF-8 - при использовании ее проблем с кодированием заголовков не возникает. Если вы отправляете письма в CI с использованием других кодировок - потрудитесь инициализировать кодировку корректно, тогда проблем не будет и у вас. Данная библиотека берет название кодировки прямо из настроек либы. Как установить нужную кодировку - курите хелп для CI, там процесс достаточно подробно описан.

P.S. Кроме исправления проблем с русскими символами, я немного подшаманил вид заголовков писем, отправляемых через эту библиотеку, которые в отдельных ситуациях выглядят некрасиво:

• Если не указано имя получателя ответов в $this->email->reply_to('address@example.com'), то стандартная библиотека подставляет адрес вместо имени, что приводит к некрасивому виду заголовка Reply-To: "address@example.com" <address@example.com>. В Gmail эта гадость будет видна в подробных сведениях сообщения. Я решил, что лучше будет, если в таком случае этот заголовок будет отсылаться в простом формате "Reply-To: <address@example.com>". Однако если вы захотите использовать не только адрес, но имя получателя ответов, оно также будет перекодировано в Base64.
• Если $this->email->reply_to в явном виде не вызвана, то и отдельный заголовок для адреса ответа по умолчанию отсылаться не будет. Это сделано из-за того, что в сообщениях, рассылемых почтовыми роботами и не требующих ответа, наличие этого заголовка в некоторых почтовых сервисах (в частности, в Gmail) приводит к появлению надписи "Ответить", что может сбивать с толку пользователей. Да, я знаю, что таких "сбиваемых" пользователей не много, но с точки зрения юзабилити эту штуку полезно отключить. Если вы хотите, чтобы адрес ответа все-таки указывался по умолчанию на адрес отправителя (хотя большинство почтовых клиентов это автоматически подразумевают в ситуации, если заголовка Reply-To нет), то расскомментируйте код в самом начале функции send().

Буду рад любым замечаниям по работе библиотеки.

ВНИМАНИЕ: Вышел следующий перевод следующей версии Pligg! Версию 9.9.5 более не рекомендуется использовать. Обновление доступно в новой версии.

С некоторой задержкой относительно выхода оригинальной версии Pligg 9.9.5, я представляю вашему вниманию локализацию новой версии этой системы на русский язык. Следуя традиции, я перевел весь интерфейс, административную панель, инсталлятор, а также привел шаблон yget и базу данных в вид, пригодный для корректного хранения и отображения русских названий материалов и рубрик.

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

В процессе перевода были произведены некоторые усовершенствования относительно оригинальной версии. В частности, проведена переверстка шаблона yget с целью большей совместимости со старыми версиями Internet Explorer. Устранены ошибки в интерпретации "осликом" Javascript-кода на странице новых событий. К сожалению, не все шероховатости удалось устранить за тот короткий срок, который я смог уделить локализации новой версии Pligg, однако с уверенностью могу сказать, что новая русская версия получилась в большей степени кроссбраузерной, чем англоязычный оригинал. Надеюсь, сделанное уменьшит степень беспокойства посетителей ваших сайтов, использующих IE 6 и ниже.

В новой версии я задействовал возможность апгрейда базы данных с русской версии Pligg 9.90. Апгрейд с англоязычной версии, к сожалению, не предусмотрен.
Были также учтены просьбы пользователей, пожелавших использовать русский Pligg с украинским языком. Pligg 9.95 RUS поддерживает транслитерацию адресов с украинскими символами ї, і и є.

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

Проведение апгрейда вашей системы Pligg 9.90 RUS:

• Сделайте резервную копию сайта, включая базу данных.
• Перезапишите файлы новой версии 9.9.5 RUS поверх старых файлов.
• Зайдите по адресу %PLIGG_ROOT%/install/upgrade.php и нажмите кнопку обновления БД.
• После апгрейда обязательно удалите каталог install (система сама об этом вас не попросит).
• Если вы пользовались модулем RSS Importer, то после апгрейда обнаружите его неустановленным. Это сделано из-за того, что структура БД изменена и старая установка может работать некорректно. Необходимо проинсталлировать этот модуль заново.
• С целью повышения безопасности в Pligg 9.95 удален редактор шаблонов. При обновлении с версии 9.90 рекомендуется удалить файлы этого редактора:
  
  admin_editor.php
  и templates/yget/admin_templates/editor_center.tpl
• Если вы пользовались встроенным редактором шалона, то у вас наверняка стоят права 0777 на все файлы шаблонов. Следует установить права файлам шаблонов на 0644, а всем подкаталогам - 0750. Это повысит безопасность системы.

В новой версии существует возможность задавать META-информацию для каждой из рубрик по отдельности. Для этого зайдите в управление рубриками и нажмите на ссылку "рубрика" рядом с названием нужной рубрики. Появятся поля для введения META-description и META-keywords. Метаданные, введенные в файл templates/meta.tpl, останутся - они будут отображаться после META-данных рубрики. Помните о том, что все редактирования файлов Pligg с добавлением русских символов следует производить в режиме UTF-8 без BOM.

В новой версии произведена замена подчеркиваний в URL на дефисы. О причинах этого можно прочитать здесь:
http://www.mattcutts.com/blog/dashes-vs-underscores/

В связи с известными проблемами шаблона yget, предлагаю всем поучаствовать в конкурсе на лучший шаблон, который достоин для распространения с русской версией Pligg. Хотелось бы избежать трудностей с апгрейдами хотя бы в этом - мне катастрофически не хватает времени довести до ума код во многом нелогичного кода шаблона yget. Если у вас есть подходящий шаблон, предлагайте его на форуме. Победивший шаблон будет включен в дистрибутив, а тот, кто его предложит, получит право на размещение ссылки на свой сайт непосредственно в шаблоне и на моем сайте. Требования к шаблонам - отвечать духу Web 2.0, быть лаконичным, позволять в полной мере реализовывать весь функционал Pligg. Надеюсь, общими усилиями получится избавить Pligg от проблем с кроссбраузерностью, валидацией и пр.

Ссылка для скачивания Pligg 9.95 russian

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

P.S. После установки новой версии вы обнаружите два фрейма внизу главной страницы панели администрирования. В одном из них вы увидите ссылки на последние новости руcской версии Pligg, которые берутся прямо с этого сайта. Так что поглядывайте туда иногда на предмет всяких разных полезных вещей ;)

С каждой новой версией браузера от 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 и остальных браузерах - и смело выкладываем код на сайт.