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

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

Поэтому есть предложение упростить этот процесс, к тому же первый шаг в сторону более дружелюбного способа и соответствующего интерфейса уже сделан.
Концепция
Путем объединения всех файлов оформления одного типа в единый файл получить на выходе связку html + css (+js) с структурной разбивкой ( кодом для парсинга а заодно и человеко-понятным описанием принадлежности к элементу движка). То есть получить максимально приближенный к простому виду и автоматически откомментированный единый шаблон, содержащий элементы оформления всех подключенных элементов (шестеренки, модули и т.п. ). И чтобы уже в этом шаблоне править взаиморасположение элементов и их оформление.
В таком виде оформленный, готовый шаблон затем в обратном порядке, на основе кода парсинга, разбирается на составляющие файлы оформления компонентов движка, которые соответственно прописываются в нужные места.

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

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

Несколько технических моментов
Должна быть возможность выборочного вывода в общий шаблон оформления конкретных элементов, чтобы сформировать шаблон только из необходимых. Причем не только из подключенных компонентов, но также и из неактивных. Это позволит предварительно оценить интегрируемость новых в общий дизайн и при необходимости откорректировать взаимодействие.
Будет удобно логическое объединение компонентов в группы для вывода, на основе структуры интерфейса. Например: при подключении расширяющего функционал элемента (допустим он сложный и имеет собственное оформление) для уже используемого блока «инфо», не приходилось бы добавлять в выборку этот элемент отдельно, а достаточно было указать вывести все элементы входящие в блок «инфо».

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

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

Сложный вопрос, для отдельного обсуждения:
Должна быть проработана система взаимной интерпретации — из шаблона во внутренний файл оформления и наоборот. Основные нюансы, на мой взгляд, следующие:
— Код в шаблоне не должен включать логику, а только соответствующий месту структурный элемент: html каркас вывода — для отладки оформления, и, при необходимости, спец «заглушки» — для замещения сложного вывода или использования некоторых возможностей движка.
— Код внутреннего файла оформления может быть значительно сложнее, за счет включения логики и собственного программного взаимодействия с движком. Здесь может применяться уже существующий внутренний шаблонизатор, и дополнительно особая разметка элементов для взаимодействия с шаблоном оформления ( вывод в шаблон /замещение импортом из шаблона ).

Из нюансов пока все, это навскидку.
Вообще же тема сложная, нужна серьезная проработка.

Что было бы полезно сейчас, уже в этой версии.
Может, стоило это оформить отдельной темой.

Предложение довольно топорное и примитивное.

(Можно было бы объединить все ниже перечисленное в некий design-debug режим, добавить в админке опцию его включения.)

С tpl сложно, предложу вот что.
Добавить внутрь каждого tpl префикс и постфикс примерно так ( это в основном, в некоторых расположение придется немного уточнить ):
<!-- start filename.tpl --> содержимое файла .tpl <!-- end filename.tpl --> Уже поможет быстро сориентироваться по коду готовой страницы, где править.

С css проще. Нужно собрать все файлы в один, отделив каждый префиксом с путем и именем файла ( а, может, + постфиксом), для обратного парсера, и вывести в таком виде эту сборку, прямо в качестве рабочего активного css(это пока design-debug режим включен), или, если по другому пока никак, хотя-бы, в отдельный файл( для отладки оформления его всегда можно подключить). Главное чтобы была возможность распарсить обратно в файлы.

/* cogear:css:path:"gears/gear1.css" */ h1{ font-size: 1.4em; } /* cogear:css:end */ - это если нужен постфикс /* cogear:css:path:"gears/gear2.css" */ h2{ font-size: 1.2em; } /* cogear:css:end */ как-то так, логика такая.

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

В итоге будет попроще с оформлением, порог вхождения будет ниже.

…

Пока собственно все, что хотелось предложить по теме оформления.
Надеюсь эта заметка пригодится.