Leaderboard

Причин может быть масса от конфига сервера, до тяжелых запросов к бд, проблемы с dns, cdn и тд Возьмем то случай, когда ваш VPS имеет много ресурсов и настроен серьезным специалистом, а значит проблема на стороне опенкарта и плагинов, которые были установлены Обычно первым делом включают лог тяжелых запросов. Опенкарт в момент создания таблицы выбирает тип таблиц ENGINE=MyISAM. Этот тип может блокировать таблицы, именно поэтому в логе можно встретить простейшие запросы выполняющиеся по 2+ секунды. Лучше перейти на innodb. На просторах гитхаба есть скрипт, который поможет сменить движок хранилища, а так же добавить индексы к таблицам. Кстати, индексы он добавляет всем столбцам, которые содержат подстроку "_id" https://github.com/lilalaunesau/opencart-turbo Но одним логом сыт не будешь и поэтому я написал решение, которое покажет время работы каждого контроллера на странице. Предварительно желательно отключить кеширование mysql. За это отвечают такие параметры конфигурации как query_cache_size = 0 query_cache_type = 0 С скрина, который прикреплен к этому посту можно сделать вывод, что менюшка не кешируется и грузится около 640мс Один из моих модулей отрабатывает за 100мс, что тоже не есть хорошо, но с учетом того что на этой странице таблица из 10+ товаров, то норм Футер тоже можно закешировать сэкономив около 300мс Если этот пост набирает 5 комментов, то выложу это решение. Напоследок хочу сказать, что продакшн это святое и любые тесты и замеры нужно делать на дев, тест или локальном окружении под присмотром профессионалов. Если я где-то некорректно выразился, то пишите поправим

Якщо на комп'ютерi ще не встановлено node.js його потрiбно завантажити з офсайту та встановити як звичайний додаток. Короткий посібник: 1) Спершу потрiбно вiдкрити консоль, та перейти до проекту наприклад, cd D:\xampp\htdocs\www\multiedit-pro\ 2) Переходимо до розгорнування проекту, вводимо в консолi: npm create vite@latest 3) Назва проекту: Якщо на цьому етапi ви розгортаєте новий чистий проект, то можна вказати його назву. Але в нашому випадку, для роботи поряд з CMS OpenCart замiсть назви, потрiбно поставити крапку тодi з'явиться запитання, i вам потрiбно буде: 3) Обрати Ignore files and continue, щоб залишити вже iснуючi файли. 4) Обрати шаблон я обираю Vue. 5) Обрати налаштування наприклад JavaScript Готово! 6) Для подальшої роботи підтягуємо залежнi модулi npm i ...тут буде багато iнфи) А ось i результат: Проект створили, та рушiй ocStore не зачепили! (Вiн знаходиться в папцi upload). А тепер можна й подивитись на результат, та отримати крапельку дофаміну: npm run dev, або npm run preview! Офiцiйний сайт Vite!

Я хочу затронуть тему очередей, которые используются повсеместно в интернет-проектах, но в Opencart данная тема особо не освещена. Представьте, что вам нужно прямо сейчас сделать выгрузку для какого-то маркетаплейса, вот только в выгрузке у вас, например, 50к товаров. Крон у вас работает раз в сутки, а менеджер магазина не подключится по ssh и не будет запускать консольный скрипт выгрузки. В подобной ситуации вам поможет система очередей. Очереди - это не конкретная технология, а только принцип. В самом примитивном виде у нас есть издатель и подписчик (producer и worker). Издатель добавляет в очередь данные, по сути инициирует выполнение какого-то действия. А воркер непосредственно выполняет нужную нам работу. Между ними присутствует обменник, который хранит сообщения и распределяет их между воркерами. При этом мы можем использовать несколько воркеров (обработчиков) для одной задачи. Где можно использовать очереди 1. Асинхронное (фоновое) выполнение задач. Допустим, что при оформлении заказа мы отправляем письма о новом заказе через внешний SMTP-сервер, админу кидаем уведомление в телеграм, а также экспортируем данные о заказе в CRM. Какие проблемы нас поджидают: синхронное выполнение каждого процесса - пользователь будет ждать, пока отработает последовательно каждый из процессов зависимость от внешних сервисов - они вполне могут работать нестабильно и все это время клиент будет видеть экран загрузки, вместо быстрого оформления заказа. Вместо этого мы создаем три отдельных очереди (для email, телеграма и CRM) и просто кидаем в них сообщения. Пользователь успешно оформляет заказ, а в это время процессы отправки писем и уведомлений выполняются параллельно в фоне. Также можно: генерировать выгрузки в маркетплейсы по запросу пользователя, делать импорт/экспорт товаров, строить карты сайта, отчеты и т.д. 2. Имитация многопоточности. PHP "из коробки" однопоточный, но с помощью очередей можно сделать несколько обработчиков одной задачи. Примеры: Импорт товаров - у нас есть исходный эксель-файл с товарами. Распарсить файл и получить данные можно довольно быстро, а вот импорт данных потребует больших ресурсов, т.к. нужно выполнять вставку данных во множество таблиц. Исходя из этого разбиваем процесс импорта на два этапа: на первом этапе парсим эксель файл и в результате парсинга каждой строки получаем результирующий набор данных, нужный для создания товара. Этот набор данных мы кидаем в очередь для импорта. создаем обработчик, который будет заниматься только импортом готовых данных. При этом мы можем запустить одновременно 5 таких обработчиков (или сколько позволят ваши ресурсы) и система очередей будет распределять задачи по импорту товаров между данными обработчиками. В итоге вместо построчного импорта товаров мы получаем 5 параллельных обработчиков импорта. Данную технику можно применить для парсинга товаров. От теории перейдем к практике. Система очередей на RabbitMQ Выше я уже писал, что система очередей - это лишь архитектурный принцип и он может быть реализован с помощью множества технологий: крон и база данных, хранилище типа Redis и т.д., но я выбрал в качестве примера специалированное ПО RabbitMQ. Кролик содержит множество возможностей: гибкую маршрутизацию, масштабируемость, хранилище сообщений и т.д. Я использую Docker в качестве среды для локальной разработки, поэтому покажу, как установить RabbitMQ именно в этой среде. Про Docker я писал в этой статье: https://opencartforum.com/blogs/entry/383-zapusk-i-otladka-opencart-s-pomoschyu-docker-i-xdebug/ Установка RabbitMQ с помощью docker compose 1. В docker-compose.yml добавляем сервис: rabbitmq: image: rabbitmq:3-management-alpine hostname: my-rabbit volumes: - ./rabbitmq/etc/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf - ./rabbitmq/data:/var/lib/rabbitmq/mnesia/rabbit@my-rabbit - ./rabbitmq/logs:/var/log/rabbitmq/log ports: - 5672:5672 - 15672:15672 2. В корневой директории Docker-проекта создаем папку rabbitmq и в ней создаем три папки: data, etc, logs для хранилища данных, конфигов и логов. В папке rabbitmq/etc создаем файл конфига rabbitmq.conf с содержимым: loopback_users.guest = true listeners.tcp.default = 5672 management.listener.port = 15672 management.listener.ssl = false Далее как обычно билдим все в Docker для установки нового сервиса и запускаем контейнеры: docker-compose up -d --build Для администрирования RabbitMQ поставляется с панелью, которая будет доступна по адресу: http://localhost:15672. В данной панели можно смотреть, какие очереди выполняются, получить сообщения, очистить очереди т.д. Пароль и логин для доступа: guest / guest. Естественно, на рабочем сервере нужно удалить гостевого пользователя и добавить нового админа. Использование RabbitMQ c Opencart Написал простую библиотеку https://github.com/ozzzi/opencart-rabbitmq Для ее работы нужно: 1. Установить зависимость: composer require php-amqplib/php-amqplib . В библиотеке предполагается, что папка vendor будет лежать на уровень выше, чем корневая директория opencart. 2. Добавить в config.php конфиг RabbitMQ: define('RABBITMQ_HOST', 'host'); define('RABBITMQ_PORT', '5672'); define('RABBITMQ_USER', 'guest'); define('RABBITMQ_PASS', 'guest'); Если речь идет о исполнении в докер-контейнере, то в качестве хоста нужно указать айпи контейнера (читаем предыдущую статью о докере). Затем в опенкарте можем использовать библиотеку: $this->load->library('queue'); $this->queue->addTask('queueName', ['some' => 'data']); Первый параметр в методе addTask - имя очереди, а второй параметр (опциональный) - данные, которые нужно передать в воркер. Примеры Далее я приведу примеры использования очередей для отправки почты, импорта товаров из Excel, и парсинга сайтов. 1. Отправка email Полный код: https://github.com/ozzzi/email_service В коде Opencart-а меняем родной код отправки email-ов на: $this->load->library('queue'); $this->queue->addTask('email', ['data' => 'examlpe_data']); Т.е. мы добавили в очередь email данные для обработки: кому, от кого и что отсылаем. За обработку данной очереди отвечает воркер: cli/email_notify.php. Вы должны сами реализовать получение конфигов для SMTP-сервера. В панели управления RabbitMQ можно увидеть, что во вкладке очередей появилась новая очередь и одно сообщение. Чтобы очередь его отработала, воркер cli/email_notify.php должен быть запущен. Для примера мы запустим его вручную внутри контейнера, а в конце я объясню, как сделать запуск автоматическим. Смотрим имена контейнеров: docker ps Нас интересует, контейнер с PHP-FPM. Чтобы войти в него выполняем: docker exec -it container_name bash Далее переходим в папку cli и стандартно запускаем скрипт: php email_notify.php Если все прошло успешно, в панели кроля вы увидите, что очередь email очистилась. Значит сообщение ушло получателю. 2. Импорт товаров из Excel Полный код: https://github.com/ozzzi/excel_import_worker В админской части вам нужно реализовать загрузку файла, передать конфиг настроек полей и подключить загрузчик композер: '/vendor/autoload.php' Затем реализовываем наш загрузчик (producer): use App\Service\ExcelParser; $file = 'price.xlsx'; $setting = [ 'category' => 'B', 'name' => 'C', 'model' => 'D', 'price' => 'G', 'quantity' => 'H', 'manufacturer' => 'F', 'description' => 'M', ]; $this->load->library('queue'); $excelService = new ExcelParser($setting, $file); foreach ($excelService->parse() as $product) { $this->queue->addTask('import', ['product' => $product]); } В итоге после чтения каждой строки мы добавляем в очередь import объект с данными товара. Чтобы обработать все сообщение из очереди "импорт" запускаем воркер: cli/product_import.php (App\Service\ProductImport - вам нужно реализовать самим ). Чтобы процесс пошел "бодрей", можно запустить параллельно несколько воркеров product_import.php. 3. Парсер сайта в несколько потоков Полный код: https://github.com/ozzzi/html_parser_worker Для примера возьмем первый попавшийся магазин стройматериалов (ссылка в коде) и спарсим все товары из категории "Сухие смеси". Разделим процесс парсинга на два этапа: Получение списка ссылок на карточки товаров. За один запрос мы можем получить все ссылки на товары для первой страницы. Если страниц пагинации в категории 5 и в среднем на загрузку страницы уходит 1 секунда, то за 5 секунд мы получим все ссылки на товары в данной категории. Парсинг страниц товаров в несколько потоков. Т.к. каждая карточка товара загружается условную секунду, то данный процесс нам нужно распараллелить, запустив несколько воркеров. Запускаем скрипт cli/parser_category.php, который будет отправлять в очередь parse_product ссылки на товары. Затем запустим несколько воркеров cli/import_worker.php. В результате ProductParser возвращает сущность Товар, которая импортируется с помощью сервиса ProductImport, с которым вы уже знаете, что делать. Надеюсь, что вы поняли, как применять очереди в таком простом виде. Теперь расскажу, как запускать воркеры как демоны в автоматическом режиме (чтобы они работали постоянно и перезапускались сами вместе с системой). Один из способов - supervisor. Установка для Debian\Ubuntu стандартная: apt-get install supervisor Добавляем конфиг для запуска конкретного скрипта. Например, добавим конфиг для запуска воркера в виде двух процессов: Создаем файл: /etc/supervisor/conf.d/worker.conf [program:worker] command=php /path/to/script.php stdout_logfile=/var/log/worker.log autostart=true autorestart=true user=www-data stopsignal=KILL process_name=%(program_name)s_%(process_num)02d numprocs=2 Перезагружаем supervisor: service supervisor restart Если вам скучно, обязательно попробуйте очереди.

Вы когда-нибудь забывали внести изменения в базу данных после публикации нового функционала? А еще эти кеши модификаторов, которые нужно не забыть обновить. В этой статье я опишу, как автоматизировать процесс деплоя проекта и избавить себя от рутины. Данная статья предполагает, что вы используете Git как систему контроля версий, GitHub как хранилище вашего репозитория и также у вас есть SSH доступ к серверу, на котором можно запустить composer. В качестве основы для нашей автоматизации мы будем использовать GitHub Actions, который позволяет запускать различные процессы внутри контейнеров. Что нам понадобится сделать: консольные скрипты для очистки модификаторов и кеша системы систему миграций для БД Консольные команды Конечно, можно использовать исходный код опенкарта и на основе него написать скрипты, но это не наш метод. Мы напишем собственные велосипеды и за основу возьмем Symfony Console. Устанавливаем нужные зависимости: composer require symfony/console Создаем директорию src для нашего приложения (лучше всего размещать такой код на уровень выше вашего index.php) В composer.json, в разделе автозагрузки добавим код для задания пространства имен нашего приложения: "autoload": { "psr-4": { "App\\": "путь к папке/src/", } }, "require": { ...список ваших зависимостей..., } Создадим папки в директории src для будущего кода: Commands, Models, Services, Traits Структура папки src Создадим сервисы для очистки директорий кеша Базовый класс <?php declare(strict_types=1); namespace App\Services\Clear; use FilesystemIterator; use RecursiveDirectoryIterator; use RecursiveIteratorIterator; class BaseClearService { protected const SKIP_FILE = 'index.html'; public function clear(string $dir): void { $directories = new RecursiveDirectoryIterator($dir, FilesystemIterator::SKIP_DOTS); $files = new RecursiveIteratorIterator($directories, RecursiveIteratorIterator::CHILD_FIRST); foreach ($files as $file) { if ($file->isFile() && $file->getFilename() === self::SKIP_FILE) { continue; } $file->isDir() ? rmdir($file->getRealPath()) : unlink($file->getRealPath()); } } } Сервис очистка системного кеша <?php declare(strict_types=1); namespace App\Services\Clear; class CacheClearService extends BaseClearService { public function process(): void { $this->clear(DIR_CACHE); } } Сервис очистки старых модификаторов <?php declare(strict_types=1); namespace App\Services\Clear; class ModificationClearService extends BaseClearService { public function process(): void { $this->clear(DIR_MODIFICATION); } } ModificationService - мне было лень переписывать код, взял из опенкарта как есть. Первый сервис очищает директорию, а второй создает модифицируемые файлы. Для создания файлов нам нужно из базы получить список модификаторов. Для этой цели можно использовать разные подходы, но т.к. я использую в других проектах Laravel, я задействую для работы с базой Eloquent . Установим пакет: composer require illuminate/database Создаем файл модели модификаций: <?php declare(strict_types=1); namespace App\Models; use Illuminate\Database\Eloquent\Model; class Modification extends Model { protected $table = 'modification'; protected $primaryKey = 'modification_id'; public $timestamps = false; } Файлы для работы с базой данных <?php namespace App\Traits; trait Singleton { public static $instance; public static function getInstance(): self { if (empty(self::$instance)) { self::$instance = new static(); } return self::$instance; } private function __clone() { } private function __wakeup() { } } Теперь непосредственно создадим классы консольных команд для очистки системного кеша <?php declare(strict_types=1); namespace App\Commands; use App\Services\CacheClearService; use Symfony\Component\Console\Command\Command; use Symfony\Component\Console\Input\InputInterface; use Symfony\Component\Console\Output\OutputInterface; class CacheClearCommand extends Command { protected function configure(): void { $this->setName('cache:clear') ->setDescription('Clear system cache'); } protected function execute(InputInterface $input, OutputInterface $output): int { try { (new CacheClearService())->process(); } catch (\Throwable $e) { $output->writeln('<error>Directory error</error>'); return Command::FAILURE; } $output->writeln('<info>Modification cache cleared successfully</info>'); return Command::SUCCESS; } } И для очистки кеша модификаторов <?php declare(strict_types=1); namespace App\Commands\Opencart; use App\Models\Database; use App\Services\ModificationClearService; use App\Services\ModificationService; use Symfony\Component\Console\Command\Command; use Symfony\Component\Console\Input\InputInterface; use Symfony\Component\Console\Output\OutputInterface; class ModificationClearCommand extends Command { protected function configure(): void { $this->setName('cache:modification') ->setDescription('Clear modification cache'); } protected function execute(InputInterface $input, OutputInterface $output): int { try { Database::getInstance(); (new ModificationClearService())->process(); (new ModificationService())->process(); } catch (\Throwable $e) { $output->writeln('<error>Directory deleting error</error>'); return Command::FAILURE; } $output->writeln('<info>Modification cache cleared successfully</info>'); return Command::SUCCESS; } } Соберем все в общее консольное приложение <?php declare(strict_types=1); namespace App\Commands; use App\Commands\CacheClearCommand; use App\Commands\ModificationClearCommand; use Exception; use Symfony\Component\Console\Application; class AppConsole { /** * @throws Exception */ public function run(): void { $app = new Application(); $app->add(new ModificationClearCommand()); $app->add(new CacheClearCommand()); $app->run(); } } И создадим файл console в корне, который будет запускать саму консоль #!/usr/bin/env php <?php require dirname(__DIR__) . '/путь к/vendor/autoload.php'; require __DIR__ . '/путь к/admin/config.php'; use App\Commands\AppConsole; (new AppConsole())->run(); Делаем его исполняемым: chmod +x console Теперь при запуске команды php console мы получим список доступных команд: php console cache:clear - очистка системного кеша php console cache:modification - очистка модификаторов Таким образом можно создать другие команды: для сжатия картинок, для бэкапов базы и т.д. Миграции баз данных Данный подход позволяет фиксировать все изменения базы в PHP-коде. Следовательно, мы можем в Git хранить всю историю изменений базы данных. Мы будем использовать библиотеку phinx. Установим ее: composer require robmorgan/phinx Далее запускаем команду для создания конфигурационного файла phinx.php ./vendor/bin/phinx init Создадим папку db/migrations - тут будут храниться файлы миграций. В конфиге phinx.php прописываем путь для папки, где будут лежать файлы миграций и параметры подключения к БД <?php return [ 'paths' => [ 'migrations' => '%%PHINX_CONFIG_DIR%%/путь до папки db/migrations', 'seeds' => '%%PHINX_CONFIG_DIR%%/db/seeds' ], 'environments' => [ 'default_migration_table' => 'phinxlog', 'default_environment' => 'development', 'development' => [ 'adapter' => 'mysql', 'host' => 'host db', 'name' => 'opencart', 'user' => 'admin', 'pass' => '1234567', 'port' => '3306', 'table_prefix' => 'oc_', 'charset' => 'utf8mb4', ], ], 'version_order' => 'creation' ]; Ключ environments позволяет прописывать различные подключения к базе на проде или тестовом сервере и потом при запуске указывать, для какого окружения нужно запускать миграции. Чтобы создать миграцию, запустите команду create и укажите название класса миграции, в названии которого будет отображена суть (для какой таблицы мы создаем миграцию). Например, создадим миграцию для таблицы с постами: ./vendor/bin/phinx create PostsTableMigration После чего в папке db/migrations появится файл с временной меткой в названии файла и именем миграции с snake case. Заполним файл: <?php declare(strict_types=1); use Phinx\Migration\AbstractMigration; final class DocsMigration extends AbstractMigration { public function change(): void { $table = $this->table('docs'); $table->addColumn('route', 'string') ->addColumn('description', 'text') ->addColumn('created', 'datetime', ['default' => 'CURRENT_TIMESTAMP']) ->addIndex(['route'], ['unique' => true]) ->create(); } } Тут все просто, указываем название таблицы, колонки и их типы, задаем индексы. Для каждой таблицы автоматически создается автоинкрементное поле id. Полную инструкцию по написанию миграций можно найти на оф. сайте: https://book.cakephp.org/phinx/0/en/migrations.html Для запуска миграций воспользуемся командой: ./vendor/bin/phinx migrate После запуска данного скрипта в таблице phinxlog (настраивается в параметре default_migration_table из файла phinx.php) появится запись о примененной миграции. GitHub Actions Остался последний и самый главный этап - настройка на стороне GitHub. Создаем в корне проекта файл (указываю полный путь) .github/workflows/deploy.yml. Здесь будут указаны все задачи, которые должны будут запускаться внутри контейнеров на стороне GitHub. name: Deploy on: push: branches: [ main ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Deploy to server uses: appleboy/ssh-action@master with: host: ${{ secrets.HOST }} username: ${{ secrets.USERNAME }} key: ${{ secrets.KEY }} port: ${{ secrets.PORT }} script: | cd /путь к корню проекта ./.scripts/deploy.sh ./vendor/bin/phinx migrate Тут мы указываем на что будет реагировать наш Action. В данном случае на пуш в ветку main on: push: branches: [ main ] jobs - непосредственно описываем задачи deploy - имя задачи appleboy/ssh-action@master - инструмент для запуска удаленных команд по SSH. Ниже указаны параметры для аутентификации и список выполняемых команд: - cd - переходим в корень проекта - ./.scripts/deploy.sh - запускаем баш-скрипт с нашими командами (опишем ниже) - ./vendor/bin/phinx migrate - запускаем миграции appleboy/ssh-action@master - для аутентификации можно использовать ssh-юзера и пароль, но я указал настройки для входа по ключу. Для этого зайдем по SSH на сервер, куда мы будем деплоить проект и создадим связку ключей: ssh-keygen -t rsa -b 4096 -C "[email protected]" cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys Скопируем приватный ключ cat ~/.ssh/id_rsa Теперь нужно заполнить секретные ключи в GitHub. Переходим в наш репозиторий: Settings -> Secrets and variables -> Actions и добавляем наши секреты: HOST - хост сервера PORT - порт сервера KEY - скопированный ранее приватный ключ USERNAME - имя пользователя на сервере Создаем баш-скрипт .scripts/deploy.sh для запуска консольных команд, которые мы создавали в начале статьи. #!/bin/bash set -e echo "Deployment started ..." git pull php console cache:modification php console cache:clear echo "Deployment finished!" Тут мы забираем все изменения из git-репозитория и чистим кеши нашими консольными скриптами. Сюда можно добавить команду для включения режима обслуживания на время деплоя, но это оставлю вам для самостоятельного выполнения. Разрешаем запуск данного скрипта chmod +x deploy.sh Окончательная структура директорий Теперь мы можем запушить новые изменения в репозиторий и увидим, как во вкладке Actions на GitHub появится новая задача. Мы можем нажать на нее и посмотреть детально на все происходящие процессы в контейнерах. Если произойдет ошибка, то вам на почту придет письмо, что Action завершился неудачно. Сюда также можно добавить проверки на codestyle, запуск тестов и построить полноценное CI/CD, но это пока не про Opencart...

Если вы до сих пор в качестве тестовой среды используете OpenServer или Хостинг+FTP, а единственным инструментом для дебага является var_dump, то самое время попробовать Docker и xDebug. Docker - ПО для запуска сервисов в изолированных контейнерах. Т.е. для запуска приложения мы можем создать необходимое количество контейнеров: веб-сервер, интерпретатор PHP, запустить базу данных. Нам не нужно захламлять систему всеми этими сервисами, все будет установлено внутри докера. При этом мы можем использовать для разных проектов разный набор версий php, mysql и т.д. В отличии от полноценных виртуальных машин (VirtualBox + Vagrant) нам не нужно скачивать образ операционной системы и ставить каждый раз полноценные версии сервисов. В докере используются облегченные версии ПО и если в одном проекте вы уже использовали PHP 7.3, то для другого проекта не нужно будет ничего качать и заново пересоздавать. Вместе с Docker мы будем использовать дополнительный инструмент од названием Docker Compose. Он помогаем с помощью одного конфигурационного файла управлять группой контейнеров. Вместе с Docker мы будем использовать дополнительный инструмент од названием Docker Compose. Он помогаем с помощью одного конфигурационного файла управлять группой контейнеров. Что мы установим для нашего проекта: PHP-FPM 7.3 Nginx MySQL 5.7 Adminer С докером определились, он поможет за 5 минут создать тестовое окружение с нужным набор сервисов. XDebug - дополнение к PHP, которое помогает производить отладку и профилирование кода. В статье будет описана работа совместно с IDE: PhpStorm и VS Code. Приступим к практике. Установка Docker Docker: https://docs.docker.com/get-docker/ Docker Compose: https://docs.docker.com/compose/install/ Надеюсь, git у вас уже установлен (если нет, читайте блог https://opencartforum.com/blogs/entry/326-git-i-opencart-dlya-samyh-malenkih). Переходим в директорию проекта и клонируем репозиторий: git clone [email protected]:ozzzi/docker-opencart.git . В данном репозитории содержится конфигурация для запуска Opencart. Структура директорий: db - файлы базы данных hosts - конфигурационный файл nginx. Конфигурационный файл настроен на использование домена oc.dev images - файлы для создания образов Dockerfile - файл конфигурации образа php.ini - конфиг PHP mods - директория для загрузки конфигов дополнений logs - логи различных сервисов. По умолчанию настроен только лог для Nginx .env - переменные окружения (в нем хранятся конфиги для MySQL). docker-compose.yml - конфигурационный файл Docker Compose Разберем файл docker-compose.yml services - список сервисов (контейнеров). Для каждого сервиса (nginx, mysql и т.д.) принято создавать отдельный контейнер. Список основных директив: image - образ для создания контейнера. Образы хранятся тут: https://hub.docker.com build - путь к Dockerfile для создания кастомного образа. Например, для PHP нам нужно установить ряд дополнений, поэтому нам нужно создать собственный образ. MySQL, Nginx мы вполне можем использовать без изменений. container_name - имя контейнера ports - пробрасываем порты из контейнера на порты локального компьютера (порт компьютера:порт контейнера). volumes - связываем папки на локальном компьютере и директории в контейнере. Используем для пробрасывания конфигов и файлов в контейнер, а также для сохранения данных сервисов в контейнере после перезагрузки (базы данных и т.д.). Перейдем к настройке PHP в Dockerfile-е. FROM - импортируем базовый образ из docker hub. RUN - запускаем консольные команды Linux внутри контейнера для установки нужных пакетов: curl, zip и т.д. ADD - импортируем файлы конфигов php и конфиг xDebug в контейнер WORKDIR - рабочая директория Команды для управления нашими контейнерами: docker-compose up - запуск контейнеров docker-compose up -d - тоже самое, но можно не держать открытым окно терминала docker-compose up -d --build - собираем проект и запускаем, после внесения изменений также нужно запускать с данным ключем. docker-compose stop - останавливаем контейнеры docker-compose down - останавливаем и удаляем контейнеры docker-compose ps - выводит список запущенных контейнеров Установка опенкарт Файлы движка нужно закинуть в директорию www/oc.dev. Чтобы домен был доступен по адресу oc.dev, нужно править файл hosts: Ubuntu: sudo gedit(ваш текстовый редактор) /etc/hosts Windows: windows\system32\drivers\etc\hosts Вносим запись: 127.0.0.1 oc.dev Данные для доступа к базе данных хранятся в файле .env (название базы, пользователь и пароль), а в качестве имени хоста мы используем имя контейнера базы данных: db. Устанавливаем Opencart как обычно. сли у вас есть проблемы с доступом к файлам и папкам (логи, кеш), вам помогут эти команды: sudo chown -R $USER:$USER directory - устанавливает текущего пользователя владельцем директории (в контейнере скрипты исполняются от пользователя www-data) sudo chmod -R 777 directiroy - права 777 для директории Настройка xDebug Файлы конфигурации хранятся по адресу: /images/php/mods/xdebug.ini Здесь нас интересует одна опция xdebug.remote_host. В ней нужно указать ip-адрес контейнера. Для Windows и Mac можно указать равным host.docker.internal Для Linux на запущенном контейнере набираем в консоли: docker inspect php-fpm | grep IPAddress Полученный IP прописываем в конфиг xdebug.ini, в моем случае: xdebug.remote_host = 172.25.0.2 (или 172.25.0.1, если не заведется отладчик) Остановим и перезапустим наши контейнеры с опцией --build. Настройка PHPStorm для работы с xDebug 1. Заходим в меню Run/Edit Configuration. Добавляем тип конфига "PHP Remote Debug" 2. Нужно добавить Server Name - имя сервера вводим любое. Нужно поставить галочку Use path mappings, значения должны быть такими: слева (File/Directory) - путь до папки на локальном компьютере, куда копировали Opencart. справа (Absolute path on the server) - путь внутри контейнера: /var/www/oc.dev 3. Заполняем название конфигурации (любое). Вносим метку, на которую будет реагировать IDE: PHPSTORM. 4. Проверим работу xDebug нажатием на ссылку Validate. Приступаем к отладке Для примера мы хотим узнать, какие модули отображаются на главной странице в позиции Top. Открываем файл catalog/controller/common/content_top.php. Нас заинтересовала строка 49, в которой можно посмотреть код модуля. Возле номера строки ставим точку остановки (Breakpoint) левой кнопкой мыши. Чтобы вызвать работу отладчика выбираем конфигурацию, которую мы добавилил в 3-м пункте, жмем на Debug 'Docker' (зеленый жук) в панели справа,сверху и включаем прослушку Start Listaning for PHP Debug Connections (трубка). Обновляем главную страницу сайта. Должен сработать отладчик и вы увидите: Окно отладки: 1. Данной кнопкой можно поменять брекпойнты и вернуться назад к отладке. 2. Кнопка просмотра точек остановки. 3. Синие стрелки вверх/вниз позволяют пробегать построчно по коду (вверх/вниз) 4. Все доступные переменные на момент остановки скрипта. 5. Стек вызова - можем проследить полный путь вызова. В окне отладки мы видим все доступные переменные в указанной нами точке. Мы поставили точку в цикле и скрипт останавливается в первой итерации. Но если мы хотим посмотреть значения переменных в определенной итерации, нажмем правой кнопкой мыши на точке остановки и зададим условие для ее срабатывания. В моем случае остановимся, когда отображается модуль Featured. Настройка VS Code для работы с xDebug 1. У вас должно быть установлено дополнение PHP Debug 2. Breakpoints ставятся возле нумерации строк. 3. Включаем окно отладки (Ctrl + Shift + D) и нажимаем на ссылку create a launch.json file. Код launch.json { "version": "0.2.0", "configurations": [ { "name": "Listen for XDebug", "type": "php", "request": "launch", "port": 9000, "log": true, "externalConsole": false, "pathMappings" : { "/var/www/oc.dev/": "${workspaceFolder}" } } ] } 4. Отладка: Запуск отладчика Панель управления. Здесь также можно остановить и обновить отладку, а также пробежаться по строчкам кода. Здесь отображаются все переменные. Стек вызова. Надеюсь, что эти советы помогут вам вести более продуктивную разработку и отладку кода.

Я получил некий фидбэк от прошлой статьи, и меня просили сделать более подробный гайд по инициализации и установки git. Итак дано чистый сервер с установленным opencart. Для начала нам нужно установить git, так как я на сервере использую ubuntu я воспользуюсь командой, внимание git должен быть установле везде где вы работает с кодом, будь то это продакшен(боевой) сервер тестовый или локальный пк apt install git на вашем же сервере используется другой пакетный менеджер, вам нужно установить с помощью него в centos например это yum install git На локальном пк можно под windows можно установить данных софт gitforwindows Далее нам по хорошему зарегестрировать на одном из сервисов это может быть github или gitlab я использую в большей степени последний. С регистрацией там все просто. Далее нам нужно создать новый репозиторий кликаем по New project пишем название репозитория, обычно это название сайта, по желанию пишем описание проекта, и выбраем каким будет репозиторий приватным или публичным. Далее gitlab нам сам предлагает, что нужно сделать для инициализации git для начала устанавливаем глобальные конфиги, чтобы видеть кто и его контакт для связи, обычно это операция делается один раз после установки git Переходим в консоль, в моем случае это наш тестовый сервер и пишем последовательно 2 команды далее, так как у нас уже развернут opencart первый вариант который предлагает нам gitlab не подходит, нам больше подходит второй варинат. Но все по порядку для начала перйдем в папку с нашим проектом cd /path/to/you/site итак мы в корневой дирректории нашего сайта теперь мы проинициализируем git командой git init gttи Далее можем сразу указать удаленный репозиторий как нам и предалагает gitlab Далее мы создаим файл .gitignore в него нужно прописать файлы и папки которые мы не хотим загружать в репозиторий который гит будет игнорировать и не будет трогать не при каких обстоятельствах, например config. не нужно чтобы кто-то знал пути и достпы к бд сайта или любых других подключений создаем файл любым удобным для вас образом я воспользуюсь консолю берем за основу gitignore из официального git репозитория opencart но с некоторой модификацией ссылку на файл осталю конце статьи Далее нам нужно добавть содержимое рабочей директории в индекс (staging area) для последующего коммита. git add . пишем команду чтобы все файлы добавить в индекс ну и сделаем наш первый комит git commit -m "Initial commit" Готово теперь у нас есть комит можем его залить на удаленный репозиторий git push -u origin master но при попытке запушить, возникает ошибка, а все потому что мы не настроили общение gitlab и нашего сервера по ssh ключам, сейчас мы это исправим Для начала нам нужно сгененрировать ssh ключ на сервере командой предварительно заменив email на свой ssh-keygen -t rsa -b 4096 -C "[email protected]" утилита предложит нам путь до файла оставляем по умолчанию, и ввести пароль для passphrase но он может быть пустым, его не обязательно заполнять. далее нам нужен публичный ключ его можно получить командой cat ~/.ssh/id_rsa.pub ну собственно куда ssh-keygen его и сгенерировал. Копируем наш ключ и идем в gitlab setting > ssh Добавляем наш ключик и делаем заново команду git push -u origin master и вуаля мы залили наш проект на сайт заметим что конфиги не попали в наш репозиторий. теперь мы имеем ветку master это ветку нажна только для продакшена в нее что либо комитить считается мовитоном, елси не идет стихийная разработка сайта. Давайте создадим dev ветку сайта в которой будут попадать все наши изменения для dev сервера. все ветка для разработки создана, теперь например у меня встала задача на сайте поманять фон на всем сайте и сменить подпись в футере сайта Для начала опишем эту задачу, идум в issue и создаем новое issue Назвать ишью лучше по порядку начиная с #1 #2 .... #90000 это удобно для самого gitlab чтобы закрыть ишью будет достаточно последний комит назвать "Close #issue" c числами же это проще всего. Итак ишью создано теперь я как разработчик клонирую репозиторий к себе не локальный пк командой git clone [email protected]:stick.qwe/opencart.git где ссылка на наш репозиторий произвожу настройку своей локальной среды разработки будь то openserver docker lamp xamp что угодно, для того чтобы развернуть сайт. Я буду использовать ide phpstorm вы же можете использовать любой редактор кода который вам нравится Для начала нам нужно переключиться на ветку dev далее нам нужно создать новую ветку с названием нашего issue отсавляем галочку на checkout branch в правом нижнем углу у нас нужная нам ветка сделанная из dev ветки начинаем выполнять нашу работу итак мы выполнили один пункт нашей задачи давайте закомитим его средствами phpStorm идем VCS -> git -> commit file Открывается окно в котором мы пишем название нашего коммита что мы сделали в этом изменении обычно я в начало добавляю так же название нашего ишью для систематизации мы видим в каких файлах были произведены изменения и что они верны жмем commit phpStorm говорит нам о warning в файле стилей не обращаем внимание, на это и жмем commit и продолжаем выполнять нашу следающую задачу задача выполнена, осталось только сделать последний commit идем туда же vsc->git->commit file называем его именно так тем самым помогаю gitlab самому за нас закрыть issue и нажимаем commit and Push мы видим наши коммиты и отправляем их на сервер и идем в gitlab и проставим галочки над выполненными задачами мы видим что содалась новая ветка нашего разработчика теперь нам нужно объеденить ветку #1 > dev а потом dev > master для этого нам нужно создать merge request Gitlab нам предлагает нашу ветку смержить из #1 в мастер но это не правильно, нам нужно смержить в dev нажимает в Change branches и меняем target branch на dev здесь в принципе ничего не меняем, ставим галочку на удаление исходной ветки и нажимаем sudmit merge request далее нажимаем merge так же не забываем закрывать наше issue кнопкой close issue теперь мы можем залить нашу dev ветку на дев сервер и оттестировать полностью, но так как сейчас у нас как бы ее нет, мы зальем наши правки сразу на продакшен сервер, но для начала создадим новый merge request теперь уже из dev > master делаем тоже самое с одним исключением это убираем галочку с удаления ветки merge request прошел успешно теперь у нас осталались 2 ветки с измененым кодом и нашими новыми коммитами далее мы идем на наш продакшен сервер переходим в папку с проектом и выполняем одну команду. git pull видим что наши файлы обновились проверяем в браузере вот видим наши изменения. Тоже самое и с дев сервером единственное перед pull необходимо сменить ветку на дев севрере git checkout dev и так же сделать git pull. Подытожим. Сегодня мы научились базовой работе с git и ведения проекта, это только базовые принципы работы с гит, его возможности куда больше, чем описно в статье, но не все сразу. как говорится ссылка gitlab репозиторий с .gitgnore https://gitlab.com/stick.qwe/opencart