Просмотр полной версии : Перенос сайта с Windows на Unix
Делал сайт на Денвере, всё работало. Скопировал всю структуру каталогов на сервер под Unix, закачал БД.
Теперь получаю сообщение 'No template found!'.
При чём если я чищу весь кэш, то при первом открытии страницы она загружается почти нормально, только часть HEADER не обрабатывается. При повторном обновлении страницы снова вываливается ошибка 'No template found!'.
Есть подозрение, что расширение Template Auto-parser неправильно работает, переустановка не помогла. Если я убираю обработку BODY, то HEADER обрабатывается нормально и ошибка не выводится, генерируется пустая страница.
Эпизодически такая ошибка вылетала под виндой, когда очищал кэш, повторная очистка решала проблему, здесь же такой номер не проходит.
Кто-нибудь встречался с подобным?
Ошибочка. Секция HEADER тоже не работает при повторном обновлении страницы. Т.е. это расширение совсем не работает. Код типа
page.10 = TEXT
page.10.value = asdfasfdasdf
нормально работает, ошибку не выдаёт
Помогла переустановка TYPO3
Попробовал выложить в инет сайт, опять таже ошибка.
Последовательность действий:
Закачиваю содержимое dummy-4.0.4
Закачиваю содержимое typo3_src-4.0.4
Устанавливаю TYPO3
Устанавливаю необходимые расширения
Закачиваю дополнительные папки и файлы, в частности шаблоны
Закачиваю файл localconf.php и редактирую его под настройки выкладываемого сайта
Экспортирую все таблицы БД кроме таблиц с префиксом cache_ из локального сайта (с командами удаления прежних таблиц)
Импортирую этот файл в БД сайта в инете
Результат: в BE всё отображается правильно.
В FE при первой загрузке страницы (например, после удаления всего кеша) страница отображается почти правильно, только стили из HEADER не вставляются. При последующих обновлениях этой страницы в браузере получаю ошибку "No template found!"
Что делать? Подскажите...
Выяснил, что, если установлен флаг magic_quotes_gpc, то может происходить такая ошибка.
Однако, после установки значения в Off ничего не изменилось.
Ошибка возникает в файле class.t3lib_tstemplate.php:
$this->setup = unserialize($setupData);
В строке $setupData много данных, но они не преобразуются в массив с помощью функции unserialize
Неужели только у меня одного такая ошибка возникает... уже не на первой операционной системе?
что значит не на первой?
локально: какие ОС, PHP, MySQL?
удаленно: какие OC, PHP, MySQL?
чем экспортируете базу?
что значит не на первой?
локально: какие ОС, PHP, MySQL?
удаленно: какие OC, PHP, MySQL?
чем экспортируете базу?
Локально: Денвер
Переносил на Linux 2.6.18-3-686 #1, PHP Version 5.2.0-8, MySQL 5.0.32. При простом копировании файлов и копировании БД, выходила такая ошибка, но через установку и копирование БД проблема решилась.
Теперь не могу перенести на Linux 2.6.18-NX.11-hydra #3, PHP Version 4.4.4 (на 5-й аналогично), MySQL 5.0.26. Установка+копирование БД с помощью phpMyAdmin не помогает.
Хотел было совсем кеш отключить... получилось только путём удаления таблиц cache_hash, cache_pages и cache_pagesection. Изуверство, конечно, но зато хоть работает.
тогда глупый вопрос - а просто через экспорт-импорт дерева не пробовали?
Настройки баз данных (кодировка, collation) - совпадают? (насколько я помню в денвере 4я ветка, так?)
Пробовал через импорт, но видимо слишком много данных (6Мб), всегда происходила ошибка времени ожидания. С phpMyAdmin таких проблем нет.
На Денвере PHP Version 5.0.4, MySQL 4.1.7
Везде стоит MySQL-кодировка: UTF-8 Unicode (utf8)
Сопоставление соединения с MySQL: utf8_general_ci
Встречался именно с такой ошибкой при переходе с php4 на php5.
Причина была в том, что в таблице cache_hash содержались обрезанные данные, которые потом не могли быть правильно десериализованы.
Проверьте collation, покажите свою [SYS][setDBinit].
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8'.chr(10).'SET CHARACTER SET utf8';
collation везде utf8_general_ci
Встречался именно с такой ошибкой при переходе с php4 на php5.
Причина была в том, что в таблице cache_hash содержались обрезанные данные, которые потом не могли быть правильно десериализованы.
Проверьте collation, покажите свою [SYS][setDBinit].
А причем тут переход с версии на версию? Я же кеш очищаю и он генерируется снова в новой версии... Пробовал запускать под PHP5 на том же сервере, та же ошибка.
Не знаю... вообще странная ошибка. Зависит от многих факторов, видимо. У меня прошла после удаления нескольких экстеншенов.
Нашёл ошибку!
В файле class.t3lib_page.php в функции storeHash вместо строки
$GLOBALS['TYPO3_DB']->exec_INSERTquery('cache_hash', $insertFields);
нужно написать
$GLOBALS['TYPO3_DB']->exec_INSERTquery('cache_hash', $insertFields, array('content'));
Вы уверены, что поле content не нужно обрабатывать через quoteArray?
Если это действительно баг, то ему место на bugs.typo3.org...
Похоже, что serialize уже заботится об этом. По крайней мере, у меня всё заработало и все страницы отображаются без ошибок. Так это наверное не ошибка TYPO3, а ошибка PHP, точнее функции mysql_real_escape_string().
Другое, более правильное, решение, наверное, было бы кодировать строку во что-нибудь, где нет кавычек и апострофов, например с помощью функций base64_encode/base64_decode:
Поменял строчки в class.t3lib_tstemplate.php:
$this->setup = base64_decode(unserialize($setupData)); // Artyom Lukanin added: base64_decode()
и
t3lib_pageSelect::storeHash($hash, base64_encode(serialize($this->setup)), 'TS TEMPLATE'); // Artyom Lukanin added: base64_encode()
Проверено, мин нет ;)
Вы уверены, что поле content не нужно обрабатывать через quoteArray?
Если это действительно баг, то ему место на bugs.typo3.org...
Добавил баг на этот сайт
Работает на vBulletin® версия 3.8.1. Copyright ©2000-2024, Jelsoft Enterprises Ltd. Перевод: zCarot