Если все это про версию 1.1, то да, есть проблемка. Пофиксим

Чтоб блок комментов вообще не вставлялся на странице, это действительно только шаблон править. Решение не очень красивое и костыльное, но рабочее такое:

В файле common/templates/skin/шаблон/tpls/actions/blog/action.blog.topic.tpl есть вставка комментариев:

{include file="comments/comment.tree.tpl"
...
}

Его можно «обернуть» в такой код:

{if $oTopic->getContentType() AND $oTopic->getContentType()->getContentUrl()=="blabla"}
{include file="comments/comment.tree.tpl"
...
}
{/if}

Где «blabla» — это название на латинице, которое вы задали типу контента, у которого не должно быть комментов.

Да, класс — это еще куда ни шло, а стайл — немного перебор. Но как иначе центровать? Хотя, как вариант, можно такой код попробовать:

array(
    'p',
        array('style' => array('text-align: center;'))
),

По идее, он должен разрешать только строго конкретное значение атрибута style. Но это в теории, не пробовал на практике.

И да, лучше не /common/config/jevix.php править, а app/config/jevix.php

Верстка практически готова и скоро демо будет представлено на суд публики. Официально краудфандинг в этот раз объявлять не будем, но добровольные пожертвования всегда приветствуются :)

Чтоб запретить комментарии в определенном типе топика — такого в движке нет. Только автор топика (или админ) может запретить комментарии к конкретному топику.

Есть и другой вариант: можно создать свой тип блога и в нем запретить комментарии всем, кроме владельца блога. При желании можно определенный тип топика привязать к этому типу блога.

Других вариантов чисто настройками без программирования нет

Ничего специально настраивать для мобильного не надо, админка либо работает (если все установлено верно), либо нет, если что-то настроено криво. Напр., с завидной регулярностью люди косячат с .htaccess — или вообще его не заливают на хост, или вносят правки, которые ломают работу.

Но что конкретно не так в Вашем случае — издалека не угадаешь

Возможно, Вы не в курсе, но плагины ЛС даже друг с другом не всегда совместимы. И как тут можно гарантировать их совместимость с другим движком?

Тогда зачем его было внедрять…

А за тем, чтобы дать возможность подключать ЛС-плагины к Альто. И для значительной части плагинов это удается сделать без всяких «шаманских плясок с бубном». Все имеющиеся ЛС-плагины на Альто никто не тестировал и не собирается. Если у Вас возникают проблемы с каким-то конкретным плагином — пишите, будем смотреть, разбираться.

Эту версию толком еще не тестировали на установку. Но за багрепорт спасибо

Такое делается без всякого кодирования/программирования/шаманства:
1) Создаете в админке типы контента
2) Создаете там же типы блогов
3) Увязываете типы блогов и типы контента

Например: создаете тип контента «фотоальбом», создаете тип блога «фотоальбомы», и в настроках типа блога указываете, что в него могут быть добавлены только топики типа «фотоальбомы».

Все, теперь если юзер при создании топика выбирает, что он хочет создать фотоальбом, то в списке блогов ему будут видны только те блоги, куда разрешено добавлять фотоальбомы.

В конфиге задать только один язык:

$config['lang']['allow'] = array('ru');

Тогда все настройки мултиязычности игнорируются

В app/config/config.local.php такой возможности нет, там только конфиг базы данных и все.

В него добавляете любые строки из common/config/config.php и меняете, как нужно

А где можно посмотреть error.log?

/_tmp/logs/error.log

Наверняка не установлен ни один из графических пакетов — ни GD, ни Imagick

Легко!

Например, есть тип топика 'company'. Тогда в папке шаблона создаете такие файлы:

/tpls/topics/topic.type_company-edit.tpl — шаблон для редактирования топика типа company
/tpls/topics/topic.type_company-list.tpl — вид топика при отображении его в ленте
/tpls/topics/topic.type_company-show.tpl — вид топика типа company при его просмотре

Не совсем так. Есть нюанс — если js-код отформатирован так, что после открывающих фигурных скобок "{" идет перевод строки или пробел — тогда не обязательно. Но код счетчиков часто вообще в одну строку форматируют, убирая все лишние пробелы и проч., поэтому я б рекомендовал для счетчиков оборачивание в {literal}. Особенно для тех, кто не особо разбирается в js-коде

Возможно, шаблоны по каким-то причинам не перекомпилируются, сбросьте кеш в админке или почистите папку /_tmp/templates

Все понятно, и все реализуемо довольно просто за исключением одного нюанса: короткие линки.

Простой пример: altocms.ru/super — это профиль (altocms.ru/profile/super), блог (altocms.ru/blog/super), страница (altocms.ru/page/super) или вообще линк какого-то плагина, который на этой странице выводит что-то свое?

Тема с короткими УРЛами время от время поднимается, и она не умрет, пока не будет найдено какое-то внятное решение, только вот универсального решения я лично пока не вижу.

Есть один вариант, который подумываю реализовать в виде плагина (не в коробке), назовем его URL Aliases: Создается отдельная таблица, куда будут вбиваться алисасы УРЛов и их оригинальные адреса, напр.:
* avadim -> profile/avadim
* dev -> blog/dev
* special -> page/special

И в роутере, когда идет определение экшена, сначала сверять запрос по этой таблице, а потом уже определять, какой экшен надо вызывать.

Плюсы такого решения — можно создавать какие угодно адреса с любыми переадресациями. Особенно удобно будет при переезде с других движков — можно будет сохранить нетронутыми все проиндексированные УРЛы. Легко реализуется идея с короткими линками, предложенная выше.

Минусы:
* +1 запрос к базе (увеличение нагрузки)
* уменьшается УРЛов (по виду непонятно, что это, пока не кликнешь)
* возникает неоднозначность — не каждый юзер въедет, почему при попытке создать именованный профиль «super», он получает отказ, хотя такого профиля нет (а зато есть блог «super»)
* есть вероятность конфликта со сторонними плагинами — если я активирую плагин с экшеном ActionSuper, а в системе уже есть блог «super» с коротким линком, то получим конфликт УРЛов — плагин никогда не будет отрабатывать.

В общем, не все так однозначно. Кстати, если внимательно посмотреть на большие соцсети (ФБ, ВК, Г+), то можно увидеть, что короткие линки они дают только на проили, а на посты, альбомы, комменты — там везде специфические линки, которые никто укорачивать особо не стремиться.

Да я и не пробовал угадать, я просто спросил :)

Тут подход такой — статьи (топики, посты — как угодно можно назвать) публикуются в блогах (разделах, секциях — опять же, назвать это можно как угодно). Если разбивки такой не надо, если нужно все публикации в одну ленту сливать, то в админке отключаются все типы блогов, кроме открытого, у него задаются права (как минимум, возможность создания блога оставляется только админу), и админ сайта этот самый один-единственный блог создает. И все — все публикации будут только туда уходить.

я не думаю что Альто как блогосоциальной системе, стоит ориентироваться на пользователей которым не нужны блоги и социальные фишки

Но мне и правда интересны потребности юзера, который в силу каких-то причин заинтересовался Альто, но которому не нужны ни социальные фишки, и ни блоги. Что тогда?

Вот некоторые идеи, которые хотелось бы видеть в Альто:
— автоматическое присвоение ID пользователя при регистрации

Но ведь ID и так есть. Имеется ввиду регистрация без указания логина? Или что-то иное?

В админке — необходимый и наиболее востребованный минимум. Значительно бОльшая часть настроек доступна в конфиг-файле. Раздел помощи действительно скудненький, скуднее некуда, это верно.

Но не очень понятно, что Вы хотите получить в итоге? Сайт с одним юзером-владельцем, содержащий только статические страницы? Или что? Вопрос не риторический, мне и правда это интересно, чтобы понимать, чего ждут люди от движка. Поэтому буду благодарен за развернутый ответ.