сентября 27, 2011

PrestaShop инструкция для разработчиков

Мне нравится работать с PrestaShop, т.к она имеет современную и логичную структуру. Достигается это за счёт использования Model-View-Controller (MVC), подхода столь популярного сегодня.
В рамках данной темы будет написано несколько инструкций. Конечно если Вы не знаете основ ООП, то лучше начать с изучения теории и для начала просто установить PrestaShop, по инструкции опубликованной на моём блоге web-esse.ru.
В PrestaShop файлы относящиеся модели (классы) расположены в папке /classes, представление в подпапке /themes, а контнроллеры в /controllers. Файлы в корневой директории необходимы для вызова одноимённого контроллера (это сделано для совместимости с версией 1.3).

В начале каждого файла класса или контроллера есть комментарий, в котором сообщается, что изменение этих файлов делает не возможным дальнейшее обновление системы. Но почему то многими разработчиками этот факт игнорируется (часто обращаются клиенты с просьбой доделать тот или иной функционал, т.к предыдущий “специалист” не справился, часто приходишь в ужас от того как в процессе изобретения велосипедов изощряются горе-разработчики). Чтобы изменить или дописать функционал PrestaShop необходимо использовать волшебную папочку /override, выполнив этот не сложный шаг вы оставляете клиенту возможность получать обновление системы без потери дополнительного функционала. Кстати в папку /modules, для системных модулей обновления вносить тоже нельзя, для этого следует скопировать шаблон модуля в свою тему, например, themes/myshop/modules/blockuserinfo/blockuserinfo.tpl. А не создавать в корневой /modules, новый модуль, например, modules/blockuserinfo2/blockuserinfo.tpl, как делают некоторые начинающие разработчики.
Отображение – Вид – Views
Эта наиболее часто меняемая часть, т.к ни один нормальный магазин не запускают на дефолтном шаблоне. Поэтому и вопросов больше всего возникает именно по тому как изменить отображение. От простых: “Как изменить логотип магазина на PrestaShop” до более сложных вопросов связанных с системой хуков и вёрсткой под Smarty.
Модель – Model
Каждый класс в папке /classes является потомком родительского класса ObjectModel и соответственно расширяет его CRUD (Create, Read, Update и Delete) функционал применительно к какой либо сущности и валидацию данных. Т.е каждый класс работает с отдельным объектом-сущностью БД (чаще всего каждому таком объекту соответствует отдельная таблица) и принимает на входе идентификатор по которому можно найти необходимую строку в таблице. Например, в классе Address: имя таблицы – address и идентификатор строки, принимаемый на входе – id_address.
Схема классов
Название класса совпадает с названием php файла и заканчивается на Core, таким образом они могут быть переопределены в папке /override/classes.
Сводная таблица классов PrestaShop, описание их основных функций.
Контроллеры- Controllers
Назначение контроллеров соответствует модели MVC и служит для связи логики системы, отражённой в системе классов и представления (шаблонов PrestaShop).
В первой части названия присутствует имя класса-модели с которым взаимодействует контроллер. Например, AddressController.php используется для редактирования адресной информации объекта модели /classes/address.php; ProductController.php работает с продукцией магазина (класс /classes/product.php) и т.п
Все контроллеры являются потомками базового класса FrontController, поэтому не зависимо от специфичности обрабатываемой информации у каждого есть общие функции.
Функции часто используемые в контроллерах PrestaShop. (готовится к публикации)


Комментарии

  • Дима

    Мне тоже очень нравится Prestashop своей гибкостью. Спасибо за статью очень полезно!

  • А как быть если надо немного подредактировать скрипт модуля?
    Иногда надо изменить количество выводимых товаров (не все модули позволяют это настраивать), иногда поменять Хук для вывода?

    Еще встречал один случай когда перегрузка контроллера через /override не работала, зато напрямую правки в скрипте срабатывали. Тогда я правил процесс оформления заказа и правил контроллер AuthController.php. Предполагаю, что это связанно с тем, что в оформлении заказа много AJAX, я как раз правил кусочек когда, работающий при AJAX запросе…

  • Страница заказа – наиболее частая правка для меня, переопределение AuthController всегда срабатывает.
    Нужно помнить что если вы вносите правки в ядро системы, то обновление системы будет сопряжено с проблемами….

  • sadko

    Здравствуйте!

    Это снова я!
    Изучаю OpenCart. Переделываю шаблон cofran с 1.4.9 на 1.5.1.3. Но так как в программировании я вообще чайник полный, возник такой вопрос:

    В cofran есть переменные в header.tpl на которые сервер ругается, что – они не определены (Undefined variable: text_contact). А определяются они, как я понял контроллером footer.php строкой:

    $this->data['text_contact'] = $this->language->get(‘text_contact’);

    Первое, что мне пришло на ум – дописать в контроллере header.php вышеуказанную строку с инициализацией переменной $text_contact, а в контроллере footer.php ее удалить. Но потом я вспомнил об этом вашем топике и подумал, что это наверное неправильно – изменять контроллер! Если я это сделаю – невозможно будет обновить сиситему. И как же мне правильно поступить? Как мне инициилизировать переменную без изменения контроллера? Волшебную апку /override я в OPenCart не нашел…

    Спасибо!

    • Что Вы подразумеваете под переделываю, если вы просто пытаетесь поставить шаблон старой версии на новую – понятно почему он ругается на отсутствие переменных. Нужно найти переменные в старой версии движка, посмотреть как они определяются, потом сравнить с новой – возможно в новой их переименовали или включили в массив.
      Да к сожалению при внесении правок в ядро OpenCart обновление становится ручным (но не невозможным). Просто потом придётся ещё раз вносить правки в уже обновлённые фалы.

  • sadko

    Здравствуйте!
    В новой версии – конкретно эти переменные обзываются также. Но в старой они были в header.tpl и объявлялись в header.php, а в новой версии – их засунули в footer.tpl и объявляют в footer.php.

    Ручное обновление это не как-то неправильно тоже. Слыхал в этом может помочь SVN. В частности если поставить TortoiseSVN, то, говорят можно отслеживать изменения вносимые собой, сделать их патчем и потом, в случае обновления ядра – пропатчить своими изменениями новое ядро. Это правда? Меня смущает такой вопрос – а если изменения ядра были такими, что там просто уже не будет тех строк, которые я поменял под себя? Что будет в таком случае – снова ручная работа? А где можно про SVN на уровне чайников почитать?

    Спасибо.

    • SVN очень удобная штука и настраивается не очень сложно… Есть поддержка в Eclipse – я использую именно эту IDE. Первое представление можно получить по видео-урокам “Школы программирования” (в одной из ступеней php, точно не помню) – во всяком случае именно в этом источнике ИМХО наиболее доступно всё объясняется.

  • sadko

    Спасибо!

    Как я я узнал на теперь – есть два пути:

    1. SVN и пропатчить своими изменениями проапгрейдженное ядро
    2. vqmod и патчить своими изменениями страницы на лету. Только тут одни говорят – что страницы генерируются дольше, а другие – что включение какого-то кеширования, делает это “дольше” – незаметным глазу.

    Или я правильно понимаю?

    • Я использую видоизменённый первый вариант.
      Вариант с VirtualQMod тоже интересный (tvorzasp.com/blog/ustanovka-i-ispolzovanie-vqmod – подробнее), но я им не пользовалась пока.

  • Введите имя

    Не кинете ссылку на видео-уроки “Школы программирования” – че-то поискал в инете: какая-то школа есть, какие-то ролики есть, но все не о том. Возможно я не в ту школу забрел.

    Буду вам очень признателен!

    Спасибо!

    • prog-school.ru/products/phpro – описание на официальном сайте

  • Владимир

    Анастасия, возможно вы и мне подскажите? Как переопределить поведение FrontController’а? В частности интересует перегрузка метода init(), оперирование с cookies и последующий вызов родительского метода. Проблема состоит в том, что в родительском методе объект cookies создается заново и изменения проведенные с печеньками, но еще не отправленные в браузер, затираются. Есть ли способ корректно обойти эту особенность вместо того чтобы полностью переопределять метод init()?

    • А какие данные вы пытаетесь сохранить? Обычно нативных cookies хватает (если не стоят задачи интеграции со сторонними системами и т.д).

      • Владимир

        Перед вызовом parent::init() идет вызов самописного модуля геолокации. этот модуль в куки пишет язык пользователя и валюту для его страны, но после этого родительская функция перезаписывает эти данные если они отличаются от значений по-умолчанию.

  • Vad

    Здравствуйте Анастасия, а что скажите по поводу opencart я слышал что они в чем то схожи с prestashop. Хотелось бы ваше авторитетное мнение услышать. Заранее спасибо!

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

      • За исключением того что для ОпенКарт почти нет модулей, тем, и беднее комьюнити

  • Sergalmaty

    Добрый день! Подскажите пожалуйста как решить проблему с тем что, главная страница полностью пустая, хотя другие мтраницы с товарами отображаются, галочки на отображение на главной странице на всех товарах стоят… Заранее спасибо!

  • alexei

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

    1)Тоесть я регистрируюсь в престашопе и мне приходит пиьсмо с логином и паролем на мой емаил. Можно зделать так чтоб эти письма приходили на один емаил а не на эмаил клиента

    2) Так же при покупке товара чтоб письмо не клиенту отсылалось а на нужный эмаил

    Заранее благодарен!

    • Добрый день – модуль mailallert как раз отвечает за отправку писем на указанный мэйл