Показаны сообщения с ярлыком twiki. Показать все сообщения
Показаны сообщения с ярлыком twiki. Показать все сообщения

2008-02-08

Итак, что надо для того, чтобы на хостинге от Masterhost заработал TWiki?

1) Поправить TWiki.pm так, чтобы не генерировалось \n\n перед Content-Length
2) Не использовать для шифрования паролей crypt. Я выбрал md5.
3) Очень долго мучился с кодировками, помогло отрубание нафиг WSYWSIG плугина. Думаю, это никак с хостингом не связано.

2008-02-07

Многоязычность в TWiki

Я использую ForUserLanguagesPlugin, который позволяет на одной странице держать и оригинальный текст, и переводы. Именно из-за этого я его и взял на вооружение, на мой вкус одна страница удобнее 10-ти, когда вносишь изменения оригинал и перевод перед глазами одновременно. Да, еще не надо дублировать всякие элементы, если они перевода не требуют (например, фото какого-нибудь hardware-оборудования).

Плугин довольно примитивен, и там есть пара недочетов. Первый - не работает инсталляционный скрипт. С этим все просто - руками рассовываем файлы по каталогам, ставим пермишены. Вторая проблема посложнее: при выборе языка плугин опирается на переменную LANGUAGE, которая сохраняется в сессии. В отсутствие таковой будет установлен дефолтовый английский (lib/TWiki/Plugins/ForUserLanguagesPlugin.pm, sub initPlugin):

$ul = TWiki::Func::getSessionValue( 'LANGUAGE' ) || 'en';


Но ведь хочется-то, чтобы было сразу на том языке, который нам понятен! Представьте себе ситуацию: заходите вы на wiki, там все по-анлгицки. Но справа вверху язык уже выбран - русский! Для того, чтобы получить русский вывод от этого плагина, надо переключиться на любой другой язык и обратно. Толко тогда getSessionValue( 'LANGUAGE' ) вернет 'ru'.

И я задумался, как это сделать без промежуточной переадресации, поскольку что-то менять в TWiki-скриптах меня пугало. Я подумал, что логичнее всего прислушаться к браузеру (так делает и сам TWiki, когда выбирает язык интерфейса пользователя) и вот, что в итоге получилось:

my $lang_det = TWiki::Func::getSessionValue( 'LANGUAGE' );

unless ($lang_det) {
my $accept_language = $ENV{HTTP_ACCEPT_LANGUAGE};

if ( $accept_language =~ /^\w+$/ ) {
$lang_det = $accept_language;
}
if ( $accept_language =~ /^\*$/ ) {
$lang_det = 'en';
}
if ( $accept_language =~ /,/ ) {
($lang_det) = $accept_language =~ /^(\w+?)/;
}
unless ($lang_det) {
$lang_det = 'en';
}
}

$ul = $lang_det;


Конечно, это далеко от совершенства, но работает для MSIE7, Netscape Navigator 9, Firefox 2, Mozilla 1.7.x. Ну и если будете совершенствовать, загляните в RFC2616 :)

2008-02-01

Сутки пытался развернуть TWiki на мастерхосте, но так и не смог.

При обращении к bin/view/TWiki/WebHome сервер упорно выдает ошибку HTTP 502/ Bad Gateway. При этом заголовки выглядят очень забавно: если вывод успешен, я вижу:

HTTP/1.1 200 OK
Date: Thu, 31 Jan 2008 12:55:38 GMT
Content-Type: text/html; charset=ISO-8859-1
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=5
Server: Apache
Cache-Control: max-age=0
Expires: Thu, 31 Jan 2008 12:55:36 GMT

А в случае ошибки -

HTTP/1.1 502 Bad Gateway
Server: nginx/0.5.18
Date: Thu, 31 Jan 2008 12:54:32 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=5


Особенно интересна строка заголовка Server... Погуглив, нашел, что это мегасервер ngnix, и видимо через него балансируется нагрузка на виртуальный хостинг на машине (там FreeBSD 6).

Я повторил запрос уже с консоли хостинга (lynx - незаменимый текстовый браузер! памятка: не забыть поставить памятник разработчикам и пристрелить тех, кто утверждал, что текстовый браузер - это глупость), и снова полюбовался на 502/Bad Gateway.

Сослаться на собственную тупость не могу: развернуть TWiki на домашней машине под Debian 4.0 заняло ровно 7 минут.

Написал в поддержку... Первым ответом у меня тактично поинтересовались, смотрел ли я error_log и где находится скрипт. Я пояснил, а дальше в ответ - тишина.

И только я собрался звонить и голосом озвучивать свою проблему (ибо прошло более 4 суток с момента моего второго письма), я, чтобы не выглядеть идиотом, решил на всякий случай проверить, существует ли глюк до сих пор. Оказалось - уже поправили! А на следующий день пришел ответ, такого содержания:

Приносим извинения за задержку с ответом.

Исправления должны быть таковы:
--- lib/TWiki.pm.orig Tue Feb 5 20:36:07 2008
+++ lib/TWiki.pm Tue Feb 5 20:49:33 2008
@@ -603,7 +603,7 @@
# - too 5.8 dependent
# my $len = do { use bytes; length( $text ); };
my $len = length($text);
- $hdr =~ s/\n$/Content-Length: $len\n\n/s if $len;
+ $hdr =~ s/^(.*?)$/Content-Length: $len\n$1/s if $len;
} else {
$hdr = '';
}


В принципе, круто. Дело в том, что я смотрел на \n\n перед строкой Content-Length, но... это работало под Debian и я подумал, что так и надо. А зря... \n\n отделяет заголовки от контента, и я это великолепно знал...

Короче, засчитываем 1 балл в пользу техподдержки Мастерхост.