Кому интересно, прошу потестить.

Скачать без регистрации и смс

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

Читать дальше →

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

Как это работает

Пользователь заливает новую версию плагина в каталог /plugins/. Система сравнивает текущую версию плагина с версией этого плагина в БД. И если версия в БД старее, то в админке появляется кнопка «Применить обновление», которая автоматически запустит необходимые скрипты для обновления.


Скрипты (классы) для обновления у плагина находятся в каталоге /update/, который в свою очередь содержит каталоги с номерами версий. Для каждой версии можно создать несколько скриптов с произвольным названием, главное, что нужно помнить — названия файлов должно быть уникальным в рамках всего плагина для всех его версий.
Файл с обновлением представляет собой класс наследник от базового класса ModulePluginManager_EntityUpdate и название класса является производным от имени файла — Plugin[plugin_name]_Update_[file_name]. Например, для файла /update/1.0/CreateTable.php класс будет таким:

<?php

class PluginArticle_Update_CreateTable extends ModulePluginManager_EntityUpdate {
	/**
	 * Выполняется при обновлении версии
	 */
	public function up() {
		if (!$this->isTableExists('prefix_article')) {
			/**
			 * При активации выполняем SQL дамп
			 */
			$this->exportSQL(Plugin::GetPath(__CLASS__).'/dump.sql');
		}
	}

	/**
	 * Выполняется при откате версии
	 */
	public function down() {
		$this->exportSQLQuery('DROP TABLE prefix_article;');
	}
}

Как видно из примера, класс содержит два метода up и down. Первый выполняется при обновлении до версии, второй при откате версии. В этих методах может быть не только работа с БД, но и другая необходимая для обновления логика.

При удалении плагина из админки выполняется автоматический откат всех изменений всех версий (метод down).
Данный поход позволит «разгрузить» у плагинов методы Activate и Deactivate от лишней логики и дать удобный механизм обновления версий. Для корректной работы данного механизма, необходимо версии плагинов именовать используя вот этот стандарт — ru2.php.net/manual/ru/function.version-compare.php, он позволит правильно сортировать версии.

В новой версии появился новый модуль Rbac — модуль управления правами на основе ролей и разрешений (RBAC).
Суть его сводится к тому, что теперь в админке можно создавать различные роли, давать ролям необходимые права (разрешения) и назначать эти роли пользователям. Роли могут наследовать от других ролей. Таким образом можно очень гибко настраивать систему управления правами.



Читать дальше →

В новой версии LS появится функционал универсальных категорий.
Плагины смогут привязывать древовидные категории к любым объектам (полная интеграция с ORM), управления такими категориями доступно из админки. Из коробки категории будут работать для блогов (как сейчас на сайте livestreet.ru).

Интеграция в плагинах

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

	protected $aBehaviors=array(
		// Настройка категорий
		'category'=>array(
			'class'=>'ModuleCategory_BehaviorEntity',
			'target_type'=>'article',
			'form_field'=>'category',
			'multiple'=>true,
		),
	);

Для модуля:

	protected $aBehaviors=array(
		// Настройка категорий
		'category'=> array(
			'class'=>'ModuleCategory_BehaviorModule',
			'target_type'=>'article',
		),
	);

Читать дальше →

В новой версии LS 2.0 появится функционал поведений (behaviors), который очень поход на подобный в Yii.
Суть сводится к тому, что теперь определенному типу объектов (пользователи, топики, блоги и т.п.) или конкретному объекту можно назначить через поведения определенный новый функционал.
Добавить новое поведение в объект достаточно просто, можно у объекта определить свойство $aBehaviors. Например:

	protected $aBehaviors=array(
		'category'=>'ModuleCategory_BehaviorCategory',
		'property'=>array(
			'class'=>'ModuleProperty_BehaviorPropertyEntity',
	        	'target_type'=>'article'
		)
	);

В этом примере добавляются два поведения — категории и дополнительные поля. В качестве ключа используется название поведение (далее по этому ключу можно обращаться к поведению), а в качестве значения идут параметры. Параметры идут произвольным массивом имя/значение, 'class' — это служебный параметр, означающий класс поведения. Если у повеления нет параметром, то его можно записать в короткой форме (смотри 'category'). Альтернативным (скорее дополнительным) способом добавления поведения является прямой вызов метода AttachBehavior, например:

$oTopic->AttachBehavior('property','ModuleProperty_BehaviorPropertyEntity');

// далее можно убрать поведение
$oTopic->DetachBehavior('property');

Читать дальше →

В новой разрабатываемой версии LiveStreet есть функционал дополнительных (пользовательских) полей. Сейчас он задействован для топиков. Суть сводится к удобной возможности добавлять в различные объекты новые поля разных типов.

Сейчас поддерживаются следующие типы полей:

• Целое число
• Дробное число
• Строка
• Текст
• Чекбокс
• Дата
• Выпадающий список
• Теги
• Ссылка на видео
• Файл
• Изображение

Постепенно мы наращиваем функционал и количество типов.
За весь функционал по полям отвечает модуль Property. Рассмотрим пример подключения функционала дополнительных полей к плагину «Статьи» на базе ORM.

Читать дальше →

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

Рассмотрим основные технические моменты. Есть два варианта интеграции:

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

Визуальное управление конфигом плагина

Все что нужно сделать, это описать так называемую схему конфига. Она состоит из двух частей — описание всех параметров конфига и описание групп/разделов параметров, которые формируют визуальную группировку на странице редактирование параметров.
Описание всех параметров задается в конфиге плагина в специальном ключе $config_scheme$, например

$config['$config_scheme$'] = array(
	'per_page' => array(
		/*
		 * тип: integer, string, array, boolean, float
		 */
		'type' => 'integer',
		/*
		 * отображаемое имя параметра, ключ языкового файла относительно плагина, или просто текст
		 */
		'name' => 'Количество элементов на страницу',
		/*
		 * отображаемое описание параметра, ключ языкового файла относительно плагина, или просто текст
		 */
		'description' => 'config.per_page.description',
		/*
		 * валидатор (не обязательно)
		 */
		'validator' => array(
			/*
			 * тип валидатора, существующие типы валидаторов движка:
			 * Boolean, Compare, Date, Email, Number, Regexp, Required, String, Tags, Type, Url, + Array (специальный валидатор, см. документацию)
			 */
			'type' => 'Number',
			/*
			 * параметры, которые будут переданы в валидатор
			 */
			'params' => array(
				'min' => 1,
				'max' => 20,
				/*
				 * разрешить только целое число
				 */
				'integerOnly' => true,
				/*
				 * не допускать пустое значение
				 */
				'allowEmpty' => false,
			),
		),
	),
	'param_string_1' => array(
		'type' => 'string',
		'name' => 'config.param_string_1.name',
		'description' => 'config.param_string_1.description',
		'validator' => array(
			'type' => 'String',
			'params' => array(
				'min' => 5,
				'max' => 50,
				'allowEmpty' => true,
			),
		),
	),
);

Читать дальше →

Мы начинаем серию публикаций о том, что мы уже реализовали нового и собираемся реализовать в новой версии LiveStreet.

Начнем с новой файловой структуры движка.
Главное, что сделали — это ввели жесткое разделение между файлами приложения и файлами фреймворка. В итоге в корне получилось всего три каталога:



Читать дальше →

Предыдущие части:

• Часть I. Введение, хостинг и PuTTY.
• Часть II. Vim, файловая система, hostname.
• Часть III. Некоторые настройки ядра, репозитории и базовые утилиты.
• Часть IV. MySQL.
• Часть V. Apache.
• Часть VI. PHP.
• Часть VII. NGINX.
• Часть VIII. APC, Memcached & Sphinx.
• Часть IX. LiveStreet.

PHP 5.3 Reaching End of Life

11-Jul-2013 The PHP development team announces the immediate availability of PHP 5.3.27. About 10 bugs were fixed, including a security fix in the XML parser (Bug #65236).

Please Note: This will be the last regular release of the PHP 5.3 series. All users of PHP are encouraged to upgrade to PHP 5.4 or PHP 5.5. The PHP 5.3 series will receive only security fixes for the next year.

Новости уже сто лет в обед. Поддержка PHP 5.3 завершена. Всем заинтересованным лицам предлагается переходить на PHP 5.4 или PHP 5.5. Продолжать жить на больше не поддерживаемой версии, мысль не очень хорошая, хотя бы из соображений безопасности (фиксы дыр в безопасности это то, что надо бы постоянно ставить). Учитывая, что следование инструкции устанавливало именно PHP 5.3, я решил описать что нужно сделать чтобы перевести установку на использование PHP 5.4.

Читать дальше →