Ну да, то есть это за сотнями силы ощущаться будет. Чтобы предотвратить чрезмерное вырастание пользователей в эдаких годзилл, одним голосом перечёркивающих мнение всех остальных.
Мне вообще интересно, настолько ли сильно отличаются эти кривые от линейных, чтобы оправдать логарифмы :) Хотя расчёт производится только по конкретному действию голосования (то есть — нечасто), соответственно особой нагрузки на сервер это на даёт и никому не мешает.
В config.php смотри, и нужные параметры переноси себе в config.local.php, изменяя по необходимости. Вот те, о которых ты спрашиваешь:
/**
* Настройки ACL(Access Control List — список контроля доступа)
*/
$config['acl']['create']['blog']['rating'] = 1; // порог рейтинга при котором юзер может создать коллективный блог
$config['acl']['create']['comment']['rating'] = -10; // порог рейтинга при котором юзер может добавлять комментарии
$config['acl']['create']['comment']['limit_time'] = 10; // время в секундах между постингом комментариев, если 0 то ограничение по времени не будет работать
$config['acl']['create']['comment']['limit_time_rating'] = -1; // рейтинг, выше которого перестаёт действовать ограничение по времени на постинг комментов. Не имеет смысла при $config['acl']['create']['comment']['limit_time']=0
$config['acl']['create']['topic']['limit_time'] = 240;// время в секундах между созданием записей, если 0 то ограничение по времени не будет работать
$config['acl']['create']['topic']['limit_time_rating'] = 5; // рейтинг, выше которого перестаёт действовать ограничение по времени на создание записей
$config['acl']['create']['topic']['limit_rating'] = -20;// порог рейтинга при котором юзер может создавать топики (учитываются любые блоги, включая персональные), как дополнительная защита от спама/троллинга
$config['acl']['create']['talk']['limit_time'] = 300; // время в секундах между отправкой инбоксов, если 0 то ограничение по времени не будет работать
$config['acl']['create']['talk']['limit_time_rating'] = 1; // рейтинг, выше которого перестаёт действовать ограничение по времени на отправку инбоксов
$config['acl']['create']['talk_comment']['limit_time'] = 10; // время в секундах между отправкой инбоксов, если 0 то ограничение по времени не будет работать
$config['acl']['create']['talk_comment']['limit_time_rating'] = 5; // рейтинг, выше которого перестаёт действовать ограничение по времени на отправку инбоксов
$config['acl']['create']['wall']['limit_time'] = 20; // рейтинг, выше которого перестаёт действовать ограничение по времени на отправку сообщений на стену
$config['acl']['create']['wall']['limit_time_rating'] = 0; // рейтинг, выше которого перестаёт действовать ограничение по времени на отправку сообщений на стену
$config['acl']['vote']['comment']['rating'] = -3; // порог рейтинга при котором юзер может голосовать за комментарии
$config['acl']['vote']['blog']['rating'] = -5; // порог рейтинга при котором юзер может голосовать за блог
$config['acl']['vote']['topic']['rating'] = -7; // порог рейтинга при котором юзер может голосовать за топик
$config['acl']['vote']['user']['rating'] = -1; // порог рейтинга при котором юзер может голосовать за пользователя
$config['acl']['vote']['topic']['limit_time'] = 60*60*24*20; // ограничение времени голосования за топик
$config['acl']['vote']['comment']['limit_time'] = 60*60*24*5; // ограничение времени голосования за комментарий
Ага, посмотрел, неслабая работа, круто! Надеюсь, это включат в ствол :)
Вообще, интересно, что в Synio блоки (в вышеприведённом смысле) вообще не объявлены — получается, надо пройтись по всем .tpl, и попроставлять названия? По идее, это никому не помешает, на разметку никак не повиляет и т.п., то есть вполне безопасная операция (лишь бы начальство ЛС это так восприняло :)).
Предлагаемые изменения запостил в ГитХаб — посмотрим, как они будут восприняты.
А пример задачи — если сейчас в $config['router']['uri'] прописать два урла, то по обоим этим ссылкам будет доступен одинаковый контент. Гугл говорит, что это не очень похвально, поэтому для исходного урла (который преображается в целевой) надо добавить указание, что именно целевой является главным («каноническим»).
Причём канонический линк уже поддерживается в стандартном шаблоне (и используется для пагинации), его надо только установить.
Вообще, в моём случае лучше 301 всё же, потому что речь о перманентном переносе большой пачки урлов (с предыдущей структуры сайтов). Это возможно сделать там же, в ядре, в Router.class.php, только вот пока что не вижу способа внести эти изменения по-человечески, без хаков (спросил тут livestreet.ru/blog/12016.html, но пока что ответ НЕЛЬЗЯ, но надежда умирает последней :)).
Зачем: Дописать обработку массива псевдонимов, чтобы при использовании псевдонима (из $config['router']['uri']) проходил редирект по 301 (или устанавливалось значение канонического пути во View — см. livestreet.ru/blog/11908.html).
Разобрался, как сделать и то и то в ядре, в Router.class.php, но не хотел бы оставлять это в виде хака.
В принципе, каноник я могу установить и по экшину показа — полностью скопировать туда парсинг псевдонимов, и если результат не совпал с ури запроса — добавлять каноник. Но 301 так сделать уже не получится, насколько я понимаю.
Ну я так и понимаю. Поэтому удивляет, что ЛС проставляет этот линк только для первой страницы в пагинации — должно же быть наобророт, на всех остальных, с указанием ссылки на первую?
Эта переменная устанавливается в классе Viewer в функции SetHtmlCanonical, и применяется (насколько я вижу) исключительно для постраничного вывода — причём почему-то только для первой страницы выставляется canonical (что смотрится крайне странно, но может я не всё понял).
Вызвать эту функцию, чтобы установить канонический урл, в Router::RewriteRequest (где разбирается конфиг псевдонимов) не представляется возможным — потому что объект Viewer на тот момент ещё неинициализирован.
Самое раннее, куда получается его впихнуть, это в Router::Exec, после инициализации объекта Engine (логично). И пока что у меня это получилось только в виде хака (и он работает), но я хочу понять, как это сделать «красиво» — то ли плагином, то ли предложить дописать эту функциональность в ядро.
Я так понимаю, что если делать плагин, то надо переписывать весь класс Router, только пару методов зацепить не получится. Хотелось бы избежать массированного копи-паста.
Почитал, подумал. Хм, выходит, можно не беспокоиться о статусе запроса (301 или 200), если везде указать канонический урл, правильно я понимаю?
Если так, то его использование полностью устраивает :) Только, насколько я вижу, он не прописывается для страниц, прописанных в $config['router']['uri']. Вообще, это тянет на прекрасное дополнение к CMS-ке — правильная работа с псевдонимами на полу не валяется. Надо глянуть, может получится патч предложить? :)
Угу, причём в Location (и только в нём, насколько я вижу) безусловно вызывается функция, возвращающая 301 в заголовке:
function func_header_location($sLocation) {
header("HTTP/1.1 301 Moved Permanently");
header('Location: '.$sLocation);
exit();
}
Поэтому как бы приладить Location к псевдонимам… и почему он вызывается при показе топика по адресу id.html (независимо от настройки псевдонимов, но не вызывается при вызове моих псевдонимов?
Я так понимаю, что хакнуть ядро тут не так и трудно будет (могу ошибаться), но именно хаканья и хотелось бы избежать.
Ты ж можешь сам сырцы плагина посмотреть, там всё очень логично расположено. Я смотрел :)
Логично :)
Мне вообще интересно, настолько ли сильно отличаются эти кривые от линейных, чтобы оправдать логарифмы :) Хотя расчёт производится только по конкретному действию голосования (то есть — нечасто), соответственно особой нагрузки на сервер это на даёт и никому не мешает.
Вообще, интересно, что в Synio блоки (в вышеприведённом смысле) вообще не объявлены — получается, надо пройтись по всем .tpl, и попроставлять названия? По идее, это никому не помешает, на разметку никак не повиляет и т.п., то есть вполне безопасная операция (лишь бы начальство ЛС это так восприняло :)).
А пример задачи — если сейчас в $config['router']['uri'] прописать два урла, то по обоим этим ссылкам будет доступен одинаковый контент. Гугл говорит, что это не очень похвально, поэтому для исходного урла (который преображается в целевой) надо добавить указание, что именно целевой является главным («каноническим»).
Причём канонический линк уже поддерживается в стандартном шаблоне (и используется для пагинации), его надо только установить.
Зачем: Дописать обработку массива псевдонимов, чтобы при использовании псевдонима (из $config['router']['uri']) проходил редирект по 301 (или устанавливалось значение канонического пути во View — см. livestreet.ru/blog/11908.html).
Разобрался, как сделать и то и то в ядре, в Router.class.php, но не хотел бы оставлять это в виде хака.
В принципе, каноник я могу установить и по экшину показа — полностью скопировать туда парсинг псевдонимов, и если результат не совпал с ури запроса — добавлять каноник. Но 301 так сделать уже не получится, насколько я понимаю.
Вызвать эту функцию, чтобы установить канонический урл, в Router::RewriteRequest (где разбирается конфиг псевдонимов) не представляется возможным — потому что объект Viewer на тот момент ещё неинициализирован.
Самое раннее, куда получается его впихнуть, это в Router::Exec, после инициализации объекта Engine (логично). И пока что у меня это получилось только в виде хака (и он работает), но я хочу понять, как это сделать «красиво» — то ли плагином, то ли предложить дописать эту функциональность в ядро.
Я так понимаю, что если делать плагин, то надо переписывать весь класс Router, только пару методов зацепить не получится. Хотелось бы избежать массированного копи-паста.
Надо ещё подумать, если есть идеи — дайте знать.
Т.е. что-то таки заложено, в теории. Копаю дальше.
Только ты так говоришь, будто LS уже это делает. Я пока не вижу, как это сделать — подскажи, пожалуйста, что я упускаю (если упускаю).
Если так, то его использование полностью устраивает :) Только, насколько я вижу, он не прописывается для страниц, прописанных в $config['router']['uri']. Вообще, это тянет на прекрасное дополнение к CMS-ке — правильная работа с псевдонимами на полу не валяется. Надо глянуть, может получится патч предложить? :)
Поэтому как бы приладить Location к псевдонимам… и почему он вызывается при показе топика по адресу id.html (независимо от настройки псевдонимов, но не вызывается при вызове моих псевдонимов?
Я так понимаю, что хакнуть ядро тут не так и трудно будет (могу ошибаться), но именно хаканья и хотелось бы избежать.