Не далі, як сьогодні, мені треба було оновити форум типу SMF (Simple Machines Forum) з версії 1.0 до 2.0RC1. В принципі, сам по собі процес відновлення проходить без проблем. Однак є деякі моменти, на яких я б хотів зупинитися докладніше. Що посилювало ситуацію, так це кодування. Версія 1.0 крутилася на cp1251, але версію 2.0 я неодмінно хотів бачити на всюдисущої utf-8.
На цьому етапі у мене з'явилося попередження, що з мовними файлами якісь трабли. Щоб не спокушати долю і не потрапити в ситуацію, коли потрібні посилання будуть недоступні (а все через те, що не буде російського перекладу необхідних слів), я вибрав використання англійської мови і процес пішов, пішов і ... заглох. Була виявлена помилка бази даних такого змісту:
Для мене все закінчилося добре. По-перше, оновлення виробляв на локальному хості, і по-друге, форум стоїть на виділеному сервері, де у мене теж є можливість змінити конфігурацію в разі проблем.
Повернемося до помилки. Дана проблема характерна, коли відбувається переповнення стека. Як видно з лістингу, потрібно збільшити змінну thread_stack. Зробити це не вдасться інакше, як за допомогою редагування файлу конфігурації. Відкриваємо файл my.cnf і встановлюємо змінну наступним чином:
Швидше за все, цього не буде потрібно. І цей випадок актуальний саме для локального тестування. На комп'ютері у мене стоїть Денвер, тому дана проблема актуальна для тих, хто використовує даний дистрибутив.
Отже, змінюємо вказану змінну, перезапускаємо сервер і знову намагаємося виконати upgrade.php. На цей раз все проходить на ура!
Тепер, просимо браузер показати вихідний код сторінки. Нас цікавлять параметри тега meta:
Ось воно що! Замість очікуваного utf-8 маємо західноєвропейську. Йдемо в теми і дивимося вміст файлу index.russian-utf8.php. Бачимо такий рядок:
Виходить, проблема не в цьому.
Що ж, прийшов час звернутися до людей, які на SMF собаку з'їли (по крайней мере, повинні були). Іду на форум російського ком'юніті, simplemachines.ru. Як людина razoomний, юзаю пошук. Оп-па, сюрприз № 1. Виявляється, щоб мати можливість шукати, мені потрібно зареєструватися. Ну хлопці, ви б хоч капчу зробили, якщо надмірного навантаження на сервер боїтеся ...
Реєстрація - це не наші методи! Починаю перебір відповідних розділах. Шукаю повідомлення, в яких йдеться про проблеми з кодуванням. Як не дивно, відповіді зводилися до кількох однотипним пропозицій (не рахуючи пропозицій полагодити криві руки). Одна з пропозицій - установка параметра $ db_character_set в файлі Settings.php (свого часу, до речі, мені таким же способом довелося облазити вихідні, щоб знайти параметр, який відповідає за установку необхідної кодування при коннекте до БД). Природно, це не те, що мені було потрібно (тим більше, що цей параметр у мене встановлений). Ще радили перевести файли з русіфікаей в utf-8 (ну тут, по-перше, я вже качав русик для utf-8, і по-друге, я його перевіряв. А вже cp1251 від utf-8 відрізнити в стані). Загалом, теж не те.
Був ще один відповідь. Якийсь діяч, з відтінком глибоко поблажливості в словах, глаголив на рівні аксіоми, що потрібно дізнатися, в якому кодуванні працював старий форум, і для русифікації сказати відповідний дистрибутив перекладів: utf-8 або cp1251, причому, за його словами виходило, що це єдино можливий варіант. Мені це теж не підходило жодним чином.
Покопавшись ще трохи на форумі і не знайшовши нічого корисного, вирішив завчасно не засмучуватися, і не впадати у відчай. У мене залишався метод «грубої сили».
Грубу силу було вирішено застосувати з головного шаблону. Відкривши файл index.template.php. побачив буквально наступне:
''
Тепер залишилося пробігтися по коду і з'ясувати, де відбувається присвоювання кодування даного елементу масиву. Подальші розкопки привели до файлу Load.php і відповідного шматку коду:
INSERT INTO `settings`
SET `variable` = 'global_character_set',` value` = 'UTF-8';
Перезавантажуємо сторінку форуму і з задоволенням виявляємо, що все стало працювати правильно (чого я, власне, і домагався).