«Все новые» подразумевает, что есть еще и старые где-то, которые не охвачены этой выборкой

Нет, это означает, что выводится вообще всё от новых к старым. Ссылка «Новые» за 24 часа со ссылкой /index/new, которые в меню experience я у себя сразу отключил, вернув классическую выборку newall. Я это сделал, потому что newall это единственный список, где можно увидеть действительно все статьи сайта. Альтернатив этому списку нет.
При использовании new, те посты, которые старее 24 часов, не отправленые админом на главную, просто скрываются от глаз юзеров. А если использовать newall, то необходимость в new вообще отпадает.

Добавить файл engine/config.defines.php такого содержания:

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

define('DEBUG', 1);

Почему не defined('DEBUG') or define('DEBUG', 1);?

нужно добавить в конфиг-файл app/config/config.local.php такую строку:

Можно автоматом включать, если включен дебаг.

а краткого текста статьи не будет!

Как это не будет, если он выведется в {$oTopic->getTextShort()}?

Желаемого результата (установка и применение правил $root$ через WritePluginConfig) смог добиться только после отключения плагина «Multiple File Upload». После повторной активации плагина, ничего не сломалось и продолжило нормально работать, хм.

Не, вообще отбирать возможность вставлять картинки в текст это чересчур. Достаточно как-то объяснить юзерам, что устанавливать главную картинку топика нужно через фотосет. Ну и доставать главную фотку фотосета в шаблоне топика выводить в нужно месте.
Пример:
в файле tpls/topics/topic.type_default-list.tpl, в нужном месте вставляем:

{$sImagePath=$oTopic->getPhotosetMainPhotoUrl(false, '682pad')}
{if $sImagePath}
    <img src="{$sImagePath}" alt="image" align="left"/>
    
{/if}

В экшне плагина в админке записывается, а в конфиге плагина выводится

$aConfigWebpaths = Config::ReadPluginConfig('feedback');
var_dump(Config::Get('router.uri'), $aConfigWebpaths);

Внутри aConfigWebpaths:

array(1) {
  ["_db_"]=>
  bool(false)
}

И ещё перестали сохраняться какие-либо настройки в админке, ошибок в логах нет

Спасибо, это как раз то, что надо.
Я попробовал сделать так, как в последнем примере:

Config::WritePluginConfig($sPluginName, [Config::KEY_ROOT => [
    "router.uri" => [
        "[~^admin/about$~iu]"] => "feedback/1"
    ]
]);

Затем читаю:

Config::ReadPluginConfig($sPluginName);
/* Возвращает:
array(1) {
  ["$root$"]=>
  array(1) {
    ["router.uri"]=>
    array(1) {
      ["[~^admin/about$~iu]"]=>
      string(10) "feedback/1"
    }
  }
}
*/

Затем вывожу Config::Get('router.uri'), но в нём нет нашего элемента.

Ну ок, с этим понятно. Но проблема с полной очисткой конфига при очистке ключа (Config::ResetPluginConfig($sPluginName, 'webpaths')) это всё же проблема или нет? Я так понимаю, что там удаляется весь общий файл кеша, но почему-то не генерируется новый.

Ну да. Админ на специальной странице назначил в нашем плагине веб-путь для сущности. Он где-то сохраняется. Затем, при загрузке модуля, в конфиге, подгружается список этих веб-путей, по ним гененируются регулярки для router.uri вида ['[~^foo/bar$~]' => 'myaction/42', …], где в myaction есть ивент, который работает уже с идентификаторами урлов (42). Вот так это должно было работать по задумке.

Так, до сего момента я делал на 1.1.10, смержил 1.1.12, и словил фатальную ошибку при попытке вызвать Config::ReadPluginConfig из конфига плагина:
Fatal error: Class 'E' not found in /var/www/altocms/engine/classes/core/Config.class.php on line 991
Видимо, теперь этот способ не подходит.

Окей, допустим это поведение нормальное. Тогда используя Config::ResetPluginConfig($sPluginName, 'webpaths'); можно очистить ['webpaths' => ['foo']] и записать ['webpaths' => ['bar']].
Но тогда сбрасываются вообще все (!) настройки, сделанные в админке. При этом, опять же, в `storage` всё на месте.

Что вообще делаю:
1. Config::WritePluginConfig($sPluginName, ['webpaths' => ['foo']]);
2. Config::ReadPluginConfig($sPluginName, 'webpaths'); // [0 => foo]
3. Config::WritePluginConfig($sPluginName, ['webpaths' => ['bar']]);
4. Config::ReadPluginConfig($sPluginName, 'webpaths'); // [0 => foo, 1 => bar]

Если честно, результаты выглядят для меня странно. Я записываю в конфиг массив, ожидаю прочитать тот же массив, однако, получаю старый массив + новые только что записанные данные. WTF? Так и должно быть? Я смотрю с БД storage, там сериализованнные данные корректно сохраняются. Видимо, старый мусор добавляется в кеш и читается оттуда.

Вижу ReadPluginConfig/WritePluginConfig. Спасибо, посмотрю.

Ничего не понял. Переход откуда куда и где появляется «ай-пи»?

Рекапча включается на странице плагинов (/admin/site-plugins/). Не забудь прописать ключи рекапчи в конфиге плагина.

А каков итог? Сделали демо-сайт или нет?

Ну, в общем, ищется человек, который этим займётся? Я считаю, это может быть кто угодно, кроме aVadim.
Нужно разработать ТЗ для плагина сбора средств по принципу «кикстартера». Продумать всякие мелочи, типа на какой лицензии будут распространяться плагины и прочее.

пригодится, если еще будет понятно, где эта $sAction доступна. Во всех шаблонах?