Вот собственно ваши слова, да мистеру PSNet в уши))) По его словам всё просто :) Вместо ника будет НИК (!) — оно же ИМЯ, просто в данной версии CMS всё привязали к уникальному и бессмысленному полю «login». Нарушая этим саму «философию» этого поля, так как по природе оно используется в связке с `pass` при авторизации.
Вам ответ, ссылка приведёт на профиль пользователя:
Тут можно долго рассуждать, но только если АДЕКВАТНО, в той манере в которой данное сообщество ведёт обсуждения серьёзных вещей, это того не стоит.
Я для себя пилю движок как мне нужно, ибо могу это сделать. Была мысль подключиться к обсуждению структуры и устройства движка, писать о своих наработках, делиться опытом и «переживаниями» — только кому это нужно?)))))
Сама цель сообщества CMS LiveStreet тупиковая! Здесь никто никому не помогает, а в 90% случаев ответы если приходят, то типа — делай сам, или заказывай у нас разработку. Парни, это ваше полное право. Вам виднее как управлять развитием CMS и сообщества…
PSNet Лично прошу у вас прощения, только вчера узнал, что вы не простой человек :)
И уже учитывая ваше положение обращусь к вам лично — будьте мягче)) Я никакой не засланец, и на ваш движок не наговариваю. Я вчера ПРОВЁЛ перевод движка на исключение `user_login` из использование в нём, заменив там где нужно на НЕ уникальный `user_name` (по умолчанию «Гость») и где нужно было для связи на `user_id` — я чуть чуть знаю о чём говорю.
Учитывая, что у системы до сих пор нет «порядочного» описания, разобраться в ней без пол литра очень проблематично.
люди подписываются на события пользователя, вводя его логин в форме, вот и сравнивания кусок кода. а внутри движка все связи, естественно, на ид.
Если бы это было так, я бы не писал этот топик. В движке `user_login` используется в самых неожиданных местах… Приводить их все нет смысла, кому нужно будет столкнётся с этим сам. Только вы больше меня знаете ту самую структуру, и позволяете себе так резко и так БЕЗ основательно высказываться о ней (!)
В 98% я заменил getLogin на getName или getId, а GetUserByLogin заменил на GetUserById — это фактически на час работы, но я не об этом. В новых веб проектах уже очень редко можно встретить поле «login» при регистрации, по простой причине — он не нужен, это пережиток. И если бы этот пережиток упоминался в коде в двух строках, я бы ничего против не говорил.
Использовать цифры — легко, но
public function getUserWebPath() {
return Router::GetPath('profile').$this->getLogin().'/';
}
Имена только говорите… Дам даже файлы кэша даже именные )))
public function GetUserByLogin($sLogin) {
$s=strtolower($sLogin);
if (false === ($id = $this->Cache_Get("user_login_{$s}"))) {
if ($id = $this->oMapper->GetUserByLogin($sLogin)) {
$this->Cache_Set($id, "user_login_{$s}", array(), 60*60*24*1);
}
}
return $this->GetUserById($id);
}
Здесь нужен анализ в целом «нужности» — для меня это не нужно. Я писал, что для внутренних связей достаточно использовать ID пользователя — он уникален. А имя пользователя в уникальности почти никогда не нуждается!
совсем не рутинное дело я вам скажу, не утрируйте.
Только вы не забывайте. Там где нужно ИМЯ — поменяем на getName, а где нужен идентификатор — getId вместо getLogin — а это уже предполагает знание архитектуры
Сути это не меняет. Я точу CMS под себя, и просто выразил своё возмущение текущей структуре — она в этом ключе весьма архаична… Нужно быть в трэнде как никак :)
Поэтому у вас вместо логина в поле автора статьи должно быть мыло!
Это первое что я сделал, НО — накуа тогда ДВА поля содержащих емайл? Куда вас понесло с ФИО и инициалами… — санитары!))) Я добавил НЕ(!) УНИКАЛЬНОЕ поле `user_name` — у меня не база данных МВД — у меня обычный чайт, на котором будет пару тысяч пользователей.
Ну не нужен этот `user_login` — это старо как говно мамонта и абсолютно не нужно!
А по сути, имеет место не понимание сути вещей :) Параметр отвечающий за слияние файлов CSS отчасти не имеет оношения к кэшу чуть больше, чем вообще не имеет.
А сброс кэша на продакшене не приводит к сбросу кэша в браузере. У меня браузер даже не обращается за этими файлами — сразу берет их своего браузерного кэша. Чтобы его принудить обноситься, самый тупой и дедовский метод — поменять имя файлов. Кто-то делает версию сss как параметр типа main.css?ver=1 кто еще как извращается.
Проблем при отключении «слияния» появится больше, чем было с ним — файлы CSS и JS будут закэшированы самим браузером. Доказывать никому ничего не буду ;)
Да нет же, именно кэш этих двух файлов — и лежат они в папке /templates/cache/
И как-то не совсем ясно как «указывает на необходимость слияния файлов по указанным блокам.» относится к кэшированию…
А дальше нужно понять, что и как и для чего инициализируется. Это происходит уже в главном файле, выше скинов — у меня /engine/lib/internal/template/js/comments.js
Там нужно не фунцию курочить, а найти инициализацю и там отключить скрытие формы, смотрим, у меня строка 330 — this.init = function()
this.init = function() {
this.initEvent();
this.calcNewComments();
this.checkFolding(); // На следующей строке вызов функции СКРЫТИЯ формы комментов
this.toggleCommentForm(this.iCurrentShowFormComment); // вот эта сука
if (typeof(this.options.wysiwyg)!='number') {
this.options.wysiwyg = Boolean(BLOG_USE_TINYMCE && tinyMCE);
}
ls.hook.run('ls_comments_init_after',[],this);
};
Или удалите эту строку или закомментируйте //
Пока разработчики LS не поймут, что нужно сделать хотя бы десятистраничное руководство и положить его рядом со ссылкой СКАЧАТЬ LS — то после скачивания вашей красивейшей CMS до 90% скачаших её удалят и поставят WordPress (!)
Адовый пипец отправлять на «к месту» заданный вопрос в поиск по яндексу «html» — конкретный вопрос — как ширину менять в шаблоне CMS а не на самописной домашней страничке… Роем сами господа…
Поиск по файлам CMS — #container встречается в /templates/skin/synio/css/grid.css но у меня там ширина не задана, так как она динамически ставится в файле шаблона /templates/skin/synio/header.tpl в строках
И вы имеете смелость предложить искать через Яндекс??
Это мне легко было найти ответ на этот ТРИВИАЛЬНЫЙ вопрос. CMS по своим характеристикам офигитительная, но как, КАК можно рассчитывать на быстрое распространение её использования если СООБЩЕСТВО минусит за элементарный вопрос, не давая при этом ни ссылки на FAQ ни на страницу/раздел документации.
Вам ответ, ссылка приведёт на профиль пользователя:
return Router::GetPath('profile').$this->getId().'/';Тут можно долго рассуждать, но только если АДЕКВАТНО, в той манере в которой данное сообщество ведёт обсуждения серьёзных вещей, это того не стоит.
Я для себя пилю движок как мне нужно, ибо могу это сделать. Была мысль подключиться к обсуждению структуры и устройства движка, писать о своих наработках, делиться опытом и «переживаниями» — только кому это нужно?)))))
Сама цель сообщества CMS LiveStreet тупиковая! Здесь никто никому не помогает, а в 90% случаев ответы если приходят, то типа — делай сам, или заказывай у нас разработку. Парни, это ваше полное право. Вам виднее как управлять развитием CMS и сообщества…
И уже учитывая ваше положение обращусь к вам лично — будьте мягче)) Я никакой не засланец, и на ваш движок не наговариваю. Я вчера ПРОВЁЛ перевод движка на исключение `user_login` из использование в нём, заменив там где нужно на НЕ уникальный `user_name` (по умолчанию «Гость») и где нужно было для связи на `user_id` — я чуть чуть знаю о чём говорю.
Учитывая, что у системы до сих пор нет «порядочного» описания, разобраться в ней без пол литра очень проблематично.
Если бы это было так, я бы не писал этот топик. В движке `user_login` используется в самых неожиданных местах… Приводить их все нет смысла, кому нужно будет столкнётся с этим сам. Только вы больше меня знаете ту самую структуру, и позволяете себе так резко и так БЕЗ основательно высказываться о ней (!)
Поиск getLogin 192 matches.
Поиск GetUserByLogin 16 matches.
В 98% я заменил getLogin на getName или getId, а GetUserByLogin заменил на GetUserById — это фактически на час работы, но я не об этом. В новых веб проектах уже очень редко можно встретить поле «login» при регистрации, по простой причине — он не нужен, это пережиток. И если бы этот пережиток упоминался в коде в двух строках, я бы ничего против не говорил.
Использовать цифры — легко, но
public function getUserWebPath() { return Router::GetPath('profile').$this->getLogin().'/'; }Имена только говорите… Дам даже файлы кэша даже именные )))
public function GetUserByLogin($sLogin) { $s=strtolower($sLogin); if (false === ($id = $this->Cache_Get("user_login_{$s}"))) { if ($id = $this->oMapper->GetUserByLogin($sLogin)) { $this->Cache_Set($id, "user_login_{$s}", array(), 60*60*24*1); } } return $this->GetUserById($id); }Здесь нужен анализ в целом «нужности» — для меня это не нужно. Я писал, что для внутренних связей достаточно использовать ID пользователя — он уникален. А имя пользователя в уникальности почти никогда не нуждается!
Только вы не забывайте. Там где нужно ИМЯ — поменяем на getName, а где нужен идентификатор — getId вместо getLogin — а это уже предполагает знание архитектуры
Сути это не меняет. Я точу CMS под себя, и просто выразил своё возмущение текущей структуре — она в этом ключе весьма архаична… Нужно быть в трэнде как никак :)
Это первое что я сделал, НО — накуа тогда ДВА поля содержащих емайл? Куда вас понесло с ФИО и инициалами… — санитары!))) Я добавил НЕ(!) УНИКАЛЬНОЕ поле `user_name` — у меня не база данных МВД — у меня обычный чайт, на котором будет пару тысяч пользователей.
Ну не нужен этот `user_login` — это старо как говно мамонта и абсолютно не нужно!
Проблем при отключении «слияния» появится больше, чем было с ним — файлы CSS и JS будут закэшированы самим браузером. Доказывать никому ничего не буду ;)
И как-то не совсем ясно как «указывает на необходимость слияния файлов по указанным блокам.» относится к кэшированию…
В шаблоне в файле JS идёт инициализация класса комментариев — у меня это /templates/skin/synio/js/template.js
// инизиализация блоков ls.blocks.init('stream',{group_items: true, group_min: 3}); ls.blocks.init('blogs'); ls.blocks.initSwitch('tags'); ls.blocks.initSwitch('upload-img'); ls.blocks.initSwitch('favourite-topic-tags'); ls.blocks.initSwitch('popup-login'); // комментарии ls.comments.init(); // -- ВОТ ЭТА СТРОКА !!!!!!! // избранное ls.hook.add('ls_favourite_toggle_after',function(idTarget,objFavourite,type,params,result){ $('#fav_count_'+type+'_'+idTarget).text((result.iCount>0) ? result.iCount : ''); });А дальше нужно понять, что и как и для чего инициализируется. Это происходит уже в главном файле, выше скинов — у меня /engine/lib/internal/template/js/comments.js
Там нужно не фунцию курочить, а найти инициализацю и там отключить скрытие формы, смотрим, у меня строка 330 — this.init = function()
this.init = function() { this.initEvent(); this.calcNewComments(); this.checkFolding(); // На следующей строке вызов функции СКРЫТИЯ формы комментов this.toggleCommentForm(this.iCurrentShowFormComment); // вот эта сука if (typeof(this.options.wysiwyg)!='number') { this.options.wysiwyg = Boolean(BLOG_USE_TINYMCE && tinyMCE); } ls.hook.run('ls_comments_init_after',[],this); };Или удалите эту строку или закомментируйте //
Пока разработчики LS не поймут, что нужно сделать хотя бы десятистраничное руководство и положить его рядом со ссылкой СКАЧАТЬ LS — то после скачивания вашей красивейшей CMS до 90% скачаших её удалят и поставят WordPress (!)
Поиск по файлам CMS — #container встречается в /templates/skin/synio/css/grid.css но у меня там ширина не задана, так как она динамически ставится в файле шаблона /templates/skin/synio/header.tpl в строках
{if {cfg name='view.grid.type'} == '<strong>fluid</strong>'} <style> <strong>#container</strong> { min-width: {cfg name='view.grid.fluid_min_width'}px; max-width: {cfg name='view.grid.fluid_max_width'}px; } </style> {else} <style> <strong>#container</strong> { width: {cfg name='view.grid.fixed_width'}px; } </style> {/if}А сами переменные находятся в файле конфига — /templates/skin/synio/settings/config/config.php строки
И вы имеете смелость предложить искать через Яндекс??
Это мне легко было найти ответ на этот ТРИВИАЛЬНЫЙ вопрос. CMS по своим характеристикам офигитительная, но как, КАК можно рассчитывать на быстрое распространение её использования если СООБЩЕСТВО минусит за элементарный вопрос, не давая при этом ни ссылки на FAQ ни на страницу/раздел документации.