Готовый рецепт трудно дать, я не знаю, есть ли у кого такой опыт. Могу только сказать, что есть папка с шаблонами для разных редакторов: common/templates/skin/experience/tpls/editors/
И есть js-файл с настройками редакторов: common/templates/frontend/libs/js/engine/settings.js
Достаточно ли только их поправить или еще что-то придется копать — не знаю
Там все банально и безхитростно — после установки плагина надо перезагрузить страницу, и будет создана папка (по умолчанию — /_dev), в которой плагин сгенерит два файла с описаниями классов в PhpDocs. IDE их подхватывает и начинает работать автокомплит.
На вещи типа E::Module('User') никак не будет реагировать, увы, тут такие простые примчики уже не прокатят, а нужно более серьезное расширение для IDE писать.
По поводу cookbook — да, давно пора, но пока ресурсов на это не хватает. Но постараюсь на днях выложить короткую презентацию, которая описывает общий принцип работы движка. А также статью про динамическое автонаследование, на котором вся система плагинов строится.
Без паники! :) Вот этот самый код, что ты привел, без всяких изменений будет работать, как и прежде. Т.е. перелопачивать старый код и его менять не требуется.
Но если писать новый плагин, то этот же вызов там может быть оформлен так:
Принцип организации плагинов что в LS, что в Alto одинаков. Но различия, конечно есть:
1) иная структура папок и шаблонов
2) вместо «блоков» используются виджеты.
Если про API (т.е. классы и их методы), то они во многом совпадают.
Подо что лучше писать — вопрос сложный. С одной стороны, под LS 1.x вроде как поздно, а под LS 2.0 — рано. С другой — я думаю, что немало ресурсов под LS 1.х еще долго будет оставаться, а, стало быть, расширения для них будут актуальны.
Если писать плагины под Alto, то под LS они работать почти наверняка не будут. А модуля совместимости Alto->LS точно не будет — нам не надо, разработчикам LS — тоже :)
В общем, это бурное обсуждение стало причиной того, что в версии 1.1 рейтинг будет вынесен в плагин. Точнее, даже в два плагина: один со стандартным «хабраподобным» алгоритмом (т.е. это нынешний алгоритм, но в виде плагина с настройками в конфиге), и один с простым — без силы и с простым подсчетом плюсов/минусов. Или просто плюсов — это все в настройках задается.
Черновые версии плагинов уже на гитхабе (в ветке 1.1), более подробно будет рассказано в отдельной статье.
Самый эффективный способ борьбы с таким спамом — ограничивать для пользователей с регистрацией меньше месяца лимит на постинг в день
Не, этого мало. У меня, как правило, боты не больше двух постов писали (возможно, больше просто не успевали :)
Думаю, более эффективно — это премодерация топиков с ссылками для юзеров-юниоров (либо по дате регистрации, либо рейтингу). В подавляющем числе случаев в спам-топиках есть ссылки.
Но тут есть еще один нюанс — если даже боты эффективно отсеиваются на странице регистрации, то сами их попытки могут создавать нехилую нагрузку на слабенький хост, т.к. каждый их запрос — это полный цикл отработки движка.
Вот специально для подобных вещей в 1.1 капчу и переделали, чтоб легко и просто можно было ее заменять на свою, в т.ч. и с вопросами, картинками и проч.
С учетом тегов в этом топике более 2,5 тыс. символов. Плюс текст топика в базе в двух версиях хранится — в исходном виде, и пропущенный через Джевикс. Плюс вспомогательные поля, плюс запись заголовка и служебной информации в отдельной таблице. Но все равно в итоге получается на порядок меньше общего объема базы.
У меня есть тестовая база:
Пользователей: 2380
Блогов: 553
Топиков: 30283
Комментариев: 17262
На самом деле не только ЛС/Альто, а многопользовательские сайты, т.е. где юзеры могут самостоятельно зарегистрироваться, подтвердить регистрацию мылом и сразу начать постить. Мне про подобное рассказывали владельцы сайтов на Друпале и Джумле, где была открытая регистрация.
Явных уязвимостей у Альто в этом плане не обнаружено. Я смотрел серверные логи, и там видно, что регистрации бывают двух видов:
1) Идет тупо программная попытка подбора капчи. Возможно, на том конце даже какая-то система распознавания работает, но не очень хорошая, т.к. много ошибочных результатов. «Долбежка» может идти весьма основательная, иногда — несколько сотен попыток регистрации в час, с разных IP, с разными сессиями. И часть из них прорывается.
2) Иногда регистрации явно вручную идут — капча вводится с первой попытки, время между запросом страницы и отправкой формы довольно большое. А потом, видимо, рег. данные уже в базу вносят, и бот авторизуется и постит топики.
На этом сайте тоже было такое, специальный плагин пришлось писать: altocms.ru/859.html
Насколько я помню, в таблицах базы данных типа InnoDB при удалении записи в самом файле БД остается «дырка». Соответственно, если было добавлено много записей, а потом они были удалены, то занимаемое на диске место не уменьшится. Чтобы сжать базу (избавиться от «дырок»), нужно сделать бэкап базы, саму базу удалить, а потом восстановить из бэкапа.
И там выводится панелька с кнопками голосования непосредственно при рендеринге страницы на сервере.
2) Панелька может втыкаться яваскриптом в заданных местах.
Минус первого варианта в том, что чтобы добавить голосовалку к новой сущности (напр., к стене), нужно явно править шаблон в нужном месте. Но зато код отрабатывает на сервере и весь HTML-код генерится там.
Минус второго варианта — немного больше возни с реализацией, больше нагрузка на клиента. Но зато вешается практически на любой шаблон без всяких доработок.
Только один вопрос, будет ли возможность влияния этих виджетов на общий рейтинг пользователя?
В обоих вариантах при клике на кнопку +\- идет запрос на сервер и передается информация, кто проголосовал, за что. А там уж от алгоритма обработки запроса зависит, на что этот голос будет влиять, и от настроек плагина. Если нужно — будет влиять, не нужно — не будет.
В итоге можно вообще пользователей не мучить никакими числами, но при этом ранжировать...
Мне кажется, что в какие-то числа это все равно надо рядить (или в «звездочки», или в какие-то «попугайчики». Ибо юзеру не будет понятно, почему сегодня один блог выше в списке, а завтра — другой. Но это уже детали реализации. Главное, чтоб была сама возможность.
Ух, какая дискуссия :) И она только еще раз подтверждает мою мысль: рейтинг — это механизм, который должен легко настраиваться, заменяться на другой или вовсе отключаться. Alyona ратует за простой и понятный всем рейтинг, inliquid — за рейтинг с множеством весовых коэффициентов, но, как я понял, без силы, aleksanderd — за относительный рейтинг с учетом социального графа. И нет смысла пытаться все это совместить в одном программном модуле. Гораздо лучше сделать его заменяемым, т.е. — плагином.
Более того, хочется сделать так, чтоб в систему рейтингования можно было включать любые сущности, напр., загруженные фотографии и видеоролики, или компании и товары (т.е. сущности, создаваемые сторонними разработчиками) и т.д.
Если внимательно посмотреть, то все описываемые тут изменения — это для того, чтоб в шаблоне по максимуму задействовать все новые фишки.
Т.е., хотите, чтобы у вас работали сниппеты? Тогда нужно сделать вот это. Не нужно вам — эта фича просто не будет работать, но ошибок выдаваться не будет. Нужен новый редактор фотосетов? Значит, стоит подрихтовать шаблон. Не нужен? Оставляете, как есть, с загрузкой через swfupload. И с меню та же байда, и с аватарами.
Допускаю, что в деталях я могу ошибаться, и все ж где-то придется слегка что-то чуть-чуть подпилить. Но я постараюсь обеспечить совместимость снизу вверх по максимуму.
И есть js-файл с настройками редакторов: common/templates/frontend/libs/js/engine/settings.js
Достаточно ли только их поправить или еще что-то придется копать — не знаю
На вещи типа E::Module('User') никак не будет реагировать, увы, тут такие простые примчики уже не прокатят, а нужно более серьезное расширение для IDE писать.
По поводу cookbook — да, давно пора, но пока ресурсов на это не хватает. Но постараюсь на днях выложить короткую презентацию, которая описывает общий принцип работы движка. А также статью про динамическое автонаследование, на котором вся система плагинов строится.
Но если писать новый плагин, то этот же вызов там может быть оформлен так:
1) иная структура папок и шаблонов
2) вместо «блоков» используются виджеты.
Если про API (т.е. классы и их методы), то они во многом совпадают.
Подо что лучше писать — вопрос сложный. С одной стороны, под LS 1.x вроде как поздно, а под LS 2.0 — рано. С другой — я думаю, что немало ресурсов под LS 1.х еще долго будет оставаться, а, стало быть, расширения для них будут актуальны.
Если писать плагины под Alto, то под LS они работать почти наверняка не будут. А модуля совместимости Alto->LS точно не будет — нам не надо, разработчикам LS — тоже :)
Черновые версии плагинов уже на гитхабе (в ветке 1.1), более подробно будет рассказано в отдельной статье.
Думаю, более эффективно — это премодерация топиков с ссылками для юзеров-юниоров (либо по дате регистрации, либо рейтингу). В подавляющем числе случаев в спам-топиках есть ссылки.
Но тут есть еще один нюанс — если даже боты эффективно отсеиваются на странице регистрации, то сами их попытки могут создавать нехилую нагрузку на слабенький хост, т.к. каждый их запрос — это полный цикл отработки движка.
У меня есть тестовая база:
Пользователей: 2380
Блогов: 553
Топиков: 30283
Комментариев: 17262
Так она занимает 344 Mb
Явных уязвимостей у Альто в этом плане не обнаружено. Я смотрел серверные логи, и там видно, что регистрации бывают двух видов:
1) Идет тупо программная попытка подбора капчи. Возможно, на том конце даже какая-то система распознавания работает, но не очень хорошая, т.к. много ошибочных результатов. «Долбежка» может идти весьма основательная, иногда — несколько сотен попыток регистрации в час, с разных IP, с разными сессиями. И часть из них прорывается.
2) Иногда регистрации явно вручную идут — капча вводится с первой попытки, время между запросом страницы и отправкой формы довольно большое. А потом, видимо, рег. данные уже в базу вносят, и бот авторизуется и постит топики.
На этом сайте тоже было такое, специальный плагин пришлось писать: altocms.ru/859.html
Картинки от удаленных статей остаются на диске
1) В нужном месте шаблона вставляется код типа:
И там выводится панелька с кнопками голосования непосредственно при рендеринге страницы на сервере.
2) Панелька может втыкаться яваскриптом в заданных местах.
Минус первого варианта в том, что чтобы добавить голосовалку к новой сущности (напр., к стене), нужно явно править шаблон в нужном месте. Но зато код отрабатывает на сервере и весь HTML-код генерится там.
Минус второго варианта — немного больше возни с реализацией, больше нагрузка на клиента. Но зато вешается практически на любой шаблон без всяких доработок.
В обоих вариантах при клике на кнопку +\- идет запрос на сервер и передается информация, кто проголосовал, за что. А там уж от алгоритма обработки запроса зависит, на что этот голос будет влиять, и от настроек плагина. Если нужно — будет влиять, не нужно — не будет.
Более того, хочется сделать так, чтоб в систему рейтингования можно было включать любые сущности, напр., загруженные фотографии и видеоролики, или компании и товары (т.е. сущности, создаваемые сторонними разработчиками) и т.д.
В общем, тема это большая. И явно назревшая :)
Т.е., хотите, чтобы у вас работали сниппеты? Тогда нужно сделать вот это. Не нужно вам — эта фича просто не будет работать, но ошибок выдаваться не будет. Нужен новый редактор фотосетов? Значит, стоит подрихтовать шаблон. Не нужен? Оставляете, как есть, с загрузкой через swfupload. И с меню та же байда, и с аватарами.
Допускаю, что в деталях я могу ошибаться, и все ж где-то придется слегка что-то чуть-чуть подпилить. Но я постараюсь обеспечить совместимость снизу вверх по максимуму.