rb2

А вот и зря. Бонусы для пицц - очень хороший маркетинговый рычаг для получения повторных покупок и зарегистрированных покупателей.

Вот-вот :) Замечательная штука, я только изменил у себя, чтобы обновляла цены и кол-ва по SKU, а не ID. Как вижу на форуме очередного пользователя, обновляющего цены через XLS-импорт-экспорт -- недоумеваю. Любят же люди приключений себе найти...

Нувыблиндаёте. Справа вверху - искать: csv, искать в: Дополнения. Энтер. 2 результата, второй - искомый.

Зависит от обновлялки.

Комментарий напишите. "Звонок c +380xx-xxxxxxx, договорились о цене XYZ, заберет после 16:00. -- rb2 @ 12:30" Если у вас 3 сейлза и 2 доставщиков, то при изменении заказов могут время от времени возникать вопросы типа "тю!?": а я не видел, а мне Вася сказал, а там другое было. С логами может не так наглядно, но по истории переписки/разговоров гораздо проще восстановить ситуацию в случае возникновения конфликтов.

Его скорее ещё не сделали, чем убрали. Там же многое поменялось: атрибуты, опции, расчет налогов. У перешедших с 1.4 тонна вопросов и путаница между атрибутами и опциями.Да и чисто организационно, в магазине - по-моему, от возможности свободного редактирования заказов больше вреда и опасностей, чем пользы.

То, что вы так решили, исходя из того, что так могло бы быть (где-то там, теоретически) -- ваша ошибка. Вы решили, что баллы - это аналог валюты и должны как-то там пересчитываться. А они ничего не должны. Потому что они - аналог штук.

Обясняю профессионально: баллы - это спички. Позолоченные. Точка. Никакой связи с автоматическим пересчетом нет, в кармане покупателя они в рубли/доллары/евро не превратятся. Сколько вы их дадите покупателю - столько у него и будет, чтобы предявить вам при следующем своем появлении. В рубли/евро/доллары только вы можете их конвертировать, потому что вы готовы купить у него эти спички. По какому угодно курсу. Он может совпадать с рыночными курсами валют, а может и нет. Эта связь с реальными деньгами - только у вас в голове. Опенкарту до этого дела нет. Он оперирует "спичками" (штуками, баллами). Даст вам покупатель 30 спичек - вы ему можете дать или 30 рублей, или 8 грн, или 1 доллар. Или товаров на эту сумму. Так понятно?

Дописать в яваскрипте в соотв. месте после добавления: window.location = "index.php?route=checkout/cart";

Вам красненьким выделить или черненьким? Поиск, бл#$!

Меня вообще очень удивило, что за 15$ вы ещё и верстку предложили.

catalog/controller/product/product.php найти 'image' => $this->model_tool_image->resize($option_value['image'], 50, 50), заменить на 'image' => $this->model_tool_image->resize($option_value['image'], $this->config->get('config_image_wishlist_width'), $this->config->get('config_image_wishlist_height')), И рулить размерами картинок опций будете из админки: = размерам картинок для вишлиста. Они все равно редко используются.

Статуса заказа? Не ставить галочку "уведомлять покупателя".

Можно было. И в 1.5.2 можно будет.

Опенкарт - универсальный движок, и для одежды, и для картин, и для виагры. Если хочется использовать одну руку и три четверти ноги вместо данных природой, а остальное отпилить и заменить такими чудными красивыми протезами (без этих проклятых пальцев - зачем их целых пять слева? Хватило бы и тех, что справа!) - это уже ваши личные изыски и прихоти. Делайте, кастомизируйте, заказывайте доработки - кто мешает? Убирать и прятать - это не добавлять. Ваш вопрос обсуждался на форуме не раз - ищите, если сами не догадываетесь, как сделать. А ругать универсальный движок за то, что он универсальный - вот это глупо. Вариантов решения как минимум пара. Один - сделать базовую цену нулевой и не показывать её в каталоге, а знаки +/- убрать. Другой - сделать базовую цену равной цене минимальной упаковки, а цену показывать финальную. Убрать это "глупое количество" -- вообще непонятно, в чем проблема. Вы и с этим не можете справитсья, просто спрятав это поле стилем display=none? Да, вам в самый раз оценивать движки.

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

upload/catalog/controller/product/product.php upload/catalog/controller/account/download.php upload/catalog/controller/account/order.php upload/catalog/controller/account/return.php upload/catalog/controller/checkout/cart.php upload/catalog/controller/error/not_found.php upload/catalog/controller/information/information.php upload/catalog/controller/product/category.php upload/catalog/controller/product/manufacturer.php upload/catalog/controller/product/shoppica.php (если есть) Дифф есть у меня в блоге, кому нужен.

И я того же мнения. Менять в заказе цены и количество - чревато недопониманием и поиском виноватых, если магазин обслуживает больше 1-2 человек. Цену доставки откорректировать? Для покупателя? Ему хватит и комментария к заказу. Для отчетов? Хм, вы ими активно пользуетесь и эта разница несколько долларов в опенкартовских отчетах вам нужна?Думаю, если всем, кто думает, что хочет редактирования заказов, назвать реальную цену этих доработок, быстро поймет, что комментарии с историей общения/переписки - самый удобный для этого способ беспроблемного согласования изменений с покупателем. И задницу прикроет при возникновении вопросов, и "дёшево и сердито". А в большинстве случаев и звонка при оформлении отправки груза с уточнением цены более чем хватает. А если для пациента вопрос стоимости доставки очень важен - он его до отправки успеет раза три задать и сам позвонит, если в комментарии к заказу не напишет.

Не-не-не. Не надо. Это для самоубийц и экспериментаторов. Я там на каждом шагу писал - не работает, это экспериментальный и незаконченный кусок был обнаружен (и потом я убедился, что во многих местах не работает, как и опасался). Это в 1.5 переделывается автором с 4 июля и только сейчас почти готово. Ждите версию Opencart 1.5.2.Сделать редактирование некоторых пунктов заказа - может и не проблема, а с полным редактированием вот уже полгода возится Даниэль. Кто уверен, что это просто (половину логики движка перенести из catalog в admin в соответствии со всеми изменениями в работе с налогами и т.п., да ещё без InnoDB и foreign keys) - может хватать флаг и сделать, назовём это "редактирование заказов для 1.5.1.3 за недельку". Вперёд. Даже спрос будет. Ещё с полгода-год наверняка.

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

В catalog/controller/checkout/voucher.php Там в 3 местах ищите цифру 1000. А вообще да, косяк. Надо бы это в настройки вынести.

Много. Я вообще не понимаю, зачем мне регистрироваться для покупки картинки за 30$. Меня задалбывают регистрации и вы ничего от меня не получите, кроме сопротивления. Я должен захотеть сам зарегистрироваться. Если я добровольно и сделаю это (сам сайт мне очень понравился, но регистрация прям сразу - это чересчур), то скорее всего после 2-3 покупок. У меня может быть настроение на одноразовую покупку. Я могу быть в Москве проездом и успеть заказать подарок, но знаю, что это разовая покупка - меня ни ваши рассылки интересовать не будут, ни повторная покупка скорей всего. Если меня будут заставлять регистрироваться - я просто уйду, вздохнув, и записав себе "фото-картины - хорошая мысль для подарка, поискать сервисы печати у нас в городе". Когда я покупаю хлеб (даже регулярно), меня никто на кассе не спрашивает, как меня зовут, мой email и сгенерировать пароль на кассе. И мне это нравится. Пришёл, выбрал, оплатил, ушёл. И все довольны.Условия доставки. Про них возникает мысль при рассматривании приглянувшегося фото и цены. Не давайте мне уйти с этой страницы! Я могу потом на неё не вернуться. Покупка - вещь импульсивная. Поместите условия доставки на отдельную вкладку в описании товара. Оформление и сообщение об ошибке. Ошибка ничем не перекрывается, но оформлена так же, как заголовки - очень похожим цветом. Я вижу на странице яркие синие, оранжевые, темно-зеленые надписи, яркие белые, серый и белый фон и массу серых обводок. Внимание не концентрируется нигде конкретно, взгляд летает по странице и цепляется на каждом сантиметре поверхности экрана. Я в поле пароля скопировал email полностью, заполнил все поля, жму. Страница дернулась вверх. Но (1) я не ожидал подвоха и ошибки, и (2) привык, что страницу опенкарт без дела дергает. Так что некоторое время просто ждал, когда же success появится. Потом обратил внимание, что ничего не грузится и прогресс-бар молчит. Стал смотреть, в чем дело. И сообщение об ошибке нашёл не сразу. При таком обилии цветов на странице, больших шрифтах (форма занимает очень много места, приходится туда-сюда листать, мои обычные шрифты в 2-3 раза мельче. Ваша форма занимает 2.5-3 экрана по высоте - это короткая форма? А по бокам от четверти до половины экрана пустует) ошибка должна сразу в глаза бросаться и взрывать мозг. Обведите её рамкой, залейте розовым/оранжевым фоном, уберите привлекающие внимание красные заголовки, выдавайте сообщение где-то в центре экрана - всё, что угодно, лишь бы было сразу видно, в чем дело. Но сейчас, опустившись на километр вниз к кнопке подтверждения, произошедшую где-то вверху ошибку я нашёл не сразу. Даже при том, что страница дернулась и вроде пыталась промотаться туда. А вообще, по-моему, имело бы смысл изменить цветовое оформление и не отвлекать зря внимание светофром надписей. Чтобы важные сообщения сильно выделялись и сразу были заметны.

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

Варантов несколько: 1. Менять doctype. Ничего крамольного в этом нет - верстальщик в этих вопросах главный, а не php-кодеры. Сделайте шаблон "valid" и пишите там правильный доктайп и теги. Но без (2) в этом случае тоже не обойтись. 2. Исправлять CKEditor. Но он в опенкарт включен в упакованном виде, в котором фиг разберешься. Так что предстоит лишняя морока. Плюс проблемы с обновлением ещё одного стороннего компонента. 3. Если надо быстро, то я бы оставил (2) как есть, делал (1), а в админке (в валидаторе напимер) добавил обработку этих полей (заменить target="_blank" на rel="external"). Если сделать это в валидаторе, то и в форму данные вернутся исправленными (в случае наличия ошибок), и в базу попадет исправленный вариант.

Встроенный бекап в Опенкарт сохраняет только данные, без структуры таблиц. Поэтому имеющийся бекап можно восстановить только на имеющюся базу, но не на чистую. Про phpMyAdmin надо было раньше думать, а сейчас, к сожалению, вариант один - пытаться восстановить сначала структуру БД, а затем заливать на неё бекап.