[dev] Конфигурация сайта на Alto CMS - некоторые нюансы и особенности

Это очередная статься для разработчиков, которые хотели бы досконально разобраться во всех нюансах работы Alto CMS. И сегодня речь – о том, как устроен и работает конфигуратор. Статья рассчитана на читателей, которые уже имеют представление о том, как конфигурируется движок, но хотели бы заглянуть «под капот». Поэтому я не буду рассказывать здесь про структуру конфиг-файлов вообще или про то, что делают вызовы Config::Get() и Config::Set(), предполагая, что читатель и так это знает, а перейду сразу к сути статьи.
С чего начинается конфиг
Загрузка всего приложения начинается с «предзагрузчика», который обычно находится по адресу /engine/loader.php (при желании его можно и в другое место положить, но для этого придется уже корневой файл index.php править).

В той же папке с предзагрузчиком лежит самый первый подключаемый конфигурационный файл config.php, в котором определяются самые важные пути для загрузки компонентов движка:
$config['path']['dir']['engine'] = __DIR__;           // Путь к папке движка
$config['path']['dir']['libs']   = ALTO_DIR . '/engine/libs/';   // Путь к библиотекам движка 
$config['path']['dir']['common'] = ALTO_DIR . '/common/';        // Путь к общим компонентам 
$config['path']['dir']['config'] = ALTO_DIR . '/common/config/'; // Путь к папке конфигурации 
$config['path']['dir']['app']    = ALTO_DIR . '/app/';           // Путь к папке приложения 
Здесь хочу акцентировать внимание на том, как именуются конфиг-параметры: настоятельно рекомендуется во всех дисковых путях использовать подключ 'dir', а во всех веб-путях использовать подключ 'url'. Например:
$config['path']['static']['url'] = '___path.root.url___'; // Полный URL до static-сервера
$config['path']['static']['dir'] = '___path.root.dir___'; // Полный путь до static-сервера в файловой системе
При таком подходе, встретив в коде вызов Config::Get('path.static.dir'), сразу ясно, о каком пути идет речь.

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

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

Шесть уровней конфига
Во-первых, предусмотрено аж шесть уровней конфигурации. Эти уровни накладываются один на другой, как в слоеном пироге. Вот они, от низшего к высшему:
  1. Основной (базовый) уровень (LEVEL_MAIN) – это то, что задано в папках /common/config и /common/config/modules/, т.е. это основной конфигуратор движка.
  2. Уровень приложения (LEVEL_APP) – это конфигурации, заданные в файлах, лежащих в /app/config и /app/config/modules/. Именно здесь (и только здесь) нужно менять параметры конфигурации своего сайта, если это делается вручную.
  3. Пользовательский уровень (LEVEL_CUSTOM) – конфигурации, заданные через админку, тут, думаю, все ясно.
  4. Уровень контроллера (LEVEL_ACTION) – да, в Альто можно задавать конфигурации аж для каждого экшена. Они последовательно берутся из файлов /common/config/actions/имя_экшена.php и /app/config/actions/имя_экшена.php. Например, для экшена admin задается свой собственный скин.
  5. Уровень скина (LEVEL_SKIN) – конфигурации используемого скина
  6. Пользовательский уровень скина (LEVEL_SKIN_CUSTOM) – этот уровень пока не используется, но можно догадаться, для чего его можно будет задействовать в будущем.
По умолчанию все операции Config::Get() и Config::Set() производятся с текущим уровнем. Но, при желании, всегда можно получить (и установить) конфиг-параметры для конкретного уровня.

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

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

В основном конфиг-файле есть такой параметр:
$config['config_load'] = array(
    'assets',       // Наборы подключаемых css- и js-файлов
    'classes',      // Определения классов
    'jevix',        // Настройки типографа текста Jevix
    'widgets',      // Виджеты
);
При конфигурировании приложения загрузчик получает параметр Config::Get('config_load') и перебирает значения из полученного массива. Если есть файл assets.php, то он загружается в секцию конфига assets. И в дальнейшем мы можем получить набор конфигурации вызовом Config::Get('assets'). То же самое касается и остальных значений – classes, jevix и т.д.

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

Похожие статьи

  • [dev] Конфигурация сайта на Alto CMS - Определяем IP-адрес пользователя
    В теории определение адреса посетителя – элементарная операция. Он, согласно соглашениям, должен лежать в переменной $_SERVER['REMOTE_ADDR']. Но суровая правда жизни нередко идет в разрез с теорией, поэтому на...
  • AltoWiki — новый раздел сайта
    Вообще-то раздел AltoWiki появился не сегодня. Но до недавнего времени он был в процессе отладки и доработки — что-то допиливалось, что-то корректировалось. Но вот сейчас, полагаю, можно о нем уже рассказать, как о...
  • [dev] Кеширование данных
    Эта статья рассчитана не просто на сайтостроителей, а на разработчиков, и рассказывает о том, как в Alto CMS устроена система кеширования данных, которая может весьма гибко настраиваться и использовать для хранения...
  • настройки движка сбрасываются на стандартные
    По какой-то причине, настройки движка сбрасываются на стандартные… К примеру после добавления скрипта счетчика… Полностью сбрасывает на дефолт… Но не всегда, не могу точно понять при каких обстоятельствах…

21 комментарий

0
Ох не знаю, ребят… Наверное это очень круто. Но мне кажется сейчас для альто нужны совсем другие статьи. Например об отсутствии некоторых функций (часто очень важных) мы узнаем от других пользователей, а не от разработчиков, например altocms.ru/blog/dev/454.html#comment7282

Шаблоны выпиливаются из коробки (а некоторые проекты делали с использованием шаблонов, которые просто выкинули из движка), основного до сих пор нет и каким он будет не ясно…

В итоге мы идем в версии 1.0 не к CMS с базовым функционалом без необходимости использования большого количества плагинов, а к фреймворку для разработчиков.
+2
Но мне кажется сейчас для альто нужны совсем другие статьи
Задавайте темы — попробуем написать

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

Первая реализация дефолтного шаблона оказалась очень неудачной, поэтому его убрали, чтоб зря не смущать. Все бесплатные шаблоны, что были до этого, останутся и будут подвергнуты ревизии и, при необходимости, корректировке, чтоб максимально плотно сели на версию 1.0
0
Не рассматривали ли фичи используемые в Padrino, например такие как апдейты патчами с хранением истории? Это весьма удобная фича, которой пока обладает единственный MVC и тот на ruby :) Очень шустро можно управлять версионированием и откатами в случае чего. Коммулятивки собирать — просто рай.
Отредактирован:
0
Задавайте темы — попробуем написать
Ок
Все бесплатные шаблоны, что были до этого, останутся и будут подвергнуты ревизии и, при необходимости, корректировке, чтоб максимально плотно сели на версию 1.0
Всегда было интересно, чем обусловлено использование synio, а не свободного и адаптивного девелопера из той же коробки ls?
0
Возможно, я чего-то упускаю из вида (тогда поправьте), но ни один бесплатный ЛС-шаблн не являются на 100% свободным, и девелопер — не исключение. Поэтому проблему решит только разработка своего шаблона
0
1) Могу ли я продавать шаблон, за основу которого был взять Synio который не является моей разработкой?
Вы можете сделать бесплатный шаблон на основе Synio.
2) Могу ли я убрать копирайт разработчика Synio, если шаблон притерпит большие изменения?
В копирайте лучше всего указать двух авторов (сохранив xeoart.ru)
3) На основе какого шаблона можно создать свой?
На основе developer (входит в стандартную поставку ЛС) можно делать как платные так и бесплатные шаблоны, копирайт можно убрать.

livestreet.ru/blog/sollutions/11533.html

Таким образом developer полностью свободный, в отличии от того же synio, который не только несет дополнительную ссылку, но еще и связывает руки для создания платных шаблонов разработчикам.
+1
Хм, ну вот все в ЛС так через… пардон. Я допускаю, что PSNet, который какбэ официально никакого отношения не имеет ни к ЛС, ни к разработчикам шаблонов, тем не менее обладает некоей информацией, которой не обладают другие. Но воспринимать его слова типа «там лучше сделать так, а тут можно сделать эдак» как официальную позицию я не могу никак.

А в сухом остатке имеем: и шаблон Synio по умолчанию имеет ссылку на разработчика шаблона, и шаблон developer. И все другие бесплатные шаблоны. Где-то явно указана лицензия (например, в developer-kit), а где-то нет. И если относительно копирайтов непосредственно по коду у меня сложилось определенное мнение, то по шаблонам пока нет. Но, возможно, где-то Вы и правы. В общем, будем думать…
0
Это официальная позиция администрации и разработчиков, т.к ссылка на этот faq идет из главного меню сайта livestreet.ru («Новичкам» выделено красным). А вот за чьим авторством статья, дело десятое и думаю вы согласитесь, что даже если бы автором был любой другой пользователь — это не имело бы абсолютно никакого значения.

Если вы все еще сомневаетесь, могу сделать топик официальный запрос на livestreet.ru

Synio не просто имеет ссылку, которая паровозом заставляет тянуть ее на всех проектах альто с шаблоном из коробки, но и не дает свободы действия по разработке своего шаблона на его основе. В противовес ему developer при небольших правках стилей и кода можно превратить в замечательный свободный шаблон.
0
Угрожающе звучит, но доля правды в этом есть.
Я считаю, что разработчикам Альто вообще стоит закрыть глаза на LS и забыть о его существование.
Нужно двигаться своим путем и своими четко спланированными планами.
Если этого не сделать на начальных этапах, то все превратиться в кашу, а мы и дальше будим видеть срач кто и что у кого позаимствовал.
Конечному юзеру далеко до лампочки чия машинка, на чьей основана ему главное, что бы она работала лучше, чем это есть у аналога.
Мне честно оч. хочется верить в успех Альто, но с другой стороны я вижу, как Альто движется в тоже русло фреймфорка, но только с меньше пользовательской базой.
Пока сложно настроить клиента на выбор в качестве основы Альто с одной стороны, а с другой сложность возникает в отсутствие элементов, которые можно взять за основу и не бояться на следующей день получить письмо с пометкой на права.
Я могу ошибаться, но это чисто мои ощущения.
+2
Вот ты привязался :) Пусть движется… Вадим все правильно делает…
Покопал я тот LS… Он мне «китайский базар» напоминает… и Ви таки смели сказать, что с ним конкурировать не надо? Да этот набор костылей сам потонет… со временем…

Вадим не слушай никого. Все правильно делаешь…
комментарий был удален
комментарий был удален
0
Флейм удаляю
+2
Так это же хорошо, что «не уходят далеко от фреймворка»… MVC хорошая еще никому не вредила. Зачем еще одна джумла на этом свете? Баги плодить?
Отредактирован:
+1
А почему у людей CMS ассоциируется только с какой-то джумла и подобным хламом?
Так это же хорошо, что «не уходят далеко от фреймворка»
И конкурировать с ЛС? — смысл?
0
Потому-что контент-менеджмент системы устарели и по сути и есть хлам. Куда круче многоуровненвые системы: фреймфорк + гуевый конструктор + шаблоны. В первую очередь надо развивать фреймворк и конструктор, а уж в качестве: «зацените шо оно умеет» — какой-нить шаблон или десяток таковых
0
Конечно круче, но конкурировать в этом сегменте с livestreet или например с таким монстром как drupal вряд ли получится. Важно сразу рассчитать силы и определить свою нишу.

Фреймворки уже есть и достаточно неплохие, а на отвоевывание доли рынка может потребоваться большое количество времени и сил, без каких либо гарантий на успех.
+1
Алена, никто ни ЛС ни друпал не собирается конкурировать. Мне так кажется :)Специально конкурировать.
Гарантий на успех и вовсе ни у кого нет.
Но и затевая дело ставку на провал не делают.
+2
Да не нужно конкурировать ни с кем, нужно просто делать. Делать то, сего хочется а его нет, делать то что вопреки… А бизнес и девелоперы сами потом решат… И эта фича с конфигурированием весьма и весьма айс, как и с многоуровневостью и зарезервированными возможностями расширения. Вы же понимаете, что это позволит избежать прикручивания костылей в будущем?

И потом: рынок ПО всегда сегментирован. И разрабы разные бывают и системы ки и прикладной уровень и дизайн. Каждому свой хлеб ;)
0
Скажите это вордпрессу :)
+1
Вордпресс… нормальный, для некоторых задач. Но речь, в общем, не о нем.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.