avatar
+62.91
154.072

Вадим

Возможно, я невнимательно прочитал ту статью. Гляну более внимательно на досуге
Во-первых, идеал — вещь сугубо субъективная. Тем более, раз «идеал» в два раза отстает от нынешних средних значений.

Во-вторых, решил проверить — вот конкретно эта страницы весит около 1 Мб, т.е. аккурат идеал! И это при том, что около 40% — картинки.

Ну, и в третьих, если все ж есть желание стремиться к идеалу — сделайте сперлайт версию шаблона и отдайте ее в публичный доступ, и «к нему на зарастет народная тропа»
Это не «злостность», а средний вес страницы в инете по состоянию на май 2015 года:

http://www.soasta.com/blog/page-bloat-average-web-page-2-mb/
Потому что в Альто эта задача решается иначе:
1) У блогов есть признак, индексировать входящие в них топики или нет (поле index_ignore)
2) У топиков тоже есть признак индексации (поле topic_index_ignore)
3) В индексе Сфинкса в условиях WHERE значится:
AND t.topic_index_ignore=0

Этот признак топика отслеживается и проставляется в нужное значение при соответствующих манипуляциях — добавление, редактирование, перенос в другой блог и т.д.
А предполагается, что у настроек много страниц? Типа, site.ru/feed/settings/page1, site.ru/feed/settings/page2 и т.д.? Если нет, то достаточно экшене Feed задать обработчик простого ивента так:
$this->AddEvent('settings', 'EventSettings');

Затем нужно код самого ивента добавить:
public function EventSettings() {
    // тут код
}

И шаблон: .../tpls/actions/feed/action.feed.settings.tpl — такой шаблон будет вызываться по умолчанию для этого ивента
Так это было давным давно сделано, по-моему, еще в самой первой пре-релизной версии Альто. Только вот в ЛС это все делается элементарно, т.к. там блог либо открытый, либо закрытый, третьего не дано. А вот в Альто с тех пор многое изменилось, в частности, появилось множество настроек для блогов, указывающих, для кого блог закрыт, а для кого открыт. И т.к. строить индексы Сфинкса для каждого юзера нереально, то для блогов сейчас просто задается опция — индексировать их или нет
Может, в кеш-директории затесались файлы с кривыми правами? Попробуйте удалить содержимое директории /_tmp (кроме .htaccess разумеется).

И можно еще в логах посмотреть — там должно быть больше информации, возможно, даже имя файла/директории есть, на которых движок спотыкается
В админке надо настроить типы блогов. По умолчанию обычный открытый блог могут создавать пользователи рейтингом не ниже 1
Если речь о плагине reCaptcha, то для его использования надо регистрироваться у Гугда и получать ключи
В принципе, можно даже прямо в шаблонном виджете это сделать, примерно так:
{$iTopicCount=1+$iTopicCount}
{if $iTopicCount>4}
  {$iTopicCount=0}
  здесь нужный HTML-код
{/if}
Не очень изящно, зато просто. Но городить огород с исполняемым виджетом только для того, чтоб счетчик реализовать, это, наверное, все ж излишество.
Как это проект приказал долго жить...
Элементарно — движок либо развивается, либо умирает, это мое твердое убеждение.

Да вы зайдите на сайт и посмотрите что это)) И сколько людей участвует и как он вообще работает)) На скорость, на UI/UX
Мы о чем говорим — хороший ли движок? Или что такое успех? Пройдет хотя бы года три в развитии, тогда и можно будет говорить об успехе/неуспехе. На моей памяти столько великолепных программных продуктов умерло, которые по многим параметрам были на голову выше конкурентов...

но при этом жалуетесь...
Кто жалуется? Я жалуюсь? Господь с Вами! Я всего лишь констатирую факты и говорю о своем опыте.
Как раз первый релиз вышел в 2011...
Угу, версия 1.0.0g1, при этом v1.0.0g3 значится как «Pre-release». Но это не суть, главное, что проект приказал долго жить, что в контексте « успеха в свободном ПО» выглядит весьма примечательным: ни энтузиазм поклонников, ни бесплатность, ни какие-то иные привлекательные стороны движка не помогли ему выжить.

Flarum пилится около года, первая версия еще не вышла из беты, а какова будет его судьба — одному Богу известно. Уж кому-кому, а мне-то хорошо известно, как легко можно начать открытый проект, и как непросто его потом удерживать на плаву.

Значит вы подтверждаете мои тезисы
Ни на йоту не подтверждаю. Ибо те, кто платит мне нормальные деньги понятия не имеют ни о моих экспериментах с ЛС, ни об Альто. А те, кто бесплатно пользовался моими ЛС-плагинами, перечислили мне донейтов, в общей сложности, 10-15 баксов, и какой-то иной финансовой выгоды я больше не имел. Это параллельные миры, которые, практически, не пересекаются.
Букв много, но на чем основаны суждения? Хорошо, давайте возьмем столь любимый Вами esoTalk. И что видим: за два с половиной года (с 2011 до 2014) так и не вышли из пре-релиза, последний релиз — почти два года назад, последний год — в основном, прием пуллреквестов с фиксами. Вы считаете это колоссальным успехом? Хм, на мой взгляд, более, чем сомнительное утверждение. Поэтому и ко всем остальным утверждениям отношение соответствующее.

И, кстати, насчет «смешно» — в свое время моя админка для ЛС была самым скачиваемым плагином (точной цифры уже не помню, но десятки тысяч скачиваний были), и мой опыт и экспертиза действительно стоят недешево (работаю, как системный аналитик и проджект менеджер в нескольких проектах). И в каком месте тут надо смеяться?

А вот что действительно смешно — это то, что Вы рассуждаете так, будто всех видите насквозь и по каждому проекту обладаете офигительной инсайдерской информацией.
Я так понимаю, что задача стоит выводить виджет в ленте топиков через каждый N топиков, так?

Тогда я бы предложил такой подход: создается программный виджет, который в шаблоне будет выводиться в ленте после каждого топика. Но в программном коде виджета считать каждый его вызов, и когда нужно — возвращать отрендеринный соответствующий шаблон, а когда не нужно — выводить пустую строку.
Для чтения через API есть плагин. А вот с добавлением все непросто — есть проблемы с тем, как сейчас реализована функциональная логика, это придется менять. И это не очень простой и не очень быстрый процесс. Поэтому скорого результата обещать не могу.
Если сравнивать виджеты Альто и блоки LS, то виджеты буквально с первого релиза были гораздо функциональнее, чем LS-блоки: можно было их включать, выключать, задавать условия и исключения для отображения.

И как-то обсуждали уже идею с построением шаблона полностью на виджетах, но дальше обсуждения дело не пошло, т.к. нужно потратить немало усилий и создать хотя бы рабочий прототип, чтобы понять, насколько эта идея работоспособна, нет ли каких-то подводных камней и т.д.
Ключевой вопрос: чего ждете от API? Полноценного управления контентом или требуется режим read only для импорта контента?
Допиливать придется любой движок. А какой проще — это очень субъективно, кому как. Какой движок кажется понятнее и легче в освоении, тот проще )
Небольшая поправка к комментариям выше: если поле называется user_profile_nick, то «магический» метод будет такой: getUserProfileNick() для получения свойства и setUserProfileNick() для присвоения.

Специально методы для присваивания и получения свойства имеет смысл писать, если в силу каких-то причин имя метода не эквивалентно имени поля. Напр., поле называется user_profile_nick, а обращаться требуется (или просто хочется) как getNick()/setNick(). Либо если требуются какие-то дополнительные действия, преобразования и т.д. Например:
public function getNick() {
    $sResult = $this->getProp('user_profile_nick');
    if (!$sResult) {
        $sResult = $this->getUserLogin();
    }
}
В этом примере, если поле user_profile_nick не заполнено, то возвращается логин юзера.
Спасибо