ozzzi

Здравствуйте. Можно через личные сообщения.

Залил обновленную версию. Добавил укр локализацию. Дополнительное отключаемое поле Год.

Это одинаковые модули, то я не совладал просто с english translation.

Та надо наверное выложить, пылиться файл....

Здравствуйте. Добавил поле "Год" в фильтр. Плюс баги.

Такое сделать можно, но ванговать не буду. Нет времени даже уже готовую новую версию выложить...

Где именно добавить? При выборе модели с главной такое есть.

Здравствуйте. Сперва нужно посмотреть лог модификаторов. Особо внимательно на кеш сео-компонентов, применился ли весь код из модификатора модуля.

Здравствуйте. В случае с опенкартом всегда есть вероятность. конфликта модификаторов, напишите в личку.

Вы когда-нибудь забывали внести изменения в базу данных после публикации нового функционала? А еще эти кеши модификаторов, которые нужно не забыть обновить. В этой статье я опишу, как автоматизировать процесс деплоя проекта и избавить себя от рутины. Данная статья предполагает, что вы используете 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...

Прикрепить деталь к авто можно как вручную: создав всю базу нужных авто и в товаре выбирать нужные модели. Или же можно импортировать CSV файл, в котором будут прописаны те же данные: автомобиль - артикул товара.

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

Это настройки из модуля, раздел "Общие настройки SEO для модели". Посмотрите, у вас есть этот раздел, заполнен ли он?

Здравствуйте. faq, faq_description, faq_categories, faq_cat_descriptions, faq_to_categories - данные таблицы создаются.

Попробую на выходных возобновить процесс.

Здравствуйте. Могу записать в список пожеланий.

Я работаю над этим, но времени мало. Процентов 75% сделано.

Для этого в модуле есть импорт/экспорт.

Здравствуйте. База автомобилей - это бонус в виде sql-файла, который нужно импортировать в базу посредством PhpMyAdmin или любого другого MySQL-клиента.

1. Если вам интересно консольные скрипты писать в рамка движка Opencart - пожалуйста... 2. Я описываю суть, а не полную конкретику. Думаю, что вы без меня знаете, как писать SQL-запросы.

Для вас, как для владельца магазина, это позволит сделать "отзывчивый" магазин для клиента и удобный для менеджеров: выгрузить, импортировать что-то тяжелое можно будет нажатием условной кнопки. Но есть и минус: все это кто-то должен поддерживать, а первый попавшийся opencart-программист не факт, что захочет лезть в эти дебри.

Я хочу затронуть тему очередей, которые используются повсеместно в интернет-проектах, но в 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 Если вам скучно, обязательно попробуйте очереди.

Можно. Но это уже будет отделенная от опенкарт архитектура.

Чтобы в мета теги можно было вносить всякие эмодзи: 1. Для этого нужного в базе данных для нужного поля поменять кодировку на utf8mb4_general_ci 2. В системном классе по работе с базой: system/db/mysqli (или другой): $this->connection->set_charset("utf8mb4");

Здравствуйте. Это товар, который подходит ко всем авто данной категории.