Плагин для интернет магазина разработать

я захотел найти через поиск интернет магазина

телевизор и пишу ntktdbpjh т.е забыл переключить язык . плагин должен автоматом переключать

также еще будет 10 подобных заказов после успешного выполнения

админку и фтп дам для работы

Правильная структура файлов и код

Примеры готовых плагинов прикрепил

Конечный продукт на проверку предоставляется в архиве tar.gz

Плагины

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

Фреймворк Вебасист реализует платформу для разработки плагинов для приложений, которая подразумевает гибкость изменения функционала приложений, стандартизированный способ подключения плагинов, установку обновлений через «Инсталлер» и т.п. Эта платформа описана далее в этой статье и является рекомендованной для внедрения в приложения. Предложенная платформа не мешает разработчику приложения реализовать свою собственную методику работы с плагинами, однако, разрабатывая свою систему, следует понимать, что она не будет интегрирована ни со стандартным функционалом фреймворка, ни с приложением «Инсталлер».

Поддержка плагинов в приложении находится полностью на усмотрении разработчика. Чтобы функционал приложения можно было расширять плагинами, необходимо соответствующим образом проектировать приложение и заранее предусмотреть места, в которых другие разработчики смогут расширять функциональность приложения. Некоторые приложения предусматривают расширение своего функционала плагинами, например, приложение «Блог», а некоторые могут не предусматривать этого — например, простые приложения «Гостевая книга», «Списки дел».

Плагин разрабатывается для одного конкретного приложения (не для нескольких приложений и не для всего фреймворка в целом). Разработчик приложения предусматривает в коде приложения места, в которых может быть добавлена дополнительная функциональность. Такие места условно называются хуками (hooks) и подразумевают вызов некоторых событий. Так в приложении «Блог» есть, например, хуки в левом навигационном меню бекенда (что позволяет плагинам добавлять туда свои ссылки или целые HTML-блоки) и хуки на события сохранения записи (что позволяет дополнить функционал на событие публикации записей, например, экспортом записи в Фейсбук).

Терминологически хук и событие различаются примерно так же, как различаются синтаксис и семантика. Хук — это место в коде, а событие — это способ интеграции с функционалом.

В предусмотренном месте приложения разработчик «определяет хук», добавляя следующий код:

wa()->event('[НАЗВАНИЕ_СОБЫТИЯ]', $params);

$params - параметры, которые передаются по ссылке (!)

Далее «опрашиваются» все плагины, у которых в описании указан обработчик указанного события, и все найденные плагины последовательно вызываются. Метод wa()->event($event_name, $params); возвращает массив вида:

array(

'[PLUGIN_ID]-plugin' => результат, который возвращает обработчик плагина

);

Плагины очень похожи на приложения. Структура плагина идентична структуре приложения, плагин хранится в plugins/ внутри директории приложения:

wa-apps/[APP_ID]/plugins/[PLUGIN]/

css

файлы CSS-стилей

img

файлы изображений

js

файлы с JavaScript-кодом

lib

PHP-файлы

actions

классы контроллеров и экшенов

config

конфигурационные файлы плагина:

install.php

скрипт установки плагина

plugin.php

аналог app.php в приложении (общие параметры плагина)

db.php

аналог db.php в приложении (структура таблиц плагина в базе данных)

uninstall.php

скрипт удаления плагина

models

классы взаимодействия с базой данных (если есть)

classes

дополнительные классы (если необходимо)

[APP_ID][PLUGIN].plugin.php

класс [APP_ID][PLUGIN]Plugin extends waPlugin, описывающий обработчики плагина

locale

файл с переводом должен называться [APP_ID]_[PLUGIN]; структура подпапок такая же, как у приложения

templates

шаблоны имеют ту же структуру, что у приложения

actions

шаблоны для отдельных экшенов

Замочком помечены подкаталоги, которые рекомендуется закрыть с помощью директивы Deny from all в файле .htaccess.

Простейший плагин может состоять всего из двух файлов:

lib/config/plugin.php — описание плагина:

return array(

'name' => 'НАЗВАНИЕ ПЛАГИНА',

'version' => '1.0',

// соответствие событие => обработчик (название метода в классе плагина)

'handlers' => array(

'НАЗВАНИЕ_СОБЫТИЯ' => 'method1',

//...

),

// остальные параметры — необязательные

'img' => 'img/plugin.png', // иконка (будет показываться в Инсталлере) размером 16x16

'description' => 'ОПИСАНИЕ ПЛАГИНА'

);

lib/[APP_ID][PLUGIN].plugin.php — класс с описанием обработчиков:

class [APP_ID][PLUGIN]Plugin extends waPlugin // например, blogAkismetPlugin

{

public function method1($params)

{

// реализация обработчика

// если нужен шаблон

$view = wa()->getView();

$content = $view->fetch($this->path.'/templates/[Название шаблона].html')

}

// … остальные обработчики

}

Контроллеры/экшены

Функциональная часть плагинов реализуется в экшенах — в точности, как в приложениях. Если, например, плагин добавляет какой-то HTML в интерфейс приложения или необходимо сохранить что-либо по AJAX, то следует создать контроллеры и экшены аналогично тому, как это делается в приложении. Маршрутизация ничем не отличается от маршрутизации в приложении. Для бэкенда нужно только в URL добавлять параметр plugin=PLUGIN. Для фронтенда необходимо создать файл routing.php, аналогично тому, как это делается для приложения.

Вызов URL (в бэкенде) ?plugin=[PLUGIN]&action=edit передаст управление экшену lib/actions/[APP_ID][PLUGIN]PluginBackendEdit.action.php:

class [APP_ID][PLUGIN]PluginBackendEditAction extends waViewAction

{

public function execute()

{

// реализация экшена

}

}

И по умолчанию будет использоваться шаблон: templates/actions/backend/BackendEdit.html

При реализации экшенов и контроллеров, обрабатывающих загрузку данных на сервер методом POST, учитывайте необходимость проверки данных для защиты от CSRF-атак, если такая защита включена для приложения, для которого разрабатывается плагин. Несоблюдение этого требования приведёт к неработоспособности функции загрузки данных. Подробнее о защите от CSRF-атак →

Действия по расписанию

Фреймворк Вебасист содержит инфраструктуру для создания cli-скриптов (от английского command-line interface, «интерфейс командной строки»), которые могут исполняться из консоли сервера и, следовательно, могут быть включены в задания планировщика (cron). Плагины могут иметь собственные cli-скрипты отдельно от cli-скриптов приложения. Такие скрипты в плагинах оформляются в виде классов, унаследованных от базового класса waCliController. Логика выполнения скрипта должна содержаться в методе класса execute(). PHP-файл класса следует находиться по адресу wa-apps/[app_id]/plugins/[plugin_id]/lib/cli/[app_id][Plugin_id]Classname.cli.php, а имя класса должно быть сформировано по правилу [app_id][Plugin_id]ClassnameCli.

Например, PHP-файл некоторого cli-скрипта с именем update для плагина brands приложения shop может располагаться по адресу wa-apps/shop/plugins/brands/lib/cli/shopBrandsUpdate.cli.php и иметь следующий вид:

class shopBrandsUpdateCli extends waCliController

{

public function execute()

{

// Код, который должен запуститься при вызове скрипта

// Можно использовать модели и любые другие классы приложения

}

}

Для вызова такого скрипта нужно использовать команду следующего вида:

php cli.php shop brandsUpdate

Более подробно о создании cli-скриптов читайте в статье «Действия по расписанию».

Локализация

Локализация плагинов реализуется полностью аналогично локализации приложений (документация). В папке locale следует разместить файлы переводов *.po и *.mo и подключать ключи в коде следующим образом:

_wp($string) в PHP (вместо метода _w(), который работает только с локализацией приложения, следует использовать метод _wp(), подгружающий локализацию плагина),

[`string`] в шаблонах Smarty (здесь нет отличий от локализации приложений).

Название и описание плагина (name и description в конфигурационном файле) переводятся с использованием локализации плагина по умолчанию, таким образом указывать 'name' => _wp('НАЗВАНИЕ ПЛАГИНА') не надо — достаточно просто указать 'name'=>'НАЗВАНИЕ ПЛАГИНА'.

Подробнее о локализации плагинов читайте в основной статье о локализации.

Список событий

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

Подключение плагина

Для того чтобы написанный плагин заработал, необходимо подключить его в системном конфигурационном файле приложения wa-config/apps/APP_ID/plugins.php, добавив в него строку:

'plugin_id' => true

Пример этого файла для приложения «Блог» (wa-config/apps/blog/plugins.php):

return array(

'akismet' => true,

'tag' => true,

'category' => true,

'gravatar' => true,

'favorite' => true,

'troll' => true,

);

В этом же файле можно отключить ненужные плагины.

Пример

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

См. списки событий, доступных в различных приложениях →