Небольшие правки на сайте, шаблон BurnEngine (Opencart)

Начали взламывать сайт В логах наблюдаю попытки выполнить взлом через уязвимость SP Page Builder Дополнительно также есть сигнатуры взлома через уязвимость JCE (Joomla Content Editor) Помогите исправить это

Добрый день. Ищу разработчика для проекта TehnoVek / T-VEK. Нужно создать не просто красивый лендинг, а первый технический этап будущего интернет-магазина. Проект: TehnoVek / T-VEK Домен: tehnovek.com.ua Формат: физический магазин + сайт + мини-каталог + будущий интернет-магазин. Основное направление: электроскутеры, электротрициклы, электровелосипеды, мототехника, квадроциклы, запчасти, аксессуары, сервис, доставка, кредит/рассрочка. Нужно: WordPress + WooCommerce. Главная страница как лендинг. Каталог товаров. Товарные категории. Первые товары должны быть заведены именно как WooCommerce-товары, а не как простые блоки. Формы заявок: подобрать технику; узнать о товаре; кредит / рассрочка; доставка. Кнопки Telegram / Viber / WhatsApp. Горячая линия 0 800 108 100 в шапке, подвале и ключевых блоках сайта. Страницы: электроскутеры; электротрициклы; электровелосипеды; мототехника и квадроциклы; запчасти и аксессуары; сервис и поддержка; кредит и рассрочка; доставка по области; доставка по Украине; физический магазин; гарантия; контакты; блог. Базовое SEO. Мобильная адаптация. Быстрая загрузка. Подключение Google Analytics 4, Google Tag Manager, Meta Pixel, TikTok Pixel. Возможность будущей интеграции с CRM. Возможность будущего подключения Google Merchant Center. Возможность будущего AI-консультанта. Возможность масштабирования в полноценный интернет-магазин без полной переделки. Важно: сейчас сайт может стартовать как лендинг + мини-каталог, но технически он должен быть сделан так, чтобы через 3–6 месяцев его можно было расширить в полный интернет-магазин. Прошу ответить конкретно по пунктам: Работаете ли вы с WordPress + WooCommerce? Можете ли сделать лендинг, но на базе WooCommerce? Будут ли товары заведены как WooCommerce-товары? Можно ли будет потом добавить корзину, онлайн-оплату и полный каталог? Есть ли у вас опыт с интернет-магазинами, а не только с визитками? Делали ли интеграцию форм с Telegram, email или CRM? Можете ли сохранять UTM-метки в заявках? Можете ли подключить GA4, Google Tag Manager, Meta Pixel и TikTok Pixel? Можете ли сделать базовую SEO-структуру? Будет ли сайт быстрым и нормально работать на телефоне? Можно ли будет потом подключить Google Merchant Center? Можно ли будет потом подключить CRM, например KeyCRM или SalesDrive? Смогу ли я сам добавлять товары после запуска? Дадите ли короткую инструкцию, как добавлять товары и редактировать страницы? Будет ли техническая поддержка после запуска? Какие примеры похожих работ можете показать? Какой ориентировочный срок первого этапа? Какая ориентировочная стоимость первого этапа? Что конкретно входит в эту стоимость? Как вы предлагаете разбить работу на этапы и оплату? Контрольный вопрос: Как вы технически сделаете сайт сейчас как лендинг + мини-каталог, чтобы потом не переделывать его с нуля, а расширить в полноценный интернет-магазин? Для меня важно не просто “красиво”, а правильно заложить фундамент будущей TehnoVek Commerce Platform: сайт, товары, заявки, CRM, реклама, доставка, кредит/рассрочка, аналитика и дальнейшее масштабирование.

Необходимо внедрить на сайтах OpenCart (3 шт) полноценный механизм управления согласием на использование файлов cookie (Cookie Consent) и настроить Google Consent Mode v2. Необходимо: установить и настроить CMP (Cookie Management Platform) или другое решение для управления согласиями пользователей; реализовать полноценный баннер Cookie Consent с возможностью принятия, отклонения и настройки категорий cookie; настроить Google Consent Mode v2 через Google Tag Manager; обеспечить корректную передачу статусов согласия в Google Analytics 4, Google Ads, а также в другие маркетинговые сервисы; настроить работу аналитических и рекламных тегов таким образом, чтобы они запускались только в соответствии с полученными разрешениями пользователя. В настоящее время баннер cookie является лишь информационным и не управляет согласиями, а также не передает их статус в Google-сервисы. Необходимо выполнить полную настройку в соответствии с актуальными требованиями GDPR и Google Consent Mode v2.

Нужен опытный OpenCart-разработчик для принятия проекта и дальнейшей поддержки Ищу опытного программиста OpenCart (не студию), который поможет профессионально принять интернет-магазин от текущего разработчика и далее будет заниматься его поддержкой, развитием и SEO-оптимизацией. О проекте Интернет-магазин на OpenCart. Проект готов примерно на 99% и проверен в соответствии с техническим заданием. Необходимо провести независимый технический аудит перед окончательной передачей сайта. После завершения передачи планируется долгосрочное сотрудничество по развитию проекта. Основные задачи Провести аудит кода и структуры проекта. Проверить качество реализации функционала. Проверить установленные модули, их совместимость и корректность работы. Оценить безопасность и стабильность работы сайта. Проверить быстродействие и предложить рекомендации по его улучшению. Проверить реализованную SEO-часть и предложить дальнейший план оптимизации. Убедиться, что проект полностью готов к самостоятельной поддержке без зависимости от предыдущего разработчика. Проверить корректность передачи всех доступов: исходный код; база данных; FTP; хостинг; домен; электронная почта; административная панель; установленные модули и их лицензии. При необходимости участвовать в коммуникации с текущим разработчиком во время передачи проекта. Предоставить перечень рекомендаций и замечаний перед окончательным принятием. Дальнейшее сотрудничество После принятия сайта планируется регулярная работа над проектом: развитие нового функционала; SEO-оптимизация; улучшение быстродействия; интеграции с внешними сервисами; техническая поддержка. Требования к кандидату Нужен специалист, который: имеет значительный опыт работы именно с OpenCart; хорошо знает архитектуру OpenCart и популярные модули; имеет опыт аудита и поддержки существующих проектов; может аргументированно оценить качество выполненных работ; ответственно относится к договоренностям и соблюдает согласованные сроки выполнения работ; заинтересован в долгосрочном сотрудничестве. В ответе прошу указать опыт работы с OpenCart; примеры реализованных интернет-магазинов; выполняли ли вы техническое принятие или аудит чужих проектов; ориентировочную стоимость: технического аудита; участия в принятии проекта; почасовой или проектной поддержки после передачи. Предпочтение отдам специалистам, которые имеют многолетний опыт работы с OpenCart, ответственно относятся к своей работе, соблюдают согласованные сроки и готовы стать техническим партнером проекта на долгий срок.

Разработка архитектуры единой платформы управления флотом WordPress-сайтовКонтекст проекта Есть флот из нескольких десятков WordPress-сайтов, размещённых на одном сервере и обслуживаемых одной командой. Сайты постепенно переводятся на единый стандарт разработки и поддержки — общую дизайн-систему с единой библиотекой блоков (ACF + Gutenberg) и единый стандарт безопасности. Требуется архитектура платформы для централизованного управления этим флотом.Задача Нужна разработка технической архитектуры единой платформы управления флотом WordPress-сайтов. Платформа — это не дашборд метрик, а полноценная система централизованного управления и доступа.Требования к платформе Единый вход для супер-администратора — одна точка входа для управления всеми сайтами флота: обзор состояния, версий, статуса соответствия стандарту. One-click доступ в админку каждого сайта — возможность зайти в wp-admin любого сайта флота из единого интерфейса, без хранения/ввода паролей от каждого сайта отдельно. Требуется продуманный механизм аутентификации (токены с ограниченным временем жизни, привязка к конкретному пользователю, полное логирование доступа). Разграничение ролей: супер-админ видит и управляет всем флотом; администраторы отдельных сайтов имеют доступ только к своим сайтам. Единая дизайн-система с кастомизацией на уровне сайта — общая библиотека блоков (ACF + Gutenberg), дистрибутируемая на все сайты через центральный механизм обновлений, но с возможностью локальной кастомизации блоков под конкретный сайт без потери совместимости с будущими обновлениями библиотеки. Общий дашборд мониторинга и оповещений — состояние сайтов и сервера, алерты о падениях/проблемах, статус обновлений и compliance каждого сайта относительно единого стандарта. Удобное добавление новых сайтов в сеть — платформа должна поддерживать быстрое клонирование/разворачивание нового сайта на основе единого стандарта (Core-плагин, дизайн-система) и подключение его к Hub с минимальным количеством ручных шагов.Архитектурные ограничения (важно) WordPress Multisite не рассматривается и не подходит для этой задачи. Причина не в удобстве интерфейса, а в фундаментальных архитектурных свойствах Multisite: Общая база данных и общее ядро для всех сайтов сети означают единую точку отказа: некорректное обновление плагина или ядра способно одновременно вывести из строя все сайты сети, а не один. Общий пул серверных ресурсов (PHP-воркеры, соединения с БД) означает, что аномальная нагрузка на один сайт (акция, всплеск трафика, атака) деградирует производительность всех остальных сайтов сети, включая никак не связанные с этой нагрузкой. Это системное свойство Multisite, не устраняемое процессом или дисциплиной — поэтому требуется архитектура, где каждый сайт остаётся независимой инсталляцией (собственная БД), а унификация и централизованное управление достигаются другими средствами.Предварительное архитектурное направление На данный момент наиболее перспективным представляется архитектурный подход Hub & Spoke, при котором независимые WordPress-инсталляции ("Spokes"), каждая со своей БД, объединяются: общим дистрибутируемым Core-плагином (библиотека блоков, security baseline, bridge-модуль для связи с Hub); центральным управляющим приложением ("Hub") — реестр сайтов, one-click login, мониторинг, оповещения. Однако данная архитектура не является заранее выбранным решением. Если исполнитель считает, что существует более подходящий архитектурный подход, он может предложить альтернативу при условии её технического и экономического обоснования. Отдельная задача в рамках ТЗ — обоснованный анализ и рекомендация: строить Hub с нуля кастомно, либо взять за основу готовое self-hosted решение (MainWP, InfiniteWP, ManageWP или аналоги) и расширять его под специфичные требования (интеграция с Core-плагином, compliance-отслеживание версий блоков, будущий маркетинговый слой). Нужна сравнительная оценка по срокам, стоимости поддержки, гибкости и ограничениям каждого варианта, с чёткой рекомендацией.Архитектурные требования При проектировании решения необходимо учитывать следующие нефункциональные требования: отказоустойчивость и отсутствие единой точки отказа для флота сайтов; возможность независимого обновления, отката и обслуживания каждого сайта; минимизацию blast radius при сбоях и ошибках обновлений; возможность горизонтального масштабирования при росте количества сайтов; безопасность централизованного управления и делегированного доступа; возможность последующего выделения Hub в отдельную инфраструктуру без изменения архитектурных принципов; расширяемость платформы для добавления новых централизованных сервисов. Кроме того, архитектура должна оставаться жизнеспособной при увеличении количества сайтов с нескольких десятков до 100+ без необходимости принципиального пересмотра выбранного подхода.Долгосрочное развитие платформы Платформа рассматривается как долгосрочная основа цифровой экосистемы компании, а не как инструмент исключительно для администрирования WordPress-сайтов. При проектировании необходимо предусмотреть возможность последующего добавления централизованных сервисов (например, управления маркетинговыми активностями, аналитикой, библиотекой компонентов, интеграциями и других модулей) без необходимости переработки базовой архитектуры.Технологии Конкретный стек не фиксируется заранее — исполнитель самостоятельно предлагает и обосновывает технологии в архитектурном документе (язык/фреймворк для Hub, модель хостинга/деплоя, механизм аутентификации и т.д.), исходя из требований задачи. Обоснованное предложение по технологиям — обязательная часть результата работы, наравне со сравнением custom vs готовое решение для Hub.Что нужно от исполнителя Опыт проектирования multi-site/multi-tenant архитектур на WordPress (принципиально — НЕ на базе Multisite) Практический опыт работы с MainWP/InfiniteWP/ManageWP или аналогичными системами управления флотом WP-сайтов — понимание их возможностей и ограничений на уровне API/расширяемости Опыт разработки WordPress-плагинов уровня production (ACF, Gutenberg block development, REST API) Понимание вопросов безопасности при построении систем централизованного/делегированного доступа (token-based auth, аудит доступа, минимизация blast radius) Умение подготовить архитектурную документацию: диаграммы, API-контракты между Hub и сайтами, схему данныхФормат работы Первый этап — архитектурный документ с обоснованным решением (custom vs готовое решение), схемой взаимодействия компонентов, API-контрактом Hub ↔ Core-плагин, планом поэтапной реализации. Документ должен включать вайрфрейм-схему интерфейса платформы (ключевые экраны: реестр сайтов, доступ в админку, дашборд мониторинга). По итогам согласования архитектуры — возможно продолжение сотрудничества. Важное замечание Ожидается самостоятельная архитектурная проработка, основанная на практическом опыте проектирования и эксплуатации подобных систем. Недостаточно предоставить компиляцию общих рекомендаций или типовых ответов, сгенерированных ИИ. Каждое ключевое архитектурное решение должно сопровождаться техническим обоснованием: почему выбран именно этот подход, какие альтернативы рассматривались, каковы его преимущества, ограничения и потенциальные риски в контексте данного проекта. При необходимости исполнитель должен ссылаться на практический опыт, существующие решения, документацию, open-source проекты или иные источники, подтверждающие жизнеспособность предлагаемых архитектурных решений.