nogocuHoBuk

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

Вы специально подменяете понятия или так само получается? Есть унитаз, его назначение - принимать продукты жизнедеятельности организма и избавляться от них Это его задача. Если Вы установили унитаз так, что он не справляется со своей задачей - виноват исполнитель, а не заказчик, и устраняется это за счет исполнителя. Я выше уже писал - для того, чтобы окончательно встать на сторону @Zauresh нужно, как минимум, увидеть ТЗ, которое было оговорено. И да, если на сайте не работает функционал, который должен работать - это вина исполнителя. Однозначно. Тут даже обсуждать нечего. Но если не реализованы фантазии заказчика - это заказчика, и только его половые трудности. И ещё раз да, если из на фронте имеются тексты, категории, адреса, которые невозможно исправить из админки, и такой возможности не было до обновления - вины исполнителя, опять же, нет. Да, считается правилом дурного тона встраивать текст напрямую в код (с правкой через FTP), но всё зависит уже от личного отношения заказчика к исполнителю и наоборот. В принципе исполнитель мог бы и исправить, добавить возможность правки из админки для удобства, но не обязан, особенно на фоне назревающего конфликта. Тут много ещё "а если б". Хотите правды - пригласите в этот тред исполнителя, послушайте его аргументы. Велика вероятность, что его тут заклюют..... Я Вам третью историю расскажу. Исходные данные те же - унитаз куплен, вызывают Вас на установку. Пришли Вы на замер уборной, посмотрели, померяли и говорите заказчику - нужно не боковое подключение, а нижнее, и не прямой выпуск, а косой, ну и объясняете почему. Акей, договорились, заказчик меняет унитаз и просит Вас приехать ещё раз, Вы приезжаете на установку, а не месте унитаза стоит стиральная машина.... И теперь купленный унитаз сюда не станет, нужно брать вообще другой, а лучше уборную расширить или стиралку переставить... Объясняете это всё заказчику и тут на Вас обрушивается шквал: "СКОЛЬКО МОЖНО ГОЛОВУ МОРОЧИТЬ!!! СКОЛЬКО УНИТАЗОВ ВАМ НАДО? ВЫ СПЕЦИАЛИСТ, СХОДИТЕ И КУПИТЕ!!!" Поймите, исполнитель не умеет читать мысли. Невозможно наперед предугадать "развитие сюжета". Даже если ВСЕ обсудить - в итоге часто бывают недопонимания. Именно для этих случаев придумано ТЗ. Всё что в нём есть - будет выполнено. Не выполнено - санкции. Выполнено - деньги на бочку. Есть дополнительные пожелания, которые выплыли в процессе (установка унитаза после установки на его место стиралки) - за дополнительную оплату после составления очередного ТЗ... ЗЫ. Сорян за много текста, но хотелось высказаться

Присмотрелся к роуту: common/home в админке

захожу куда? Вы можете проблему описать? Мол: "захожу на сайт, ввожу логин/пароль а мне пишет..." или "перехожу в каталог товаров а мне пишет" или "устанавливаю дополнение, а мне пишет" Могу только предположить, что Вы устанавливаете дополнение несовместимое с Вашей версией опенкарта, либо от "криво переделанного дополнения" со старой версии до Вашей. Там разные роуты: extension/module и extension/extension, потому после установки старого модуля происходит неправильная переадресация и возникает ошибка, процитированная Вами.

где пишет? Если галки проставлены, то, подозреваю, что ошибка появляется после установки дополнений.

Ну вариантов, же, действительно не так много. Проверить файлы конфигураций /config.php, /admin/config.php и /system/library/config.php И если с ними всё в порядке - перекачать папку system. Ведь ошибка явно говорит о том, что проблема в классе Config. Возможно некоторые файлы не загрузились (сталкивался пару раз при заливке на хост). Ошибка была другая, но тот факт, что некоторые файлы либо пустые либо их не существовало - имел место быть...

config.php, который в корне, точно корректный?

Верно. Тут мой завтык... Но ещё раз обращу внимание на саму строку с ошибкой: Эта строка некорректная Должно быть == Не думаю, что в Simple на проде такой косяк. Либо сторонний модуль либо "правленый" Simple.

Первый пункт очень расплывчатый и малоинформативный. У вас движок-динозавр, которому уже как минимум 7 лет. За 7 лет на Ваш сайт могли быть внесены сотни изменений в функционал. И если изменения в модификаторах можно отследить, то изменения, внесенные в код напрямую отследить нереально (разве что увидеть случайно). Потому фраза "с сохранением текущего функционала" не несет никакой полезной информации. Создайте полноценное ТЗ, в котором распишите ВЕСЬ функционал, который Вам необходим.

абсолютно верно

В \catalog\model\checkout\order.php в функции addOrder после $order_id = $this->db->getLastId(); добавляем: $new_auto_incr = ($order_id+1) + rand(3,10); $this->db->query("ALTER TABLE `" . DB_PREFIX . "order` AUTO_INCREMENT = ".$new_auto_incr); Примерно так: После внесения правок ОБЯЗАТЕЛЬНО обновить модификаторы.

т.е. при изменении номера на +3 за неделю это, конечно придаст магазину престижа

Так то можно при желании, запустить итератор аутоинкремета в таблице oc_order в функцию добавления заказа с циклом, ограниченным рандомайзером.... Только зачем?

По факту Вам дали уже максимальную информацию Там действительно ничего сложного создать модуль конкретно для Вас с возможностью указания размера миниатюр в самой категории. А при отсутствии указания, например, брать дефолтные настройки. Это действительно не сложный модуль, ноооо НЕ БЕСПЛАТНЫЙ Прям орнул. В точку. Не смог пройти мимо - плюсанул

Информация о том, получил поставщик инфу или нет, как оказалось, содержится в самом ответе т.е. ResultStatus - статус получения заказа (таблицу ответов смотрите в документации API поставщика) Точно знаем, что ResultStatus = 2 - Не корректный ApiKey Т.е. Вам нужно в заказе создать флаг отправки, который в случае успешной отправки заказа поставщику (думаю что ResultStatus = 1, но это предположения) перевести этот флаг в "отправлено" И можно смело вешать задачу на крон с отбором заказов по фильтру - (оплачен, не отправлен). Раз в 10-20-30 минут. В зависимости от количества заказов. Думаю, это самая оптимальная реализация. Хотя их, действительно, много. Я вижу как минимум 3.

Ну, так то это нотис, а не ошибка Предупреждение. И гласит оно примерно следующее: В массиве order_data отсутствует указанный вами ключ (речь о shipping_method) Тут ещё такой момент - это Вы неправильно скопировали, или в коде действительно такое сравнение? $data['quick'] = ($order_data['shipping_method'] = '') ? true : false; Ибо по логике там должно быть $data['quick'] = ($order_data['shipping_method'] == '') ? true : false; Т.е. если данных заказа указан метод доставки - это обычный заказ, если не указа - быстрый заказ. А сам нотис можно убрать в коде оформления быстрого заказа прописав дефолтный shipping_method. Либо слегка изменив код на такой: $data['quick'] = false; if (isset($order_data['shipping_method'])){ if ($order_data['shipping_method'] == '') $data['quick'] = true; } else { $data['quick'] = true; } Т.е. проверяем существование $order_data['shipping_method'] и если существует - дальнейшая проверка. И тогда исключение "PHP Notice: Undefined variable" не выскочит...

Этот момент так-же требует разъяснения. Всё ж зависит от способов оплаты. Если у Вас подключен платежный модуль, который общается с платежной системой (например тинькофф) то схема следующая: 1. Покупатель оформляет заказ. 2. В БД создается заказ со статусом "ожидание", а покупателя перекидывает на страницу оплаты. 3. Если оплата произведена, то платиежная система отправит на Ваш сайт коллбек с информацией о получении оплаты 4. Сайт, по колбеку, находит заказ и переводит его в статус "В обработке". В этом случае функцию формирования массива для отправки можно встроить в АПИ для приема колбека от платежной системы (образно) Но если у Вас прием оплаты, например, на счет/карту, то перевод статуса заказа происходит не автоматически, а оператором, который отслеживает поступившие средства, и по данным платежа переводит тот или иной заказ в статус "В обработке" В этом случае формирования массива для отправки нужно встраивать в админку в order_edit и отслуживать новый статус.... Это уже не совсем автоматизация. В таком случае можно просто кнопку добавить в форму заказа типа такой: Просто нужно делать так, чтобы мухи были отдельно, а котлеты отдельно. Либо автоматизация, и тогда искать общее событие, к которому можно "присосаться", либо забить на автоматизацию, и прикрутить скрипт на кнопку. Полная инфа, как и документация АПИ, как и варианты оплат и прочеепрочее есть только у Вас.

Что-то советовать и обсуждать невозможно без ТЗ (как уже выше писали) Сумма, по факту, не имеет значения, так как обе стороны согласились (хоть 100 вечнозеленых, хоть 100000). Если ТЗ выполнено - никаких претензий возникнуть не должно. Если же какой-то из пунктов не выполнен - можно требовать либо возмещения, либо исправления. И да, без "второй стороны конфликта" сложно что-то советовать и предполагать. Просто выглядит это примерно так: Алек Болдуин на съемках фильма застрелил оператора и ранил режиссера. И мы все тут обсуждаем какой Алек нехороший. Кто-то вспоминает, что это всё из-за того, что в США разрешено ношение оружия. Некто напомнил, что Болдуин, так-то, ещё и побухивает время от времени. А в итоге оказывается, что Алек стрелял холостыми строго по правилам режиссера, в направлении, указанном режиссером, но пуля при выстреле не сгорела, а её осколки угодили в оператора и режиссера. И вины Алека нет и быть не может.... Очень маловероятно. В большинстве случаев это обычно вытекает в "Слушайте, не нужно мне напаривать! Мне главное чтоб работало", а это уже ОЧЕНЬ расплывчатая формулировка. И да, если в работе есть ошибки, которых по умолчанию быть не должно - исполнитель должен их устранить (либо доступно объяснить по какой причине это сделать невозможно)

Совет с записью в сессию массива $this->session->data['product_options'] с выбранными опциями и ключом - product_id, а затем чтением этого массива в карточке товара и включения выбранных пользователем - очень даже правильное решение. Естественно нужно предусмотреть очистку массива товаров с опциями в случае, если страница не равно карточка товара. Но то уже "оптимизация". Если в этом месте у Вас недопонимание - лучше обратитесь к спецу. Ибо тут не мануал нужно давать, а полноценный курс по сессиям, их хранению, очистке и использованию.

Собственно тоже да, но мы пока не знаем нужно изменение для конкретной службы доставки или для всех, у который сумма 0 Если для конкретной, то по shipping_code, как в моём примере if ($order_total['code'] == 'shipping' && $order_info['shipping_code'] == 'flat.flat') { Если в любой доставке с 0, то по сумме: if ($order_total['code'] == 'shipping' && (int)$order_total['value'] == 0) {

Нене. Не там строчка: Вам, скорее всего, действительно нужно смотреть именно в сторону самого модуля импорта. Без "взгляда" на код не понять где и почему возникает описанная Вами ошибка. Много "факторов"

Откажитесь от моей первоначальной затеи сравнивать название службы доставки То я был сонный Правильней привязаться к коду доставки: foreach ($order_totals as $order_total) { if ($order_total['code'] == 'shipping' && $order_info['shipping_code'] == 'flat.flat') { $data['totals'][] = array( 'title' => $order_total['title'], 'text' => 'Тут добавляйте любой нужный Вам текст. Даже чистый HTML, что-то типа <b>жирный текст</b>', ); } else { $data['totals'][] = array( 'title' => $order_total['title'], 'text' => $this->currency->format($order_total['value'], $order_info['currency_code'], $order_info['currency_value']), ); } } flat.flat - вставил для примера. Вы можете вставить код Вашей службы доставки (новой почты)

Не совсем понятна задача (точнее есть уточняющие вопросы) 1. Нужно ли принимать ответ поставщика? Если нужно, то в каком формате? Если нет - как Вы узнаете, что реквест отправлен? 2. Почему ExtOrderPaid - 1? Т.е. отправку данных нужно производить только после оплаты? Как быть, если оплата при получении? От ответа на второй вопрос зависит то, в какое именно место нужно интегрировать отправку запроса. Ибо если задача "тыкнуться" к поставщику при оформлении заказа (мол поступил такой-то заказ), то правильней будет вкорячить в mail/order чтобы реквест отрабатывал одновременно с уведомлениями. Если же задача только после оплаты, то привязываться нужно к статусу заказа (либо "завершен", либо "оплачен" - ну или Ваши аналоги этих статусов) Ну и, уверен, по мере ответов на эти вопросы могут возникнуть новые...

Нужно смотреть. Бо непонятно ж где именно Вы удалили строку. в модифицированном файле или в родном? Если в модифицированном, то её там добавляет модуль типа "Товары подкатегорий в родительской категории"

Самый первый подводный камень, он же самый огромный (я бы даже сказал айсберг) это то, что WordPress, это, в первую очередь, CMS для БЛОГА, в который вкостылили магазин. А опенкарт - это магазин, в который вкостыливают блог.