OtezVikentiy

Вот да, не раздражайте, пожалуйста.

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

это кому адресовано?

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

/catalog/controller/common/menu.php У вас в этом файле на 32 строке идет обращение к объекту (скорее всего модель), которая не загружена. Соответственно дергается метод не загруженной модели. Видимо какой-то модуль встал криво (модификатор не нашел нужной строки куда впилиться).

Делать маркетплейс на опенкарте имхо так себе идейка... Какое количество товаров вы планируете вообще прогружать в движок?

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

Выглядит так, будто бы seopro ищет файл кэша которого нет... Собственно в эту сторону и надо идти xdebug'ом

@Otche94 видимо владелец Ozon/Беру раз у него такой объем трафика без рекламы Даже для месячного интервала пара лямов - это много прям как-то выглядит. @Otche94 Какая у вас ниша то для такого трафика? Монополия в чем-то что ли?

Ну смотрите... Разработчик и пользователь зачастую говорят на разных языках, для пользователя выглядит как яблоко - для разработчика - как набор нано-частиц собранных в определенной последовательности. Если простым языком - то чем менее детальное ТЗ - тем больше шансов встрять в ситуацию, когда разработчик будет говорить "это не входило в стоимость изначальных договоренностей" - и будет собственно прав на самом то деле, а вам будет казаться, что вас "нагревают". Не спорю, бывают и такие, кто нагреть заранее планируют, но такие не все... Соответственно, чтобы разработчик мог хоть как-то ориентироваться в стоимости и объеме тех работ, которые ему предстоят - необходимо ТЗ. Чем подробнее вы опишете ТЗ - тем меньше вероятность, что вы столкнетесь с какими-то трудностями и недоразумениями. В части опенкарта тоже довольно всё просто на самом деле. Можно делать подходы итеративно: 1) выбираете шаблон и набор модулей, которые реализовывают функционал, который вы хотите видеть. Соответственно в ТЗ пишете - хочу, чтобы это было установлено. Разработчик говорит "ОК" и озвучивает ценник. Если всех устраивает - приступаете к работе. 2) После того как данная конкретная часть выполнена - ищете баги и собираете в ТЗ новые "хотелки" - согласовываете ценник с разработчиком и опять же если всех все устраивает - продолжаете работу уже по обновленному ТЗ. 3) и т.д. Наверняка встает вопрос о том, типа почему если я как заказчик нашел баги, то почему разработчик не хочет чинить их бесплатно?! - Потому что модули это некое универсальное решение и всегда существует вероятность того, что можно поставить модуль, а работать он будет не всегда идеально и в первую очередь это связано с тем, что чем больше модулей наставлено - тем больше вероятность того, что они будут друг с другом конфликтовать. И это НЕ кривота рук разработчиков, а данность, потому что невозможно предугадать совокупное множество устанавливаемых модулей. Как альтернативный вариант - писать все индивидуально под ваш сайт, но это в разы дороже и дольше.

орнул

На самом деле всё просто... За качество и скилы всегда приходится платить. Всё действительно зависит от ТЗ. Например, если вы наймете Junior разработчика - то ценник будет ниже, сроки дольше, хотелок он выполнит потенциально меньше (просто не умеет еще). Если вы наймете Senior'а - ценник сразу вырастет довольно ощутимо - сроки сократятся, вряд ли вы столкнетесь с тем, что что-то "невозможно" реализовать. Ну то есть - больше платите - больше простор для творчества. То есть все зависит от того а что же вы вообще хотите (более детально, чем "прикрутить шаблон и модуль выгрузок" - это при всем уважении не ТЗ от слова совсем )

Поддерживаю вопрос! Расскажите, пожалуйста, какая ниша и откуда действительно столько трафика?

Речь именно о нишевом магазине. Например только аккумуляторы, или только лампочки, или только омывайка, или только масла. В это придется топить денег намного меньше.

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

Ну кстати да, вот вопрос корректности метрик действительно есть на самом то деле наверное... Хз... надо изучить этот вопрос... Я просто почему спросил вообще, потому что на работе на основной частенько сталкиваюсь с тем, что какую-то мелочь и вообще не проблему раздувают до каких-то не мыслимых масштабов, топят в это все горы денег, чтобы что?... А чтобы не открывать вторую вкладку... лол... Вот решил поинтересоваться, а какая проблема вообще решается изначально.

А что будет происходить если этого не происходит? Какие последствия? Я просто вот на opencart 3.0.2 по этому поводу вообще не заморачивался, и вроде бы как я есть в поисковой выдаче и в яндексе и в гугле, живой трафик пусть и не большой, но идет... У меня правда немного специфичное направление, где не такая прям фееричная выдача как таковая... Может из-за этого возникает ложное ощущение, что все в порядке... о_О

А подскажите, пожалуйста, в чем проблема дублей вообще? Ну то есть как бы все вот говорят дубли - это плохо. А чем это так плохо? А то уже выглядит так, что тут разворачивается борьба ради борьбы... о_О

Попробуйте заполнить ВСЕ возможные поля, не только обязательные.

@chukcha Вот я об этом и говорю, что вроде как пользователь всё заполнил, а всё равно фаталы. При написании кода стоит либо ставить жесткие валидаторы либо не полагаться на то, что пользователь все заполнил и ставить isset и продумывать красные сценарии ))) То есть судя по коду получается, что ключ в массиве существует, но видимо есть кейс, когда это не так. Соответственно - это баг и нужны доработки по коду (это идеальный сценарий конечно же). Можно и расковырять и что-то дозаполнить или подставить костыли - это тоже всегда выход из ситуации. А так вообще, будь я разрабом модуля - я б все же доработочку то сделал. ))) P.S.: если вдруг @chukcha вы разработчик этого модуля, я не пытаюсь кидаться какашками или говорить что я святой и пишу без багов, я тоже косячу периодами Всё предусмотреть довольно сложно )))

Оставили бы возможность комментирования ТЗ. Я так чисто ради интереса зашёл почитать, с ходу захотелось вопросы оставить в комментариях )))

Мне кажется вы не с того ракурса смотрите на проблему. Если проблема есть и ее надо решать - тогда надо искать решение. Если проблема есть, но абстрактному заказчику это не нужно - то и решение искать не нужно. Это так же как с оптимизацией, первым делом надо понять вообще а есть ли проблема... Если система предполагает 1,5 пользователя в день, то строить сложную высоконагруженную архитектуру - нет смысла. То есть в частном случае, если фильтрация нужна и на том объеме данных, который есть у вас - у вас возникают проблемы - то ее надо решать, профилировать код, искать узкие места и оптимизировать запросы. Если фильтрация не нужна или у вас на том объеме данных, который предполагается проблемы нет - то смысл возиться то с этим вообще?

Ошибка говорит о том, что в 31 строке в массиве $settings['title'] не существует ключа 3 (ключ 3 это идентификатор языка), про строку 290 примерно то же самое, но для $tab['name']. Можно предположить, что это код модуля шаблона - и он сделан косячно, потому что имеет по коду вот такие вот узкие места, которые в случае с добавлением/изменением языка требуют доработок в коде.

Ну так да, если никакого сложного функционала нет - то не слишком сложно и тогда только с внешкой вопросы ))) Согласен )))

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