rb2

Я ж не про то, что с ними сделать можно. Там вопрос был, это тоже базы данных или что. Я сначала тоже начал писать что-то подобное, потом стёр нахер. Потому что понимаю, что топикстартеру просто очень хочется обновить mysql на сервере.

Чтобы налог считался, надо указать Tax Class в тех способах доставки, которые может выбрать пользователь при оформлении. Если там нет такого поля с выбором - значит искать другой способ доставки или адаптировать имеющийся. Промоделировал на OC3, получилось как-то так при цене макбука = 500 и доставке = 10:

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

@gustovapebar ну вы дважды написали, что планируете недорого, при этом скорей всего по-быстрому. А после выхода в прибыль - будете поднимать сайт на профессиональный уровень. Это подаёт очень понятные сигналы. С другой стороны - наполнение с нуля, при этом надо тщательно и аккуратно заполнить характеристики и атрибуты без готового сайта-донора этих данных. С китайского сайта скорей всего можно будет взять только названия и фото. Кое-как автоматизировать - ну разве что фото, и то непонятно, будет ли с этой автоматизации хоть какая экономия. Скажу, что при ручном заполнении аккуратное внесение всех данных быстрым оператором, который хорошо знает опенкарт - это минимумм 20 минут на товар, при том, что все данные уже есть и не нужны ни переводы, ни рерайт - просто перенос информации. 200 товаров - 2 недели, 300 - минимум 3, реальней 4. Дальше - вам нужен в одном лице программист, верстальщик, сеошник и контентщик.Навскидку, даже не заглядывая на DOU со статистикой зарплат айтишников - в ваших хотелках навскидку работ на месяц и по деньгам - где-то в диапазоне 2-5к долларов. Если капец как ужаться - ну не знаю, может 1к и месяц работы, если с расчётом на долгое дальнейшее сотрудничество. Мне примерно так заявленный объём видится. Похоже это на ваш бюджет? Или вы ожидаете в разы меньше и что 200-300 товаров можно по 5-8 грн за шт наполнить?

На вкладке "транзакции", если правильно помню.

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

Почему вы думаете, что в базе обычные пробелы, а не неразрывные? Вы привели только скриншоты, на которых их не отличить. Посмотрите в hex-виде, что там на месте пробелов в украинских названиях. Думаю, там будет не 0x20

Форма чекаута с первого взляда: вау, одностраничник. После нескольких минут экспериментов и недоумения - гора матов. Две, мать его, кнопки! Логика капец неочевидная. Воу-воу! Неужели зачатки DRY начали просачиваться в код через 12 лет бесплодных попыток пропихнуть это в апстрим?

В админке: Extensions - Extensions - выбрать в списке Order Totals И там отключите ненужную строчку.

А в опциях что за ошибка? По приведённой ссылке ошибок не видно.

Можу подивитися на сервері. Якщо у вас там є SSH, можете спробувати щось таке: grep -rnw '/де/там/ваш/сайт' -e '(1000,' # або краще так grep -rnw '/var/www/ваш/сайт' -e '1000,\s*1000' Але я не пам'ятаю, які там аргументи функції, що формує адрес зображення. Якщо розміри не прям відразу, то скобочка заважатиме

Уважніше, там скріншот, з якого зрозуміло, що кеш ні до чого - вони там знову з'являться. @AlexandrSY скоріш за все дійсно десь хардкод, можна пошукати в коді цю "1000"

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

Так это НЕ статус товара. Это "что написать, если товара нет на складе"

@lensmen я свободен, могу посмотреть. Быстрей и точней будет на вашем сервере. Если нет - поставлю указанную в начале версию.

@zhizherinv если покупатель не может выбрать те или иные серёжки, то какие опции, зачем? Я это вижу как один товар с разной ценой, а вес - это просто способ идентификации конкретной пары серёжек на складе. И по сути нужен механизм смены цены и может названия/описания товара - допустим, где-то указаны пары вес-цена. Но возникает вопрос - когда и как менять цену? Положил в корзину - ещё не значит, что купил. Сразу после полёта в корзину? После оплаты или отправки заказа? Хранить или не хранить эти пары "вес-цена" и историю? Лично я бы скорей всего сильно удивился, если бы после того, как положил в корзину товар, на него цена тут же изменилась на следующую по списку.

Ну так от нас вы чего ожидаете? Конкретные предложения? Мы сейчас тоже хотим, чтоб ваш дебильный совок рухнул, и будем делать всё возможное для этого - изоляция, бойкотирование в том числе. Для русофобии вы нам дали все основания.

Проверил на PHP7, PHP8 - результат везде 0.97 v7.4.15, v8.0.2 <?php echo 22795 / 23500; echo (float)22795 / (float)23500; echo '22795 грн' / '23500 грн'; Вы точно цены не из админки берёте, а выводили на экран или в лог?

Поправлю. В опенкарте из коробки не делается охулиард индексов, необходимых для нормальной работы.

LOL +1 про оптимизацию запросов. Это комплексная задача.

Что вас так удивляет? Я не помню реальных цифр, но вроде для опенкарта это вполне норма. Одно меню построить - там кучу запросов опенкарт делает.

Не понял, почему не вариант? Будет у 2-8 товаров один трек-номер указан. При большом желании можно при выводе информации покупателю их сгруппировать по одинаковому номеру.

Они правы. Версия 2.2.0.0 - это странный выкидыш. Её надо обходить десятой дорогой. http://www.labtodo.com/2016/04/pro-versiyu-22

Продажи - Покупатели - Пользовательские поля

Не фантазируйте. Хотите видеть там язык - код языка "uk", хотите показывать там страну - показывайте "ua". Но говорить одно, а "красивше другое" - это самодеятельность и "я так вижу".