rb2

Насколько вижу, в теме применяется Cufon и кастом-шрифты (Kartika). Вероятней всего, он просто по умолчанию скомпилирован без кириллицы. Или разбирайтесь с Cufon и созданием своих шрифтов, или пните разработчика, чтоб international support включил в пакет - они задолбали знать только про английский и до сих пор спотыкаться на UTF8 и забывать о существовании другого мира.

Они про admin/controller/.......... Где, к слову (во всей админке) нет ничего с именем cart.php А последний раз такую строчку можно было найти в исходниках до этой даты: Author: ibabushka <ibabushka@44b37dae-b762-45cd-8c5e-82695f3631dd> Date: Thu Jun 23 09:43:00 2011 +0000 git-svn-id: http://subversion.assembla.com/svn/ocstoreru@208 То есть это пост вообще непонятно о чём. Никакого отношения к 1513.

СЕЙЧАС ДОЛЖНО ЛУЧШЕ РАБОТАТЬ. Посмотрите последние изменения - тогда и решите. Я лишь недавно, на этой неделе этот момент переделывал. Теперь не должно быть неоднозначностей и зависимости от того, как броузер JS обрабатывает. Может и MSIE полегчает. Я не фронт-энд разработчик, нет под рукой зоопарка броузеров для полноценного тестирования. С первым пунктом у меня нет точного ответа. В баг-трекере это пожелание есть, #81. Ваше пожелание туда приплюсовал. Сроков назвать не могу.

Если взял в руки скальпель - ещё не значит, что уже хирург. Конструктивная критика предлагает альтернативное решение. Без этого - это простые вопли и выпячивание павлиньего хвоста. Если всё так просто - бери и делай.

Evgeny, напомните email, с которого покупали - в профиле не нашёл ничего, чтоб идентифицировать. Вышлю обновление, попробуете с последними изменениями. Отключал автовыбор персонально для IE уже давно. Сейчас должно лучше работать. 2 - включите её в админке как обычно, галочка и появится.

catalog/language/russian/checkout/quickcheckout.php $_['entry_firstname'] = 'Ф.И.О.';

http://rb.labtodo.com/page/opencart-1512-quick-one-page-simple-checkout См. скриншоты, там есть и очень короткий вариант. Фамилию и вконтакте я вам добавлю, ну и сделать их обязательными тоже не проблема.

Индикация цен опций товара заменена на абсолютную величину (вместо разницы +X руб, -Y руб) Там есть отмазка в самом начале. Эти плюсы и минусы не просто так делали. Если есть несколько наборов опций, то реальную цену уже не увидишь и такое решение запутает покупателя. Оно применимо только в частных случаях: с одним набором опций, влияющих на цену. Иначе будет путаница.

Чеканя РУССКИМИ буквами Ненавистно длинные СТРОЧКИ Зайдём мы в светлое БУДУЩЕЕ С офигенно КРУТЫМИ шаблонами! Неся на плечах РАЗРАБОТЧИКОВ! В каретах таких, с БАЛДАХИНАМИ! Пыщ-пыщ!

Откуда данные? Вы анализируете поисковые запросы по своему магазину? Или это выводы из серии "я и 10 моих друзей не пользуются"?

Неудобно что? Там на 1 действие больше. Дальше всё то же самое - поиск и клик на кнопку.

1 - комментарии к заказу, 4 - заведите покупателя "Заказы по телефону", логиньтесь под ним из админки при звонке и заказывайте

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

А в чём смысл разгадывания этого ребуса?

Речь точно о рунете? И об Опенкарте? Тут на модули ценой 10-30$ собираются вскладчину.Да и понятия бизнеса у всех разные. На Опенкарте многие пробуют делать свой первый магазин и с нулевыми (или около того вложениями).

У автора рецепта спросите, что он имел в виду и как делал.

https://opencartforum.com/topic/6219-ocstore-v1513-%d1%80%d0%b5%d0%bb%d0%b8%d0%b7/page__view__findpost__p__47678

Одноразово: 1. Берём ocstore с гитхаба: git clone [email protected]:rb2/ocstoreru.git magaz-na-ocstore Теперь у вас локально в папке "magaz-na-ocstore" -- своя локальная копия репозитория. 2. Переходим в ветку master. Там живёт read-only копия основного SVN репозитория с ассемблы: git checkout master 3. отпочковываем свою ветку (независимую копию): git co -b magaz1.ru Регулярно: 4. Фигачим, экспериментируем, ставим что попало. Проверяем. Работает? Коммитим. Подробности всех процессов тут опускаю для краткости. 5. Периодически вливаем изменения из master branch в нашу ветку живого магазина: git merge master (делать это надо, находясь в своей ветке) Собственно, вкратце и весь сценарий. Это должно позволить без проблем вносить новые обновления в свой магазин, построенный на этой сборке. Все изменения и эксперименты происходят в вашей ветке и никак не влияют на master. Ваша ветка растёт и растёт сама по себе, обрастая стабильными изменениями. Периодически надо заглядывать в ветку master и забирать обновления с сервера: git co master && git pull. Посмотрев логи, не забыть вернуться в свою ветку: git co magaz1.ru Помочь вспомнить, где мы находимся, может команда git branch -a Переключаться между ветками желательно со всеми закоммиченными изменениями, чтобы git st был чист и измененные файлы не путешествовали туда-сюда. P.S. Как это сделать с использованием только SVN - не знаю, даже не спрашивайте, это с другой планеты, не пригодной для жизни. Теоретически концепции схожи, но на практике в SVN работа с ветками - удел избранных и очень терпеливых. И постоянно подключенных. P.P.S. Сокращения Git команд отсюда, я к ним привык

У меня было несколько постов на эту тему - http://rb.labtodo.com/tag/search

Да нормальный ход мысли. Делайте опцию с тремя вариантами (комплект, только бюст, только трусы), ещё лучше с картинками А это непонятный мне ход мысли. Чем вы сэкономите мое время, если я вижу на фото полный комплект, а в том, что можно купить отдельно - надо догадываться и разбираться в хитросплетениях списков и опций, нагроможденных на одной странице только ради того, чтобы человек подольше на ней находился?Просто, быстро и удобно - это когда всё однозначно, понятно и наглядно. Картинка + цена + кнопка. И без сюрпризов, когда я вижу на фото полный комплект за полцены, ведусь на цену, а потом оказывается, что это только одна из частей, просто фото у всех товаров из комплекта одинаковое. Просто дайте посетителю 2 товара. Или хорошо и понятно оформляйте опции, чтобы с одного взгляда было понятно, что именно получишь в итоге. Без ребусов и головоломок.

Поиск: csv где: дополнения Enter

Ок, на суммах в 100$ картина будет симпатичней - не будет того "хвостика", который сильно портит прием мелких платежей (на суммах 5$ я сразу теряю на входе 10%, на 10$ - 7%). На более крупных суммах незаметно. Плюс может быть конвертирование из одной валюты (в которой платежи принимаются) в другую (валюту банка, куда выводятся) по курсу Paypal. Если банк - не конечная инстанция, а надо ещё из него деньги обналичить - ещё одно звено. В общем, согласен - на таких суммах, может и получится до 5% терять. Ну и самое главное - все эти комиссии скрыты от покупателя, перекладываются на получателя. Меньше будет отпугивать.

Большие платежи - явно не карточками. Карточка - это по сути "неподписанная транзакция". Нет подписи в виде ввода PIN-а, когда уже полностью доказано, что платил именно владелец карты. Всем сторонам сделки удобно, риски есть, но на них идут - золотая середина. В случае, если покупателю вздумалось сказать "а это не я был" - он получит назад свои деньги, а кто-то где-то - пендюлей и сработавших рисков. На более крупных сделках потери гораздо больше и их компенсировать уже никому не хочется, веря на слово. Поэтому - банковский перевод. Где платящая сторона уже подтвердила, что именно она владелец счета, и никто не мешает переводить нужные суммы тому, кому надо. Тут уже не получится сказать "а это не я был", как с карточкой. Скорей всего именно поэтому Розетка принимает WM при покупке достаточно дорогих товаров (ноутбуки, например) и не принимает карточки. WM - это банковский перевод по сути. Покупатель полностью авторизовался. Сказать, что это не я был, а продавец мошенник и списал лишнее или дважды с карты - не получится. Ну да, логично: нал (+ чек), безнал и WM. Так что прямая дорога к безналу и прямым переводам на больших суммах. Я не в курсе нынешних правил той же Визы и Мастеркард, но раньше они штрафовали за чарджбэки очень люто. И штрафы ложились на продавца. Вот и подумайте - пойдете вы на эти риски, если будет возможно заплатить вам 5 тыс, заказать на адрес какой-то незнакомой бабушки, заплатив ей смешные деньги за то, что ей доставят посылку (я типа дома не бываю, живу в соседнем подезде, вас вижу часто, спасите-помогите, ещё и сотню грн заработаете), а потом опротестовать платёж и сказать это ваааще не я, ничего не знаю, отдайте деньги, ничего не видел, карту спёрли или сфотографировали на кассе. CVV тоже воруется: у кассира остается номер, при возврате карта переворачивается обратной стороной вверх, а один из соседей в очереди запоминает 3 цифры. И все дела. Можно бежать в ваш магазин с чужой картой и очередной бабушкой-одуванчиком для разового адреса доставки.

Думаю, что при любой попытке списать с карточки покупателя 5-10 тыс долларов интернет-магазином два банка будут вздрагивать одновременно. И если ваш процессинговый центр рано или поздно может и включит вас в список благонадежных, то у банков, обслуживающих карточки покупателей, сомнения будут возникать часто и регулярно. И они скорей всего часто будут блокировать подозрительные платежи. Просто на всякий случай, для защиты своих клиентов. Что не прибавит радости ни процессингу, ни вам. В общем, я думаю, что любой нормальный банк скорей всего будет довольно сильно мешать своим клиентам потратить столько денег для оплаты товаров карточкой в интернет.

Да как бы давно уже. by Yesvik. ---- Если сервер поймет указанные строки в .htacess - их и применяйте. Если сдохнет с ообщением об ошибке (типа 500 internal error) - комментируйте и разрешайте строки по одной в поисках, какая ему не по зубам. В случае проблем с func_overload - ну, тогда уже меняйте исходный код на использование mbstring. А длину в базе - ставьте любую, которая нравится. И перевод корректируйте.