Обновление сайта livestreet.ru на версию 0.4
5
Сегодня движок сайта livestreet.ru обновился до 0.4 версии.
Пока на новую версию переведен только основной функционал. Раздел «Модули» и WIKI появятся немного позже.
Версия 0.4 вступает в стадию активного тестирования! Все замечания и баги можно смело писать в комментарии. Еще раз, писать именно баги, а не пожелания к функционалу, для этого была отдельная тема.
Приступим? :)
Пока на новую версию переведен только основной функционал. Раздел «Модули» и WIKI появятся немного позже.
Версия 0.4 вступает в стадию активного тестирования! Все замечания и баги можно смело писать в комментарии. Еще раз, писать именно баги, а не пожелания к функционалу, для этого была отдельная тема.
Приступим? :)
- +23
- 30 января 2010, 20:38
- ort
Очень понравилась оптимизация движка.
Вчера без особых натяжек выдержал 4300 уникальных посетитель (8500 просмотров), все эти пользователи пришли начиная с 15 часов дня. Хостнг шаринг, тип кеширования — мемори.
Очень доволен.
Вчера без особых натяжек выдержал 4300 уникальных посетитель (8500 просмотров), все эти пользователи пришли начиная с 15 часов дня. Хостнг шаринг, тип кеширования — мемори.
Очень доволен.
Во вьюере в методе BuildHeadFiles() как добавлялся сначала append, а потом prepend, так и осталось:
И еще глюк: пути на мерженные и сжатые js- и css-файлы в заголовке указываются не вебовские, а локальные:
array_merge(
(array)$this->aJsInclude['append'],
(array)$aResult['js'],
(array)$this->aJsInclude['prepend']
)
И еще глюк: пути на мерженные и сжатые js- и css-файлы в заголовке указываются не вебовские, а локальные:
<script type='text/javascript' src='U:/home/local/.../a2f7503048ba03aca2a.js'></script>
По путям: нашел причину. В функции GetWebPath($sFile) местами надо поменять строки. Сейчас:
Надо:
$sFile=str_replace(DIRECTORY_SEPARATOR,'/',$sFile);
return str_replace(Config::Get('path.root.server'),Config::Get('path.root.web'),$sFile);Надо:
$sFile=str_replace(Config::Get('path.root.server'),Config::Get('path.root.web'),$sFile);
return str_replace(DIRECTORY_SEPARATOR,'/',$sFile);
Хочу сделать несколько сайтов на ls. Все подготовительные действия уже готовы, то есть структура сайта определена, дизайны нарисованы и сверстаны в html(еще не натянуты).
Но стоит несколько вопросов:
1)Делать на 0.3 версии или же лучше на 0.4? Я конечно склоняюсь к 0.4 но вот как долго ждать еще допилки модулей?
2)Трудно ли будет перехать в случае чего с 0.3 на 0.4?
3)Будут ли в дальнейшем версии LS не совместимы с верху в низ?
Но стоит несколько вопросов:
1)Делать на 0.3 версии или же лучше на 0.4? Я конечно склоняюсь к 0.4 но вот как долго ждать еще допилки модулей?
2)Трудно ли будет перехать в случае чего с 0.3 на 0.4?
3)Будут ли в дальнейшем версии LS не совместимы с верху в низ?
Вопрос не к месту, читайте для чего был создан топик:
Все замечания и баги можно смело писать в комментарии. Еще раз, писать именно баги
Можно ли сделать, чтобы аватары и фото юзеров хранились в БД (user_profile_avatar, user_profile_foto) в относительных адресах, а то при смене хоста они перестают отображатся.
Например, при тестировании на локале, прописались пути
И их уже не сменить просто.
Например, при тестировании на локале, прописались пути
http://localhost/*****/uploads/images/00/00/01/2010/02/03/avatar_100x100.jpgИ их уже не сменить просто.
В patch.sql есть строки
Соответственно классы $oBlog->getUserIsAdministrator() и $oBlog->getUserIsModerator()
ничего не выводят.
Теперь, чтобы определить принадлежность юзера к группе модераторов блога, надо делать следующие манипуляции, например в comment.tpl:
Или я не так понял?
ALTER TABLE `prefix_blog_user`
DROP `is_moderator`,
DROP `is_administrator`;Соответственно классы $oBlog->getUserIsAdministrator() и $oBlog->getUserIsModerator()
ничего не выводят.
Теперь, чтобы определить принадлежность юзера к группе модераторов блога, надо делать следующие манипуляции, например в comment.tpl:
{assign var="oBlog" value=$oTopic->getBlog()}
{assign var="oBlogUser" value=$oBlog->Blog_GetBlogUserByBlogIdAndUserId($oBlog->getId(),$oUser->getId())};
{if $oBlogUser->getIsModerator()}...код...{/if} Или я не так понял?
Соответственно классы $oBlog->getUserIsAdministrator() и $oBlog->getUserIsModerator()Вы делаете вывод о работе функций только по списку полей в базе данных? Посмотрите как модуль получает данные о блоге и что дальше с ними делает (функция GetBlogsAdditionalData).
ничего не выводят.
$oBlog->Blog_GetBlogUser.....Вот такое работать никогда не будет.
Оно действительно работает…
А так как поле в БД остутствует, то в файле Blog.entity.class функции
возвращают пустой результат, так как они берут данные (насколько я понимаю) из SQL запроса к таблице blog_user
А так как поле в БД остутствует, то в файле Blog.entity.class функции
public function getUserIsAdministrator() {
return $this->_aData['user_is_administrator'];
}
public function getUserIsModerator() {
return $this->_aData['user_is_moderator'];
}возвращают пустой результат, так как они берут данные (насколько я понимаю) из SQL запроса к таблице blog_user
Просто вопрос, как получить данные о принадлежности к модераторам блога comment.tpl?
не работает
{assign var="oBlog" value=$oTopic->getBlog()}
{$oBlog->getUserIsModerator()}не работает
Для использования {$oBlog->getUserIsModerator()} в комментариях, необходимо включить подгрузку данных о пользоветеле блога в Comment.class.php
$aTargets['topic']=$this->Topic_GetTopicsAdditionalData($aTargetId['topic'],array('blog'=>array('owner'=>array())));$aTargets['topic']=$this->Topic_GetTopicsAdditionalData($aTargetId['topic'],array('blog'=>array('owner'=>array(),'relation_user')));
Имеет ли смысл постить багрепорты при установке на денвер? Ревизия 774.
Переименовал
config.local.php.dist
config.stable.php.dist
Запустил инсталятор. Указал ему базу, юзера, всё как полагается. А после перехода на сайт мне вывалило ерроры, что нет такой базы 'social'. Естественно, нет. Я в инсталяторе совсем другую указывал.
Ладно, прописал в конфиге ручками.
Захожу на сайт и вижу, что он голый.
link rel='stylesheet' type='text/css' href='X:/home/site.com/www/templates/cache/new/66943096540d664f8afadd9da7e9b205.css'
Переименовал
config.local.php.dist
config.stable.php.dist
Запустил инсталятор. Указал ему базу, юзера, всё как полагается. А после перехода на сайт мне вывалило ерроры, что нет такой базы 'social'. Естественно, нет. Я в инсталяторе совсем другую указывал.
Ладно, прописал в конфиге ручками.
Захожу на сайт и вижу, что он голый.
link rel='stylesheet' type='text/css' href='X:/home/site.com/www/templates/cache/new/66943096540d664f8afadd9da7e9b205.css'
тоже самое наблюдаю… в 741й ревизии изменилась строка 44 файла config.php, автор ort
с
config['path']['root']['server'] = $_SERVER['DOCUMENT_ROOT'];
на
config['path']['root']['server'] = dirname(dirname(__FILE__));
и получается описанный эфект
если вернуть на место, то ссылка на css файл нормальная, а вот внутри него ссылки на графику такие же битые
с
config['path']['root']['server'] = $_SERVER['DOCUMENT_ROOT'];
на
config['path']['root']['server'] = dirname(dirname(__FILE__));
и получается описанный эфект
если вернуть на место, то ссылка на css файл нормальная, а вот внутри него ссылки на графику такие же битые
Иногда повторный старт сессии происходит и получаем:
Notice: A session had already been started...Надо либо проверять, запущена сессия уже или нет, либо хотя бы блокировать вывод Notice-сообщений при вызове session_start() (т.е. ставить @session_start())
Понял первопричину этой проблемы. И эта первопричина вызывает еще ряд проблем.
Сейчас при инициализации движка имеем:
Может, все же автоподгрузку модулей сделать ДО плагинов? Или это ломает какую-то вашу логику?
Сейчас при инициализации движка имеем:
$this->InitPlugins();
$this->InitHooks();
$this->LoadModules();
...
Может, все же автоподгрузку модулей сделать ДО плагинов? Или это ломает какую-то вашу логику?
Ревизия 776
Проверить легко: добавь в плагин профайлера в ф-цию Init() вызов $this->Message_AddNotice(...) — и проблема на лицо.
Да, при беглом взгляде я тоже вижу, что, вроде, должна быть проверка, загружен модуль или нет, но я вижу, что Message->Init() дважды выполняется.
Но мне кажется, что и по логике долно быть так: сначала грузится ядро с базовым набором модулей, потом плагины, потом инициализируются хуки, а потом уже — по мере надобности — другие модули. Ведь и плагины и хуки — они на ядро должны опираться. Или я чего-то упустил?
Проверить легко: добавь в плагин профайлера в ф-цию Init() вызов $this->Message_AddNotice(...) — и проблема на лицо.
Да, при беглом взгляде я тоже вижу, что, вроде, должна быть проверка, загружен модуль или нет, но я вижу, что Message->Init() дважды выполняется.
Но мне кажется, что и по логике долно быть так: сначала грузится ядро с базовым набором модулей, потом плагины, потом инициализируются хуки, а потом уже — по мере надобности — другие модули. Ведь и плагины и хуки — они на ядро должны опираться. Или я чего-то упустил?
Ага, щас гораздо лучше, спасибо.
Только еще одно предложение: сейчас идет подгрузка плагинов и одновременно их инициализация. Предлагаю разделить этот участок на два этапа (как у модулей): сначала подгрузка активных плагинов (и делегирование), а потом инициализация уже загруженных плагинов.
При таком подходе можно будет при инициализации одного плагина использовать модули, которые были переопределены в других плагинах.
Только еще одно предложение: сейчас идет подгрузка плагинов и одновременно их инициализация. Предлагаю разделить этот участок на два этапа (как у модулей): сначала подгрузка активных плагинов (и делегирование), а потом инициализация уже загруженных плагинов.
При таком подходе можно будет при инициализации одного плагина использовать модули, которые были переопределены в других плагинах.
маленькая несовместимость конвертера базы в формат 0.4 с модулем Админпанели: если установлен данный модуль, то при инсертах голосов (1262 строка файла install/index.php) мускль ругается на несоответствие количества колонок в таблице и запросе (т.к. в запросе не перечислены имена колонок через () VALUES (), а вставка идет сразу по порядку колонок). в результате не переносятся голоса за, как я понимаю, комменты и блоги.
Предлагаю простой багфикс — во всех INSERT-ах в конвертере указывать имена колонок, чтобы не было похожих проблем в другими модулями — мало ли что и кто-то ALTER-ил системные таблицы.
Предлагаю простой багфикс — во всех INSERT-ах в конвертере указывать имена колонок, чтобы не было похожих проблем в другими модулями — мало ли что и кто-то ALTER-ил системные таблицы.
Файл /config/loader.php:
...
$aConfigFiles = glob($sPluginsDir.'/'.$sPlugin.'/config/*.php');
if(count($aConfigFiles)>0) {
...
}
После апдейта пропали аватарки на группах и юзерах, вернее пути похерились, с группами проще, а вот юзеров можно пофиксить как то?
Уже сказать не могу, вроде бы там просто остались цифры какие то вместо путей… откатился, попробовал поновой обновить, короче теперь у меня вообще ничего не работает, точнее частями, ошибки выдает, опять откатился… что я не так делаю?
может инсталл без саф моде не отрабатывает?!
может инсталл без саф моде не отрабатывает?!
практически везде на подобии: SQL Error: Unknown column 'uf.user_from' in 'field list' at /home/..../classes/modules/user/mapper/User.mapper.class.php line 497
Array ( [code] => 1054 [message] => Unknown column 'uf.user_from' in 'field list' [query] => SELECT uf.user_from, uf.user_to FROM prefix_friend as uf WHERE ( uf.user_from = 1 OR uf.user_to = 1 ) AND ( uf.status_from + uf.status_to = 3 ); [context] => /home/..../classes/modules/user/mapper/User.mapper.class.php line 497 )
Array ( [code] => 1054 [message] => Unknown column 'uf.user_from' in 'field list' [query] => SELECT uf.user_from, uf.user_to FROM prefix_friend as uf WHERE ( uf.user_from = 1 OR uf.user_to = 1 ) AND ( uf.status_from + uf.status_to = 3 ); [context] => /home/..../classes/modules/user/mapper/User.mapper.class.php line 497 )
Аналогичная ошибка. Решил на тестовом сервере обновить свой сайт.
Во время конвертации из 0,3 в 0,4,1 выдало
Теперь в разных местах вылетает ошибка, аналогичная вашей.
Как-то решили проблему?
Во время конвертации из 0,3 в 0,4,1 выдало
Error: Error on rename of './l2plus/prefix_friend' to './l2plus/#sql2-5b5-100c8' (errno: 152)
Error: Error on rename of './l2plus/prefix_favourite' to './l2plus/#sql2-5b5-100c8' (errno: 152)
Error: Error on rename of './l2plus/#sql-5b5_100c8' to './l2plus/prefix_friend' (errno: 150)
Error: Key column 'user_to' doesn't exist in table
Error: Unknown column 'user_to' in 'where clause'Теперь в разных местах вылетает ошибка, аналогичная вашей.
Как-то решили проблему?
В patch.sql ошибка в 135 строке:
134: ALTER TABLE `prefix_user` ADD `user_date_topic_last` DATETIME AFTER `user_date_comment_last` ;
135: ALTER TABLE `prefix_user` DROP `user_date_topic_last`
В конфиге пояснения перепутаны местами
$config['general']['reg']['invite'] = false; // использовать активацию при регистрации или нет
$config['general']['reg']['activation'] = false; // использовать режим регистрации по приглашению или нет. Если использовать, то регистрация будет доступна ТОЛЬКО по приглашениям!
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
Комментарии (178)
RSS свернуть / развернуть