… но это скорее проблемы

Я бы так сказал: пункты 1 и 2 — это, скорее, предложения, а п.3 — проблема.

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

Например, по п.1: есть мнение, что невозможность удалить собственный коммент заставляет юзеров чуть больше задумываться о том, чего они пишут в комментах. И, кстати, если юзер не может удалить коммент, как таковой, то может его отредактировать, если это разрешено в конфиге сайта. И даже если он полностью удалит контент, то все равно тот факт, что юзер часто за собой подчищает комменты уже что-то о нем говорит.

То же касается и п.2: в порыве некорректной дискуссий автор топика может просто поудалять вполне корректные, но неугодные ему комменты, что чаще всего сыграет в минус для общей ситуации в сообществе.

Хотя, в теории, я допускаю, что на каких-то отдельных сайтах в силу их специфики такие фичи могут быть полезны. Поэтому вряд ли это стоит делать прямо «в коробке» по умолчанию, но вполне может быть реализовано плагином.

А вот невозможность исправить даже просто опечатку в опросе, если хоть один юзер уже проголосовал — это, как уже сказал, проблема, согласен.

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

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

В нынешнем виде под 1.0 без допилки однозначно не заведется, т.к. используется синтаксис Альто 1.1. Но лицензия GNU GPL, код открыт, плагин выложен на гитхаб, поэтому, если найдутся желающие, то при портировании под Альто 1.0 особых проблем возникнуть не должно.

А RSS-лента вообще формируется? Можно ведь просто в браузере открыть и посмотреть.

Протестировал на демо-сайте: demo.altocms.com/new/blog/test/
Проблема не воспроизводится

Это не косяк, а фича — давно уже набор допустимых символов в логине настраивается в конфиге:

// Только цифры, латиница, подчеркивание и дефис
$config['module']['user']['login']['charset'] = '0-9a-z_\-';
// Цифры, латиница, подчеркивание, дефис и кириллица
$config['module']['user']['login']['charset'] = '0-9a-z_\-а-яё';
// Любые символы
$config['module']['user']['login']['charset'] = '\p{L}';

Или речь о чем-то ином?

fix: github.com/altocms/altocms/commit/5e446295ac40ffa6180f7ab8afaaf9baea7e978f

Спасибо, добавил в текст об этом

Вот тут об этом говорится: altocms.ru/976.html#h2

Но если кратко — получаем синтаксис интуитивно более понятный (в первую очередь для тех, кто впервые знакомится с движком), более правильный с точки зрения семантики (все-таки через $this по всем канонам ООП должно быть обращение к методам текущего объекта), и плюс это дает возможность легко настроить автокомплит методов в IDE.

Нужно придерживать какого-то одного подхода — либо по старой схеме подключать, либо по новой. Замените везде в конфиг-файлах:

$config['head']['default']['js'] — на $config['assets']['default']['js']
$config['head']['default']['css'] — на $config['assets']['default']['css']

и все будет хорошо

Да, конфиг-секция head.default переехала в assets.default, и вынесена вообще в отдельный файл common/config/assets.php (что, на мой взгляд, логично, ибо файл этот давно есть, а определения ассетов по старинке в основном конфиг-файле болтались).

Соответственно, если ассеты переопределяются для шаблона, то лучше их тоже вынести в отдельный файл, как, например, сделано здесь: common/templates/skin/experience/settings/config/assets.php (ассеты для шаблона experience).

НО! Если вы, как и раньше, определите конфиг-секцию head.default, то она точно также будет подхватываться движком и обрабатываться. Т.е. в этом плане обратная совместимость соблюдается.

Так что я не вполне понял, в чем суть проблемы.

О проблеме знаю, но еще не смотрел внимательно

Во-первых, Config::Set() — это все же вызов метода (а если быть точнее, то там целая цепочка методов вызывается).

Во-вторых, при вызове Config::Set() сбрасывается внутренний кеш конфига.

Вот по этим двум причинам первый вариант будет экономить доли секунды. Оно, вроде, экономия на спичках, конечно, но все ж если много плагинов и в конфиге каждого будет Config::Set(), то «спичка к спичке — коробок наберется» :) Говоря о предпочтительности, я именно это имел ввиду. А результат в обоих случаях будет одинаковый.

Не совсем понятен вопрос. Вообще-то такая конструкция вполне себе работает:

Config::Set('router.page.estheme', 'PluginEstheme_ActionEstheme');

Либо для конфига плагина можно и так (и это даже предпочтительней):

$config['$root$']['router']['page']['estheme']

Но в Альто есть еще и такая фишка:

// Автоопределение роутинга экшенов
$config['router']['config']['autodefine'] = true;

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

Только при чем тут админка? Этого я не понял

Настроил сейчас на демосайте: demo.altocms.com/new/blog/test/26/ — работает без проблем. Возможно, какой-то из плагинов дает такой эффект. Либо проблема в настройках сервера. Больше что-то идей нет

Для версии ниже 1.1 такой код должен работать:

{if E::ActivePlugin('agent') AND E::Agent_GetAgent()->isComputer()}
  <!-- Плагин активен и определяем, что пользователь зашел на сайт с компьютера -->
  <!-- Значит ему можно показать слайдер с большими баннерами -->
  <div id="big-slider">
      <!-- здесь код слайдера -->
  </div>
{/if}

Вообще-то вся концепция движка строится на том, что вебмастер не должен ничего менять в самом движке, а весь доп.функционал будут делать через расширения. И при таком подходе все обновления в рамках минорной версии 1.1.х могут выполняться просто обновлением папок /engine и /common.

Если же вебмастер что-то меняет в движке, то это означает одно из трех:
1) Он не понимает, как создавать расширения
2) Он ленится создавать расширения (а исправить прямо в коде действительно получается часто быстрее, чем создать плагин)
3) В движке есть какие-то узкие места, которые не позволяют создать нормальное расширение.

И мне, вообще-то, хотелось бы понимать в каждом конкретном случае корень проблемы.

А что касается патчей — а в каком виде их делать? Если в формате гита, то проще клонировать репо и мерджить коммиты. Или какой-то иной вариант предлагается?

Работаем, да: altocms.ru/1232.html#comment22843

Главным образом, это фиксы найденных ошибок. Плюс некоторые обновления, связанные с оптимизацией и небольшими улучшениями

Вся соль в том, что используется не «переименовывание», а реврайтинг. Ведь на самом деле управление передается тому же самому контроллеру, что и раньше. Только раньше контроллер определялся автоматически, т.к. он совпадал с URL:

site.com/blogs -> ActionBlogs

А сейчас вы хотите другой URL перенаправить на тот же обработчик:

site.com/community -> site.com/blogs -> ActionBlogs

Вот и надо в конфиге прописать, чтобы запрос community отправлялся туда же, куда обычно отправляется запрос blogs.

Сравните мой код и Ваш, и поймите разницу. Если Вы хоть когда-нибудь писали правила для .htaccess, то все должно быть очевидным