deeman

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

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

Такого не может быть, потому что именно из базы опенкарта берут все данные не только модуль, но и все остальные страницы (и даже админка модуля на скриншоте выше берёт данные оттуда же, то есть они есть прямо в вашем опенкарте). Можете проверить на любой стандартной странице опенкарта

Уточните, пожалуйста, информацию по приобретению модуля и адрес сайта в личке, пожалуйста

Вам сверху посоветовали изменить название, при этом вы прочитали невнимательно и даже не попробовали сделать... Они могут писать что угодно. Если бы дело было в модуле, он бы в принципе не выводил сдек для любого региона. Всё примитивно, есть массив с данными адреса, есть ответ от модуля доставки

Не вижу среди покупателей модуля, уточните информацию в личке.

1. Я не ставлю модули персонально каждому 2. У модулей доставки своя логика и свои настройки, мой модуль не может не показывать в зависимости от региона. Он передаёт адрес и выводит то, что вернули модули доставки

По аналогии, так, как сделано там или в любом другом месте опенкарта. Я физически не могу писать код каждому персонально, в принципе свободного времени нет,

Смысл тогда прогонять через корзину? Добавьте в массив товаров в модели заказа перед сохранением в базу, там же и проверку добавьте на нужные товары. Способ выше нужно окружать проверками, не добавлен ли уже товар в корзину и т.п.

Зависит от задачи и реализации, варианатов реализации вагон... Можно в методе создания заказа модели опенкарта дописать товары в массив и в базу запишутся в заказ. Можно на уровне выше перед передачей товаров в модель уже в коде модуля в контроллере, который назвали. Если человеку нужно видеть, что у него будет добавлено, то делать ещё "выше", в самом начале перед загрузкой блоков добавлять товар в корзину опенкарта, если его там ещё нет. Ну и плюс продумывать вариант с попыткой удаления такого товара.

1. Не вижу среди покупателей модуля, уточните информацию в личке 2. Можете не ставить модификаторы для кастомных полей, они не обязательны для работы модуля.

Отмените свои же действия на сайте и с модулем. Ну и как вариант наоборот обновите до последней версии (как минимум отменит все правки в модуле и если что модуль сделает запись в лог)

в каталоге темы шаблон /checkout/simplecheckout_shipping.tpl

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

Да уж... Можете поставить модуль на любой другой сервер и убедиться, что всё работает. Либо поставить ту версию, которая стояла изначально. И проверьте ещё раз и внимательно, что выполнили рекомендацию с async: false, это поставит все запросы к серверу в очередь. Ещё раз повторюсь, что 503ую ошибку выдаёт сервер, до модуля дело не доходит. Ни одна правка в модуле проблему не исправит, кроме правки выше, которая тоже ничего не изменит, только лишь все запросы от модуля (5 штук при загрузке) встанут в очередь друг за другом. Вопрос больше к хостеру, почему 5 одновременных запросов к их серверу приводят к отказу в обслуживании и что будет, если на сайт зайдут 5 пользователей одновременно...

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

Тогда нужно уточнять у хостера, что не так. Этот ответ даёт сервер, не модуль

Из инструкции: Если в админке модуля при его открытии вы видите ошибку 503 (Service unavailable) в красном уведомлении, то в файле /admin/view/template/extension/module/simple.tpl вместо async: true сделайте async: false

настройки модуля править не нужно, кроме значения по умолчанию. Значение по умолчанию будет передано в модель адреса и потом с адреса будет же и получено. Если в базе есть много старых пустых адресов, то можно у всех проставить значение одним запросом: UPDATE oc_address SET country_id = 220 Ну а если модели опенкарта правлены и адрес не создается при регистрации, то нужно поправить модель, которая отдаёт данные адреса (/model/account/address.php метод getAddress) и выдавать в нем айди страны для пустой записи.

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

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

Вы таки провели исследования и знаете реальную картину обновлений, раз даёте такую публичную оценку?.. В курсе, кто и как обновляется? Я уже писал вам, что в первую очередь отмените все правки, никаких ошибок не будет.

Нужно писать тому, кто эту ошибку выводит. Модули оплаты берут всю информацию по заказу с базы данных с таблицы заказа. Проверьте информацию по заказу в админке, совпадают ли суммы

Только делать вызов reloadAll() своим скриптом по onchange. Сам скрипт можете добавить в админке модуля в разделе джаваскриптов

Я не беру заказы и не пишу код персонально под каждого пользователя и также не провожу аудит настроек каждого пользователя, у меня столько свободного времени нет. Код представлен как пример, причем он рабочий, всё делается по аналогии с полем регистрации. Можете так же написать свой код или сделать отладку существующего примера через запись в лог опенкарта. $this->log->write(var_export($нужная_переменная, true));