EVMedvedev

Не говорите ерунды. Кому нежен сайт напримере Амазона без стоящего за ним бэкэнда. Это пустышка. Сайт Амазона стоит много только как часть их бизнеса, как часть того, что приносит прибыль. В противном случае домен очень быстро опустится ниже плинтуса. Его просто перестанут посещать, как только стане ясно что за ним ни чего нет. Уж если ни чего не понимаете в этом лучше помолчать.

В идеале - полностраничное кэширование. Здесь на форуме уже обсуждали как сделать ( ). Это не особо сложно. Тогда сможете и главную страницу сохранить в целости и скорость увеличить.

Так а кроме как под каждый поддомен загружать свой config, другого решения нет. Плодите конфиги с разными настройками, в которых прописаны разные пути к темам и т.п. и грузите их в зависимости от домена, с которого вошел посетитель.

Сначала разберитесь что продаете. Интернет-магазин - понятие растяжимое. Сайт ни кому не нужен. Так что если и возьмут, то только в случае если вы доплатите. Если юридическое лицо продаете, то надо оценивать его активы. А пока не поймете чем торгуете, клиентов не найти.

Так в налоговой отчитывается хозяйствующий субъект, а он может регистрироваться с одним видом налогообложения?

Заработок и длинный язык не одно и тоже :-).

А собственно не просил вас влезать в данную тему вообще. Как полагаю и все остальные участники. Так что поучить вас явно полезно. Не только программированию, но и вежливости. И как оказалось так думают многие на этом форуме. Так что, сударь, вы имеете честь быть посланным мной далеко и надолго :-). Спасибо

Сбросил контакт.

У вас серьезные запросы. Уточните потребности пожалуйста. Например нужно ли писать сбор статистики с нуля или можно попробовать перенести этот функционал с других движков (в Prestashop например есть модуль сбора статистики PHP+JS код. Можно попробовать перенести на ОС. Там статистики много собирается)? Как стоить аналитику по статистике (нужен конструктор отчетов или набор отчетов фиксированный? Почему именно специальная сборка нужна? Вы собираетесь ее тиражировать или вам нужен лишь один сайт на ней? Сборку сделать сложнее чем один сайт потому что как минимум нужно внимательнее относится и к организации кода и к его документированию. Ну и бюджет конечно в любом случае не маленький, но для создания сборки он может быть в разы больше чем для сайта?

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

Почитайте материал тыц и постарайтесь уточнить задание. Количество товаров и категорий дает слишком мало информации для разработчика.

Если магазин не работает пока, то можно отлаживаться на основном домене. Если магазин работает, то соответственно либо переносите код на локалку и отлаживаетесь там. Либо, если по каким-то причинам вам нужна точная копия операционной среды рабочего сайта, то тогда как раз самое подходящее - создать поддомен. На локальной машине и операционка может быть другая и версия PHP другая, политика безопасности другая и т.п. и все это может приводить к тому, что на локалке у вас все работает, а выносите не хост - сыпятся ошибки.

Twig не может быть сыроват. Он появился наверно еще до того, как работы над ОС начались :-). Может быть сыровато использование Твига в ОС.

Это стандартные дефекты архитектуры кода опенкарт. Избавиться от них разработчики смогут не скоро да и то, если перепишут его на чем то вроде ZF или Symfony, где валидация и конструирование форм вынесено в отдельные классы и в сервисы, где основной функционал контроллеров вынесен соответствующие базовые классы и т.д. и т.п., то есть действительно активно используются большинство паттернов ООП. Так что, если интересует ОС, придется с этим смириться.

Скорее всего в импорте где то используется функция striptags которая вырезает HTML тэги их контента. Надо ее убрать и будет вам счастье.

Стриминг и через Ютуб делается. У меня заказчик сам за полчаса сделал вещание для зоомагазина через него своего товара (террариум с богомолами). Камеру ему только настроили и вывесили в сеть. Там по сути только проигрыватель нужен, подключенный к нужному потоку. Для каждого товара сделать тоже не проблема, хотя возни с развертыванием и поддержкой такого пула камер будет довольно много. Да и движок возможно под проект стоит брать вообще не магазинный. Нужен ведь только каталог товаров по сути и сайт визитка. Можно найти что нибудь с редактором шаблонов типа MODx, чтобы можно было дизайн оперативно править с минимальными знаниями программирования.

Обшибся, каюсь. Не Action::execute, а скорее Front::dispatch. В других движках алгоритмы другие. Сначала работает routing, то есть разбор урлов, а уже потом запускается контроллер. Там уже поздно кэшировать. В этом смысле вы видимо имели ввиду "контроллер" это переменная $controller в index.php в которой и сидит объект класса Front. Тогда все верно.

Так написано же. Для полностраничного кэширования в Action (если точнее, то в Action::execute), чтобы даже URL не разбирать, если для него есть кэш. Для модели - в момент после сбора полного SQL-запроса и перед его исполнением. В первом случае делаем ключ для кэша из урла, во втором - из SQL-запроса. Обычная практика во всех движках. Кстати отсутствие в Opencart ORM движка для работы с базой данных, как например в Symfony, осложняет кэширование данных. В Symfony, а значит на всех системах на его основе, кэширование данных встроено в Doctrine централизовано.

Если поля выборочно пишутся или теряются, то соответственно либо проблемы сериализации и десериализации (данные из БД нужно преобразовывать в строку для записи в кэш и обратно в массив) либо потери данных в самом кэше.

Вместо кода контроллера нужен код модели, то есть то место, где формируется запрос к базе данных. Ключом данных в кэше является хэш SQL-запроса. Полностраничный кэш - это когда в кэше хранится весь HTML-код страницы. Тогда соответственно перехват страницы нужно делать на уровне роутинга. Например в Action, но получается опять же не в контроллере.

Формулировка некорректна, если речь идет о кэшировании запросов к базе данных. Нужно проверку вести в файлах model.

При заданной ТСом постановке задаче обсуждение потянет на целый мешок попкорна.

Каждый со скукой борется по своему. Не понравится результат - придет еще. Тогда и узнаем.

Да собственно phtml код тоже шаблонизатор. PHP изначально был именно шаблонный язык. ООП добавили оптом. Но вообще шаблонизаторов довольно много. Но вот Prestashop до селе использовал Smarty, а теперь его переписывают на Symfony и как следствие все переводится на Twig. Но вообще в конечном итоге шаблоны на Twig или Smarty в конечном итоге компилируются в стандартный phtml код который и используется для построения HTML кода.

Если бизнесмен не в состоянии организовать и оплатить работу по составлению ТЗ то он точно будет сидеть И я лично, да и многие из присутствующих, составлять ему компанию не желаю. С таким "предпринимателем" каши не сваришь.