afwollis

в доках море данных, которых нет в opencart. надо сначала грамотное ТЗ составить, описав связи/подстановки/итпд.

а нам всем конкретика требуется. тем-ни-о-чем на форуме МОРЕ.

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

как всегда - "надо только...". да только вот НЕ ТОЛЬКО. надо ставить два магазина - копию текущего и чистый с новой версией темы оформления. перелопатить новую версию, чтобы понять, ОТКУДА НОГИ РАСТУТ. затем перелопатить старую, чтобы понять, КУДА ЭТИ НОГИ НАДО ПРИШИТЬ. и вот только потом можно будет "перетянуть и пришить ноги".

проблема как раз не это, а то, что хочется иметь "бесплатный/дешевый комбайн", который выгрузит товары в yandex,wikimart(,avito,aukro,ebay,amazon,...) и покупателя обслужит, и деньги удачно вложит, и водички с похмелья подаст. это как хотеть транспорт (велосипед+авто+мотоцикл+троллейбус+пароход+самолет+космический_шаттл), чтобы "везде быстро удобно не останавливали" и ночью можно было в квартиру забрать, а не оставлять на улице/в ангаре. - - - сделать модуль для выгрузки товаров на wikimart - не проблема. озвучиваешь итоговые требования к функционалу/настройкам/формату-данных-на-выходе -> оплачиваешь разработку -> получаешь результат.

Skunk, зачем повторять чужие глупости? не учитываются: - ни строковость (наличие в "цене" в tpl пробелов,запятых,точек,итпд); - ни символы валют; - ни акционные цены... там больше кода в контроллерах надо.

зачем? есть какие-то непреодолимые проблемы/причины для обновления? конкретику давайте. если есть прайсы и надо из них импортировать/обновлять данные - цепляйте примеры прайсов. ... вам сначала нужна помощь в формировании ТЗ.

Lilya, что-то это вообще не об opencart... и какие таблицы "нужные"? и что и в каком виде ты оттуда заберешь? - море данных в разных таблицах, которые надо будет потом как-то связывать? = = = вот пример и дополнительная пища для размышлений (всем): - - - есть "гости" в заказах: вася петечкин - [email protected] - купил бубен - оплачен, завершен; вася петечкин - [email protected] - купил "10 соток на Луне" - отменен; аня пирожкова - [email protected] - купила барабан, губную помаду, iphone6s - оплачен, завершен; аня пирожочкина - [email protected] - купила барабан, губную помаду, iphone6s - отменен; петя васечкин - [email protected] - купил рулон обоев, пачку клея, валик - оплачен, завершен. потом регистрируется: иван иванов - [email protected] и делает заказ: гена чебурашкин (customer_id итпд - иван иванов, но адреса доставки/оплаты другие) - [email protected] - купил утюг, рулетку - оплачен, завершен. - - - что делать (особенно с "геной")?

если оставлять "это ТЗ", и особенно вот это то получится "создание магазина под ключ с индивидуальной (уникальной) адаптивной темой оформления и проработкой юзабилити". Какие такие "баннеры категорий"? Для вывода категорий с изображениями и их подкатегориями есть много модулей. "Более красивые" для кого? Как определяется "красивость"? Тут надо четко описать, что и в каком виде вам надо. От качества и содержания изображений категорий (а они - ваша забота) тоже многое будет зависеть.

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

в каком виде? это может быть полотно данных.

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

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

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

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

нет. чтобы "подсказать" надо это "сделать". мне оно не надо.

"как-то" - можно. надо переписывать используемый обработчик ЧПУ (seourl / seopro / другое).

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

уехало в соответствующий раздел.

смотри, что в $this->session->data. если нет твоих данных в массиве про shipping - надо ловить раньше и сюда отправлять...

ммм... статические данные одинаковые для всех товаров? или что?

это ты не понимаешь. и уже ж была подобная тема?..

ручками. своими / автора модуля pdf-счета / стороннего разработчика.

"пример" так и не загрузился... старайтесь не пользоваться этим картинкохостингом.

шта?.. что за модуль? где "поискал..." и "оказалось..."?