Первое включение Блога на хосте.

Сразу после загрузки скрипта на сервер, либо апгрейда, в соответствии с предшествующими документами, обращение браузером к морде блога должно нарисовать её безо всяких варнингов и эрроров.

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

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

    Возможно, что никаких эрроров и варнингов не будет, но блог на понятном русском языке укажет на ряд неправильно проставленных значений, что произошло исключительно по невнимательности. Ибо про каждую настройку предыдущие документы раздела "Установка Lasto Blog" самым подробным образом рассказывали, и внимание на ней акцентировали.

Если никаких протестов Блога о неверных настройках не появилось, то Вы молодец.
Правда, не исключены две засады, возникшие не по Вашей вине:

1. Неправильная локаль.

Если Ласто Блог вдруг скажет на экран, что "В файле настроек ./data/settings.php указана нерабочая локаль", и отошлёт ссылкой за разъяснениями к данному документу, то вот эти разъяснения:

    Многие строковые функции PHP, а также регулярные выражения, не станут работать корректно, если не сообщить интерпретатору PHP всю правду о кодовой странице тех данных, с которыми этим строковым функциям и регуляркам придётся иметь дело.

    Как Вы догадываетесь, данный скрипт чуть сложнее тулзы для вывода на экран ритуального "Hello world", а потому регекспа и строковых функций в нём запредельно много. Соответственно, дабы всё работало правильно, простановка верной кодовой страницы жизненно необходима.

В файле ./data/settings.php Вы могли видеть подобную запись постулирования нужной локали:

# Установка дефолтовой кодировки:

   setlocale(LC_ALL,'ru_RU.CP1251');

Не факт, что такая локаль действительно установлена на Вашем сервере, о чём скрипт, собственно, и ругается.
Стало быть, тут необходимо написать что-то иное, и весь вопрос в том, что же именно.

Узнайте это.
Cделайте тестовый файлик test.php и запустите его на своём сервере:

<?php 
   echo setlocale(LC_ALL,'ru_RU.CP1251','rus_RUS.CP1251','Russian_Russia.1251','russian');
?>

Этот скрипт напишет на экран имя той локали, которая сервером точно поддерживается.
Для юниксообразных операционок наиболее вероятны ru_RU.CP1251 или rus_RUS.CP1251
Для виндовых - Russian_Russia.1251 (под Денвером, например).
Для экзотических забугорных серверов - russian

Поэтому в файл настроек ./data/settings.php на сервере Вам необходимо внести в соответствующую запись именно тот локалс, про который сознается данный тестовый скрипт. Как только Вы это сделаете, Ласто Блог тем и удовлетворится, и больше по этому поводу претензий предъявлять не станет.

Дискламбер:

  1. При отсутствии поддержки какой-либо локали вообще, следует беспокоить этим фактом саппорт хоста.

    Вы должны понимать, что автор скрипта не намерен ломать голову над странными глюками, порождёнными незнанием PHP Вашего сервера русских буковок. Обучайте интерпретатор PHP великому и могучему, чтоб никаких глюков не было в принципе.

  2. При локали, детектированной проверочным скриптом как russian, не стоит обольщаться.

    Согласно спецификации, имя локали должно содержать локализацию и кодировку, разделённые точкой.
    Локаль вида "russian" говорит про знание ею русских буковок, но не более того.
    Кодовая страница никак не указана.

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

    Рекомендации те же - попросить хостера поставить стандартную локаль ru_RU.CP1251 или rus_RUS.CP1251

  3. Сама процедура установки нужной локали на сервере отнюдь не трудоёмка.
    Админу всего-то нужно набрать в консоли команду наподобие

    localedef -cv -i ru_RU -f CP1251 /usr/lib/locale/ru_RU.cp1251

    (возможны вариации в зависимости от состава серверного ПО), и это всё.
    Так что смело напрягайте саппорт хоста.

2. Непобедимый UTF.

Несмотря на то, что скрипт Ласто Блога чётко и конкретно оговаривает кодировку с помощью PHP хедера, отсылаемого в поток вывода строго по уставу, как это предписано всеми спецификациями, Верховный Админ Вашего хостера может принудительно распространить на весь сервер настройки для хомячков, которые ничегошеньки не понимают в web-технологиях, и пользуют исключительно бесплатные движки со строго УТФ-ной кодировкой.

Если Вы попадёте под такие "настройки для хомячков", то обнаружите, что Ваш сайт выводится в неправильной кодировке несмотря ни на что. Даже если Вы воткнёте в шаблон дизайна метатег с указанием нужной кодировки в явном виде, это Вам ничем не поможет.

Правильно установленная локаль (в которой ни слова про UTF) тоже может не спасти от напасти.

Тогда попытайтесь в .htaccess Блога самой первой строкой указать на нужную Вам кодировку:

AddDefaultCharset windows-1251

Обычно этого достаточно. Но если Верховный Админ Хостера считает своих пользователей Фатальными Хомячками, которым запрещено пользоваться даже благами хтакцесса, то пишите ему письмо с рассказом про то, что Вы о нём думаете. Обычно непобедимый UTF после этого ретируется.

Получение лицензии на работу в домене.

Если Вы размещаете Блог не в тестовых доменах test.ru или test1.ru, то первый же запуск инициирует обращение к сайту автора скрипта для проверки, приобреталась ли для данного домена лицензия. Что должно проистекать в фоновом режиме, практически незаметно, и в дальнейшем никогда больше повторяться не будет.

    Однако, если на сайте нет исходящих соединений или коннекта до сервера выдачи лицензий, и обращение за разрешением на работу выполниться физически не может, блог нарисует соответствующие эрроры, а также ссылку для ручного прокликивания. Которая при клике в себя предъявит на экран набор из 32 символов. Этот хэш из 32 знаков требуется поместить текстовым редактором типа "блокнота" Винды в ASCII коде в файл с именем blog_license.db - файл надо сделать, и разместить его на сервере в папочке ./data/settings/ с дефолтовыми правами доступа 666

Если Вы пытаетесь заселить Блог в непролицензированный ранее домен, об этом так и будет сказано на экран.

При работе Блога в доменах test.ru или test1.ru под локальным сервером никаких лицензий не нужно.
Ибо на то они и тестовые домены.

Далее, когда всё это проделано автоматически либо руками, переходите к окончательным настройкам.


Примечание раз:

    Не даётся никаких гарантий, что скрипт на реальном домене, но в Денвере, правильно сгенерирует файл ./data/settings/blog_license.db

    На реальном хосте с этим никаких проблем не возникает, так как хостер строго следит за правильной работой всех необходимых расширений РНР.

    Если Вы чувствуете, что Ваш локальный сервер не способен полноценно эмулировать реальный сервер хостера, создайте на своём сайте на хосте какую-нибудь временную папку, и заведите голый дистрибутив в ней. Родившийся файл ./data/settings/blog_license.db далее можете стянуть с хоста, и использовать на локальном сервере.


Примечание два:

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

    Вам специально выделяется два тестовых домена test.ru и test1.ru работающих без лицензии под каким угодно локальным сервером- практикуйтесь на них.