EVMedvedev

Получается наоборот . Чем больше репа, тем больший флудераст ее обладатель . Механизм присвоения репы здесь некудышный. Лучше ее убрать и пусть каждый сам читает посты авторов и выносит свое суждение.

Да, тоже частый вариант . Бываю еще горе SEO-оптимизаторы и SEO-продвиженцы, которые умеют вроде как настраивать рекламу в поисковиках, но не более.

Простой заказ на ОС за 60 тыс рублей - это сказка. На ОС в первую очередь идут заказчики ради дешевизны, которая во всем самая низкая. То есть тут собираются в основном заказчики либо из неудачников, у которых торговля сыпется и они надеются на чудо задарма благодаря созданию "продающего" сайта (который за них все сделает, а они будут только капусту собирать), либо начинающие заказчики (могут быть даже с очень приличными деньгами), которые пока не знают как управлять проектом создания серьезного сайта и поэтому надеются получить первый опыт как можно дешевле ( минимизируют потери в случае провала проекта).

Я сейчас пишу одно приложение, где клиентская часть полностью построена на JS. Там у меня все переходы между страницами (интерфейсами) сначала строятся на клиенте средствами JS, а потом уже подкачиваю данные с сервера. Средствами JS можно делать редиректы между страницами. Это на самом деле несложно.

Если верстка будет выполнена в виде набора HTML станиц с минимальным набором js кода для демонстрации, тогда переносить все это на дефолтный шаблон ОС будет самым сложным и самым дорогостоящим вариантом. Просто учтите это. Перенос фотошоповских макетов на дефолтный шаблон ОС в разы дешевле.

Ну если почитать ТЗ там есть требования, которые могут у многих вызвать определенные сомнения.

Тогда возможно дело не в сбросе сессии, а именно в разлогинивании? Может где то идет редирект на логаут?

Может есть какие то настройки хранения сессий, о которых вы не упомянули. Например если вы храните сессии в memcached, а он дурит или модули PHP для работы с memecached сервером дурит. Я с таким сталкивался. К тому же для записей в memecached есть ограничения на размер. Другое направление поиска проблемы - время хранение куков. Если в них не сохраняется идентификатор сессии, то сервер не найдет нужную сессию и создаст новую. Есть еще предположение в догонок. Если например у вас не настроены правильно права доступа для апаче и PHP на диск для сохранения файлов сессий, то они могут не сохраняться и тогда будет такой же эффект как вы описали. Но это только предположение. Просто из базового алгоритмы работы WEB приложения с сессиями.

Если я правильно помню, то с односложным именем домена есть проблемы при сохранении куков. При установке некоторых движков сразу предупреждают что доменное имя должно иметь 2 уровня. Поэтому обычно прописывают доменное имя в файл hosts с указанием IP 127.0.0.1 а в настройках апача (nginx) создают под это домен конфигурацию. Вот такое есть в сети Источник https://forum.ixbt.com/topic.cgi?id=24:20822

Ну отказ от ПО типа Битрикс в пользу ПО с открытым исходным кодом с точки зрения большинства разработчиков - дело богоугодное и часто выгодное, потому что в случае с Битриксом вы платите за лицензии. К тому же часто разработчик на Битрикс стоит дороже, при той же квалификации что и разработчик для бесплатного ПО (наверное сказываются повышенные затраты на освоение ПО к которому в любом случае осложнен доступ). А вот стоит ли конкретно для ваших задач брать именно ОС - вопрос неоднозначный. Если приоритет отдается торговле, то магазинный движок естественно предпочтителен. А вот если ваша деятельность в первую очередь ориентирована на сбор и обработку заказов на оборудование, то возможно стоит взять что-то другое, что проще переделать под вашу специфику работы (аренда оборудования ближе к бронированию размещения и т.п., но не к торговле).

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

А вот по договору надо будет выставлять счета для оплаты. Счет не чек. Это разные вещи.

Ну да. Я меня тоже самое. Только я занимаюсь не перевозками, а программированием и консалтингом. Сделал, работу без договора (например срочную), называю заказчику сумму, он платит и получает от меня чек, как мое подтверждение факта приема от него денег. Ну тут у ТС все нормально. Он хорошо все пояснил.

Так чек вроде выставляется по получении денег? Это счет выставляется под договор для оплаты, то есть до получения денег. И разве самозанятым можно торговать? Вроде только услуги оказывать.

Ну репа на данном форуме чаще всего не за помощь дается и поэтому не отражает профессионализма ее обладателя.

@magecode Да вы с Yoda не парьтесь :-). Эта статья ведь не для вас а для профессионалов или тех, кто хочет стать такими.

На самом деле вопрос поставлен не совсем корректно. Docker ну и др. виртуальные машины, нужны не для какого то движка, а для удобства разработчиков при работе в определенных условиях. Например если работает группа разработчиков над сложным и активно посещаемым сайтом, то организация работы будет другой. Команда должна развернуть репозитарий на гите, с репозитария раздать всем кодерам копию кода и настройщик среды, в которой крутиться сайт на продакшене (докер файл). Кодеры восстанавливают среду у себя на виртуальных машинах, кодят и комитят изменения на гит. После решения задачи делается копия продакшн сервера на отладочный и проводится операция апдейта копии рабочего сайта с гита (деплой). Если все проходит нормально, то продакшн сервер останавливается на короткое время и с гита деплоятся изменения, в расчете на то, что на продакшн сервере все сработает так, как это было на отладочном. Другое дело, что такие проекты на Опенкарт не делаются (он для этого просто не предназначен) и в этом случае вы правы - такие сложные вещи для ОС не нужны.

Эти дежурные фразы есть в любой статье по minikube :-). Может вы можете рассказать чуть больше? В чем это большее удобство заключается. А зависимость от чего либо есть практически всегда. Не питон, так руби. Не руби, так NodeJS и т.д.

А что это дает?

Если вы в чем то не разбираетесь, то это еще не значит, что это плохо вообще. Это плохо только в ваших глазах. Кстати использование ORM еще позволяет и избавить ОС от спагетти кода работы с данными, размазанного между двумя разделами (catalog и admin). Это такой отстой, который кажется остался только в ОС.

Применение то же Doctrine дает 2 очевидных выгоды. Во-первых это действительно может дать ускорение работы хотя бы уже потому, что в этой библиотеке есть средства кэширования работы непосредственно с базой данных. Во-вторых, возможность ОС работать на разных СУБД, потому что если оперировать только ORM объектами при разработке своего кода, то дальше можно подключать разные библиотеки перевода объектной модели в запросы к разным СУБД и не только реляционные (поддерживается например MongoDB). В Doctrine есть и еще одна фишка, которую тоже можно было бы использовать для ускорения системы. Можно добавлять атрибуты в специальную таблицу, на основании которой регенерировать классы сущностей Doctrine, с помощью которых регенерировать таблицы хранения данных товаров, категорий, клиентов и таким образом добавлять любые типы полей. То есть сделать механизм, аналогичный Мадженто, который позволяет хранить данные о товарах в плоских таблица, что значительно ускоряет работу с базой данных.

Ну собственно ORM предполагает использование какого-то QueryBuilder, чтобы трансформировать объектную модуль в SQL запросы. Это бы ОС точно не помешало. Пора уже как то разработчикам ОС двигаться хотя бы в 20 век, а то уже на дворе 21 :-). И уж лучше бы взять какую нибудь вменяемую ORM-библиотеку вроде Doctrine. Да и вообще можно больше компонентов и решений от Symfony позаимствовать.

Не понял о каких слоях идет речь. В нормальном движке, разработанном в соответствие с общепринятыми стандартами разработки софта, композера вполне достаточно для добавления и обновления пакетов. Все системы, разработанные например на базе Symfony прекрасно так работают. Собственно композер как менеджер пакетов для этого и нужен. Другое дело что пока это ОС не касается в полной мере.

Стоит продолжить освоение темы. При работе с Magento 2 я столкнулся с одной компанией, профессионально разрабатывающей модули под эту платформу, так вот они через свой репозитарий организовали автоматическое обновление модулей. В Мадженто 2 есть возможность обновлять движок и сторонние модули через composer, так вот эта команда организовала так, что с их репозитория можно обновлять модуль, но при условии, что вы оплатили поддержку. То есть они организовали репозиторий с билингом. Правда кажется они поднимали свой репозиторий на Satis. Кстати и бесплатные модули из магазина приложений Мадженто тоже композером устанавливаются на автомате. Удобно.

Отсутствием в ОС соответствующих возможностей для этого, таких как: многоуровневое кэширование от данных до готовых HTML блоков недостаточно оптимизированная модель данных (сложная структура таблиц, из-за необходимости использовать универсальные способы перевода контента или описания атрибутов) отсутствие возможностей использования кластеров БД (распределения чтения данных между несколькими СУБД)