Поддержка тем в CodeIgniter

Владимир | | CodeIgniter, PHP, Web разработка.

codeigniter themes

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

Примечание. Если вы не знакомы с этим фреймворком, то сначала вам стоит почитать статью «Как создать свой сайт на PHP? Или зачем нужны фреймворки?».

Прежде всего, сформулируем задачу:

1) контроллер должен оставаться неизменным при использовании любой из тем;

2) файлы тем должны находится в отдельных папках;

3) минимальная нагрузка на систему (т.е. шаблонизаторы и дополнительные библиотеки не используем).

В принципе, поддержка тем изначально заложена в CodeIgniter. Если придерживаться архитектуры MVC, то весь код, связанный с отображением страниц, будет находиться в представлениях, а работа с данными и обработка запросов пользователя – в моделях и контроллере.

Отсюда вытекает простейший вариант решения задачи. Если в папке view создать несколько вложенных папок (theme1, theme2, …) и разместить в них представления, то нам останется только управлять их загрузкой из контроллера.

Рассмотрим конкретный пример.

Допустим, у нас есть 4 представления: header.php, content.php, sidebar.php и footer.php. Кроме того, каждая тема должна иметь свою таблицу стилей styles.css.

Папка view содержит две темы (default и classic) и имеет такую структуру:

view/
	default/
		header.php
		content.php
		sidebar.php
		footer.php
		styles.css
	classic/
		header.php
		content.php
		sidebar.php
		footer.php
		styles.css

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

Создаем файл application/config/themes.php, и сохраняем в нем название выбранной темы.

<?php
if ( ! defined('BASEPATH')) exit('No direct script access allowed');
$config['current_theme'] = 'classic';
?>

Теперь рассмотрим контроллер:

class Main extends Controller {
	
	private $curTheme = 'default';

	function Main() {
		parent::Controller();
		$this->load->helper('html');
		$this->config->load('themes');
		$this->curTheme = $this->config->item('current_theme');
	}

	function index() {
		$pageData['title'] = "Использование тем в CodeIgniter";
		$pageData['theme'] = $this->curTheme;
		$pageData['contentTitle'] = "Это заголовок";
		$pageData['contentData'] = "Тут должен находится текст статьи с".
			"картинками, комментариями и т.п. В общем, все, что хотите....";
		$pageData['sidebarTitle'] = "Рубрики";
		$pageData['sidebarData'] = array('PHP', 'CSS', 'HTML', 'JavaScript');
		$this->load->view($this->curTheme.'/header', $pageData);
		$this->load->view($this->curTheme.'/content');
		$this->load->view($this->curTheme.'/sidebar');
		$this->load->view($this->curTheme.'/footer');
	}
}

В конструкторе контроллера мы загружаем конфигурационный файл (строка 8 ) и читаем параметр current_theme (строка 9).

В методе index мы добавляем к названию представления имя папки с активной темой (строки 20-23). И, кроме того, сохраняем название темы в массиве $pageData (строка 14). Дело в том, что файл header.php содержит заголовок страницы, в котором подключается таблица стилей. Т.к. каждая тема имеет свой css файл нам нужно правильно сформировать путь к нему.

<link href="<?php echo $this->config->system_url(); ?>application/views/<?php echo $theme; ?>/styles.css" rel="stylesheet" type="text/css" media="all" />

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

Здесь я приведу только два скриншота для обоих тем.

Тема classic

codeigniter themes classic

Тема default

codeigniter themes default

Как видите, они отличаются только размещением колонок. Содержимое страниц одинаково (если не считать текста с названием темы).

Попробуем немного усовершенствовать код.

Уберем из контроллера код, выполняющий загрузку представлений. Для этого напишем небольшой хелпер (helper).

Создаем файл application/helpers/theme_helper.php со следующим содержимым:

<?php
function createPage($pageData) {
	$CI = & get_instance();
	$curTheme = $CI->config->item('current_theme');
	$pageData['theme'] = $curTheme;
	$CI->load->view($curTheme.'/header', $pageData);
	$CI->load->view($curTheme.'/content');
	$CI->load->view($curTheme.'/sidebar');
	$CI->load->view($curTheme.'/footer');
}
?>

Как видите, мы написали всего одну функцию, которая просто читает параметр current_theme и загружает представления.

Обратите внимание на использование функции get_instance() она позволяет получить доступ к объекту CodeIgniter (в контроллерах и моделях вместо нее используется $this).

Теперь код контроллера можно переписать следующим образом:

class Main extends Controller {
	
	function Main() {
		parent::Controller();
		$this->load->helper('html');
		$this->load->helper('themes');
		$this->config->load('themes');
	}

	function index() {
		$pageData['title'] = "Использование тем в CodeIgniter";
		$pageData['contentTitle'] = "Это заголовок";
		$pageData['contentData'] = "Тут должен находится текст статьи с ".
			"картинками, комментариями и т.п. В общем, все, что хотите....";
		$pageData['sidebarTitle'] = "Рубрики";
		$pageData['sidebarData'] = array('PHP', 'CSS', 'HTML', 'JavaScript');
		createPage($pageData);
	}
}

Как видите, работать стало удобнее.

Теперь представим, что наш сайт имеет разную структуру страниц. Например, на главной странице сайдбар отображается, а на других страницах – нет. Кроме того, разработчик темы может захотеть добавить дополнительные представления или изменить их названия.

Очевидно, что функция createPage должна каким-то образом определить, какие представления показывать в каждом конкретном случае.

В этом случае нужно, прежде всего, определиться с типами страниц. В нашем случае они будут называться: main (главная) и page (просто страница).

Теперь добавим несколько параметров в конфигурационный файл.

$config['themes']['default']['main'] = array('header', 'content', 'sidebar', 'footer');
$config['themes']['default']['page'] = array('header', 'content', 'footer');

Как видите, мы создали многомерный массив с настройками. Второй индекс массива указывает названия темы, третий – тип страницы.

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

Примечание. Аналогичные настройки нужно задать для всех тем.

Теперь нужно изменить хелпер.

function createPage($pageData, $pageType) {
	$CI = & get_instance();
	$curTheme = $CI->config->item('current_theme');
	$pageData['theme'] = $curTheme;
	$themeData = $CI->config->item('themes');
	foreach ($themeData[$curTheme][$pageType] as $curView) {
		$CI->load->view($curTheme.'/'.$curView, $pageData);
	}
}

Теперь, мы получаем массив с названиями представлений и загружаем только их. Кроме того, добавился еще один параметр $pageType (тип страницы).

В контроллере мы только добавляем метод page()

function page() {
	$pageData['title'] = "Использование тем в CodeIgniter";
	$pageData['contentTitle'] = "Это заголовок";
	$pageData['contentData'] = "Тут должен находится текст статьи с ".
		"картинками, комментариями и т.п. В общем, все, что хотите....";
	$pageData['sidebarTitle'] = "Рубрики";
	$pageData['sidebarData'] = array('PHP', 'CSS', 'HTML', 'JavaScript');
	createPage($pageData, 'page');
}

Ограничения и область использования такого решения

Если вы внимательно посмотрите на последний блок кода (метод page), то заметите один существенный недостаток (строки 6 и 7).

Дело в том, что в одной теме может использоваться сайдбар, а в другой – нет. Но в контроллере мы в любом случае должны подготовить данные для него. Иначе часть тем просто не будет работать.

Конечно, в данном примере, это всего лишь короткие строки текста, но в реальном приложении эти данные нужно будет получать из базы. А это означает, что для каких-то тем будут выполняться лишние запросы.

Отсюда следует простой вывод: «Такой способ создания тем можно применять только для сайтов с постоянной структурой страниц».

Если вам нужно более гибкое решение – используйте подход, который применяется в большинстве CMS (например, в движке WordPress).

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

Например, в том же WordPress функция get_posts возвращает выбранные записи.

Но, несмотря на гибкость такого подхода у него есть свои недостатки:

1) Система усложняется (оправданно для CMS, но для обычного сайта может быть излишним).

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

3) Разработчик темы может написать далеко не оптимальный код. Например, вызвать несколько раз одну и туже функцию.

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

5) Нарушается архитектура MVC (получение данных выполняется внутри представления). В принципе, это не проблема, т.к. CodeIgniter не накладывает здесь жестких ограничений.

Скачать архивы с примерами

1) Простейший вариант (без хелпера).
2) Тоже самое + хелпер.
3) Вариант с поддержкой индивидуального оформления разных типов страниц.

Во всех архивах находится папка application, которую нужно скопировать в папку system дистрибутива CodeIgniter.

Заключение.

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

Интересно почитать:

Забавный трюк по получению трафика с социалок

  • MAX

    Отличный теоретический материал! 🙂

    А вот с практической точки зрения здесь всё не так просто. Если контролер данные подготавливает всегда, то это накладывает очень жесткие ограничения на файлы шаблона. Данные которые они выводят также будут строго предопределены.

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

    Но вообще такая поддержка шаблонов всё-таки тянет на CMS. CodeIgniter в исходном виде, да еще из-за своей MVC просто не имеет готовых решений. В частности получение данных обязательно должно переноситься во вьювер. (Как у меня.) Ну а это для «фанатов» MVC просто не допустимо. 🙂

    Пример с WordPress не совсем некорректный. Я бы даже сказал, что все как раз наоборот: WordPress вначале получает данные (аналог контролера), а уже потом можно «перебить» их в шаблоне (аналог вьювер). (Если совсем строго, то можно сразу перехватить начальные запросы с помощью плагина и хука на init.) Именно из-за такой архитектуры WordPress столь ресурсоемкий и негибкий.

    Да и еще. На мой взгляд именно такая схема шаблона не очень удачна. Просто из-за фиксированных php-файлов во вьювере теряется смысл шаблонов как таковых. Но, зато можно продумать эти файлы так, чтобы при одной html-разметке можно было бы подключать разные css-файлы. В этом случае достаточно только ввести один параметр — имя css, а разработка самого шаблона по сути сведется к css-верстке. Тогда можно не заботиться о программировании. Из подобных разработок могу упомянуть зен гарден. Да и у любого верстальщика в загашнике всегда есть свои аналогичные решения. 😉

    • жесткие ограничения на файлы шаблона

      Да, это основной недостаток. Но при этом разработчику шаблона не нужно изучать API. Для CMS, однозначно не подходит, но для небольших проектов с фиксированной структурой может иметь смысл.

      для «фанатов» MVC просто не допустимо

      Я не фанат 😉 . И, честно говоря, не знаю примеров CMS, которые сделаны в строгом соответствии с MVC.

      Пример с WordPress не совсем некорректный

      Да подробно разобраться с WP у меня руки не дошли 🙂 . Если я правильно понял, данные, которые возвращают функции с этой страницы http://codex.wordpress.org/Function_Reference движок получает заранее?

      фиксированных php-файлов во вьювере

      Почему фиксированных? Их можно менять. Последний пример в конце статьи, когда имена файлов и их количество задаются в массиве отдельно для каждой темы. Я просто фрагмент настроек привел только для одной темы. Т.е. можно сделать:
      $config['themes']['default']['page'] = array('header', 'content', 'sidebar', 'footer');

      $config['themes']['classic']['page'] = array('header', 'content', 'footer');

      зен гарден

      Идеальный вариант. Очень высокие требования к разметке, но оно того стоит.

      • MAX

        Если я правильно понял, данные, которые возвращают функции с этой страницы http://codex.wordpress.org/Function_Reference движок получает заранее?

        В WordPress есть такой глобавльный объект $wp_query, который вроде аналога $CI. 🙂 И формируется он в момент инициализации системы. То есть вначале роутер смотрит текущий ЧПУ, потом его парсит и уже по нему пытается построить sql-запрос. И при этом сразу же его выполняет.

        Таким образом $wp_query уже заполнен в момент передачи управления шаблону. Потом, если сделать query_posts, то это по сути заставит измениться $wp_query, путем парсинга и модификации последнего sql. То есть получается двойная работа.

        Я просто фрагмент настроек привел только для одной темы. Т.е. можно сделать:

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

        Идеальный вариант. Очень высокие требования к разметке, но оно того стоит.

        Если немного упростить задачу до каких-то типичных структур, вроде две колонки, текст, то все варианты спокойно уложатся в один html. А с помощью CSS, можно уже чудеса творить. 🙂 Но, хотя, конечно же тут требуются хорошие знания CSS.

        • То есть получается двойная работа.

          Да, не самый оптимальный вариант 🙂 . Насколько я понял, в MaxSite CMS объект $MSO вообще не заполняется данными из базы (при инициализации).
          Есть небольшой вопрос. Что будет если два раза вызвать mso_get_pages?

          немного упростить задачу до каких-то типичных структур

          Все равно разметка получится сложной. Например, если не использовать CSS3, то для создания закругленных уголков нужны вложенные div'ы для одного и того же блока. Такие нюансы придется учитывать, иначе количество чудес поубавится 😉

        • MAX

          Насколько я понял, в MaxSite CMS объект $MSO вообще не заполняется данными из базы (при инициализации).

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

          Что будет если два раза вызвать mso_get_pages?

          В зависимости от входных параметров сформируется sql-запрос и он будет выполнен. Дважды.

          Все равно разметка получится сложной. Например, если не использовать CSS3, то для создания закругленных уголков нужны вложенные div'ы для одного и того же блока.

          Не совсем. 🙂 Я все чаще использую плагин к jQuery — Cornerz, который работает с любым браузером и очень неплохо скругляет углы. Я его даже в комплект MaxSite CMS включил. 🙂

        • и он будет выполнен. Дважды

          Почему бы не кэшировать результаты этих запросов? Т.е. при первом обращении к функции запрос выполняется как обычно, а его результат сохраняется в $MSO (или другом глобальном объекте, подойдет обычный массив), при повторном вызове функции будут возвращаться сохраненные данные, а запрос выполняться не будет.
          Получится что-то вроде временного кэша в памяти, который существует только для одного запроса. Своеобразная «защита от дурака».
          Примечание. Это не предложение изменить MaxsiteCMS, скорее просто мысли вслух. В большинстве случаев этот кэш использоваться не будет. А если включено обычное кэширование, то разговаривать вообще не о чем, функция будет вызвана только при обновлении кэша.

          плагин к jQuery

          Zen Garden не использует JS для дизайна 😉

        • MAX

          Не так. $MSO вообще никакого отношения к кэшу не имеет. Если уж и нужно закэшировать SQL-запрос, то с этим пусть справляется $CI. Там вообще его кухня.

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

          Зато спокойно можно использовать кэш в разных функциях. Например вывод последних записей. Один запрос, результат в кэш. Ключ кэша явно определяется, так что проблем нет. У меня практически все сложные функции имеют подобное кэширование и именно по этому такое малое ресурсопотребление.

          Да, и в отличие от WordPress результат не сохраняется в глобальном объекте. Просто нет надобности. 🙂

        • какая-то операция изменила базу

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

          Но, чем больше я думаю на эту тему, тем больше вопросов возникает. В общем, уже сам сомневаюсь, что такое решение будет эффективным 😉
          Нужно будет поэкспериментировать.

  • MAX

    Отличный теоретический материал! 🙂

    А вот с практической точки зрения здесь всё не так просто. Если контролер данные подготавливает всегда, то это накладывает очень жесткие ограничения на файлы шаблона. Данные которые они выводят также будут строго предопределены.

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

    Но вообще такая поддержка шаблонов всё-таки тянет на CMS. CodeIgniter в исходном виде, да еще из-за своей MVC просто не имеет готовых решений. В частности получение данных обязательно должно переноситься во вьювер. (Как у меня.) Ну а это для «фанатов» MVC просто не допустимо. 🙂

    Пример с WordPress не совсем некорректный. Я бы даже сказал, что все как раз наоборот: WordPress вначале получает данные (аналог контролера), а уже потом можно «перебить» их в шаблоне (аналог вьювер). (Если совсем строго, то можно сразу перехватить начальные запросы с помощью плагина и хука на init.) Именно из-за такой архитектуры WordPress столь ресурсоемкий и негибкий.

    Да и еще. На мой взгляд именно такая схема шаблона не очень удачна. Просто из-за фиксированных php-файлов во вьювере теряется смысл шаблонов как таковых. Но, зато можно продумать эти файлы так, чтобы при одной html-разметке можно было бы подключать разные css-файлы. В этом случае достаточно только ввести один параметр — имя css, а разработка самого шаблона по сути сведется к css-верстке. Тогда можно не заботиться о программировании. Из подобных разработок могу упомянуть зен гарден. Да и у любого верстальщика в загашнике всегда есть свои аналогичные решения. 😉

    • жесткие ограничения на файлы шаблона

      Да, это основной недостаток. Но при этом разработчику шаблона не нужно изучать API. Для CMS, однозначно не подходит, но для небольших проектов с фиксированной структурой может иметь смысл.

      для «фанатов» MVC просто не допустимо

      Я не фанат 😉 . И, честно говоря, не знаю примеров CMS, которые сделаны в строгом соответствии с MVC.

      Пример с WordPress не совсем некорректный

      Да подробно разобраться с WP у меня руки не дошли 🙂 . Если я правильно понял, данные, которые возвращают функции с этой страницы http://codex.wordpress.org/Function_Reference движок получает заранее?

      фиксированных php-файлов во вьювере

      Почему фиксированных? Их можно менять. Последний пример в конце статьи, когда имена файлов и их количество задаются в массиве отдельно для каждой темы. Я просто фрагмент настроек привел только для одной темы. Т.е. можно сделать:
      $config['themes']['default']['page'] = array('header', 'content', 'sidebar', 'footer');

      $config['themes']['classic']['page'] = array('header', 'content', 'footer');

      зен гарден

      Идеальный вариант. Очень высокие требования к разметке, но оно того стоит.

      • MAX

        Если я правильно понял, данные, которые возвращают функции с этой страницы http://codex.wordpress.org/Function_Reference движок получает заранее?

        В WordPress есть такой глобавльный объект $wp_query, который вроде аналога $CI. 🙂 И формируется он в момент инициализации системы. То есть вначале роутер смотрит текущий ЧПУ, потом его парсит и уже по нему пытается построить sql-запрос. И при этом сразу же его выполняет.

        Таким образом $wp_query уже заполнен в момент передачи управления шаблону. Потом, если сделать query_posts, то это по сути заставит измениться $wp_query, путем парсинга и модификации последнего sql. То есть получается двойная работа.

        Я просто фрагмент настроек привел только для одной темы. Т.е. можно сделать:

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

        Идеальный вариант. Очень высокие требования к разметке, но оно того стоит.

        Если немного упростить задачу до каких-то типичных структур, вроде две колонки, текст, то все варианты спокойно уложатся в один html. А с помощью CSS, можно уже чудеса творить. 🙂 Но, хотя, конечно же тут требуются хорошие знания CSS.

        • То есть получается двойная работа.

          Да, не самый оптимальный вариант 🙂 . Насколько я понял, в MaxSite CMS объект $MSO вообще не заполняется данными из базы (при инициализации).
          Есть небольшой вопрос. Что будет если два раза вызвать mso_get_pages?

          немного упростить задачу до каких-то типичных структур

          Все равно разметка получится сложной. Например, если не использовать CSS3, то для создания закругленных уголков нужны вложенные div'ы для одного и того же блока. Такие нюансы придется учитывать, иначе количество чудес поубавится 😉

        • MAX

          Насколько я понял, в MaxSite CMS объект $MSO вообще не заполняется данными из базы (при инициализации).

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

          Что будет если два раза вызвать mso_get_pages?

          В зависимости от входных параметров сформируется sql-запрос и он будет выполнен. Дважды.

          Все равно разметка получится сложной. Например, если не использовать CSS3, то для создания закругленных уголков нужны вложенные div'ы для одного и того же блока.

          Не совсем. 🙂 Я все чаще использую плагин к jQuery — Cornerz, который работает с любым браузером и очень неплохо скругляет углы. Я его даже в комплект MaxSite CMS включил. 🙂

        • и он будет выполнен. Дважды

          Почему бы не кэшировать результаты этих запросов? Т.е. при первом обращении к функции запрос выполняется как обычно, а его результат сохраняется в $MSO (или другом глобальном объекте, подойдет обычный массив), при повторном вызове функции будут возвращаться сохраненные данные, а запрос выполняться не будет.
          Получится что-то вроде временного кэша в памяти, который существует только для одного запроса. Своеобразная «защита от дурака».
          Примечание. Это не предложение изменить MaxsiteCMS, скорее просто мысли вслух. В большинстве случаев этот кэш использоваться не будет. А если включено обычное кэширование, то разговаривать вообще не о чем, функция будет вызвана только при обновлении кэша.

          плагин к jQuery

          Zen Garden не использует JS для дизайна 😉

        • MAX

          Не так. $MSO вообще никакого отношения к кэшу не имеет. Если уж и нужно закэшировать SQL-запрос, то с этим пусть справляется $CI. Там вообще его кухня.

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

          Зато спокойно можно использовать кэш в разных функциях. Например вывод последних записей. Один запрос, результат в кэш. Ключ кэша явно определяется, так что проблем нет. У меня практически все сложные функции имеют подобное кэширование и именно по этому такое малое ресурсопотребление.

          Да, и в отличие от WordPress результат не сохраняется в глобальном объекте. Просто нет надобности. 🙂

        • какая-то операция изменила базу

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

          Но, чем больше я думаю на эту тему, тем больше вопросов возникает. В общем, уже сам сомневаюсь, что такое решение будет эффективным 😉
          Нужно будет поэкспериментировать.

  • А мне все таки больше Kohana понравилась, производная CodeIgniter. Не сложилось у меня с ним.

    • Я с Kohana не работал. А чем она лучше?
      Описание я, конечно, читал. Очень красиво все описано. Но результаты тестирования показывают, что она потребляет практически на 50% больше памяти чем CI.

  • А мне все таки больше Kohana понравилась, производная CodeIgniter. Не сложилось у меня с ним.

    • Я с Kohana не работал. А чем она лучше?
      Описание я, конечно, читал. Очень красиво все описано. Но результаты тестирования показывают, что она потребляет практически на 50% больше памяти чем CI.

  • Toy

    А можно каким нибудь способом сделать, чтобы в файлу config/themes.php, $config['current_theme'] = 'classic'; вместо 'classic' был запрос из базы ? Чтобы через админ панель было легче менять тему.

    • Можно. themes.php — это обычный php файл и в нем можно выполнить любой код, в т.ч. и запрос к базе.

  • Toy

    А можно каким нибудь способом сделать, чтобы в файлу config/themes.php, $config['current_theme'] = 'classic'; вместо 'classic' был запрос из базы ? Чтобы через админ панель было легче менять тему.

    • Можно. themes.php — это обычный php файл и в нем можно выполнить любой код, в т.ч. и запрос к базе.

  • Спасибо, понравилась идея с хелпером для загрузки отображения.

  • Спасибо, понравилась идея с хелпером для загрузки отображения.

  • Budzinkan

    Класс! Спасибо! Как раз искал решение для своей маленькой cms!