RGB

Может быть дело в том, что магазин находится на поддомене и имеет адрес localhost/opencart? Мне не приходит в голову, как это проверить

Аналогичная проблема, только циклическая переадресация возникает не на главной, а на категориях/товарах с прописанными сео-адресами (чистая версия отсюда 1.5.2.1). Файл htaccess – с магазина версии 1.5.1.3, где все в такой конфигурации работало. Предложенное решение с кеширующим сео_урл работает, но лишь для английских названий, кириллица в ссылках при этом не катит. У кого есть идеи, как можно решить проблему? Переводить все русские ссылки на английский не хочется, так как поисковики уже съели их. P.S. Речь идет про seopro, обычная система чпу работает как надо.

Новый модуль импорта-экспорта с поддержкой фильтров для версии 1.5.1.Х: http://opencartforum...1x-filter-soor/

Супер, именно такого развернутого ответа не хватало. Да, действительно, у нас крупные платежи практически все по банковским переводам идут, пожалуй если и есть смысл у ввода карточной оплаты, то вполне должно хватить того же LiqPay. Спасибо, вы мне изложили именно те аргументы, которых не хватало! :) undefined

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

Если я все правильно понял, то скрестить новый модуль импорта без фильтров со старым модулем с поддержкой фильтров вполне реально - добавляется пара новых функций + чуть изменений по коду. По крайней мере, у меня он после 5 часов мучений заработал с виду корректно :). Но я импортирую опции с отдельных таблиц, они не связаны с родными для версии 1.5.1.3 аттрибутами. Если кому-то надо такой не оптимальный вариант, могу выложить.Оффтоп: терпению менеджера можно только позавидовать :)

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

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

Простите, но вы, по всей видимости, и являетесь автором того модуля, верно?Вас в этой теме много раз просили поделиться адаптированным модулем под версию 1.5.1.3, не могли бы вы его выложить, раз он уже готов? Буду благодарен не только я.

Есть решение "в лоб" - работать с локальной версией сайта, при обновлении базы сливать бекап с инет-версии сайта на локальную, заливать туда все товары модулем экспорта-импорта, делать бекап локальной версии и заливать дамп в инет-версию сайта (если просраны все лимиты, можно кусками заливать). Таким образом можно честно обойти ограничения на память пхп (в каких-то пределах наверное, но теоретически дамп можно разбить на сколько угодно кусков, и база может иметь и 100 000 товаров, пофигу). У меня сейчас xls-версия базы, которая импортируется, весит почти 300 мб, а дамп базы всех таблиц около 70 мб, при этом в базе всего 4000 товаров, но на каждый описания от 2 до 7 тыс символов.

Видимо, вы как раз залезли в те дебри, куда я пока не могу попасть - я оценивал скорость работы по этому модулю: http://forum.opencart.com/viewtopic.php?t=27918Вы не пробовали измерять результаты работы именно через него?

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

Да уж, редизайн за 20$, да и столько же за доработку напильником - это вы сильно придумали :lol: Мне кажется, если у человека есть деньги на интернет и он занимается веб-программированием, то, как минимум, предлагать такому человеку плату в 5$/час – это не серьезно. Может сразу поищите индусов, готовых работать за еду?

Если вы хотите перенести лишь только категории и товары, то снимите галочки со всех остальных (не нужных) таблиц. Зачем вам адреса клиентов? Сохраните их отдельно, если уж это критично, иначе ищи те ошибки в таблице - если все выполнено правильно, то восстановление БД произойдет без ошибок.

Зачем изобретать велосипед? В систему встроен удобный инструмент бэкапа базы - делаете на старом домене бэкап по всем полям, открываете в текстовом редакторе и заменяете все упоминания вашего старого домена на новый, и восстанавливаете бэкап на новом домене. Разумеется, движки должны быть одинаковыми.

Не знаю почему, но у меня оптимизировать не только не получилось, но и совсем наоборот. Не знаю КАК у вас получилось 1000 запросов на главной, у меня все немного иначе. В базе около 2500 товаров, главная до оптимизации: Memory Usage: 1.573029 MB Execution Time: 0.354942 seconds 75 sql queries executed: После: Memory Usage: 1.584435 MB Execution Time: 0.656461 seconds 75 sql queries executed: Однако не могу сказать, что все удалось выполнить - некоторые описанные в диффе вещи у меня просто отсутствовали, так как раньше были исправлены, а вот с выводом кол-ва запросов (если я правильно понял последние пару изменений) у меня вообще не получилось - возможно потому, что для отладки уже использовался модуль с офф. сайта. Я никоим образом не хочу сказать, что ваше предложенное решение бесполезно, но мне оно не помогло - возможно виной тому и так уже раскуроченый движок.

Тут может смущать лишь боязнь запороть базу, но, естественно, бэкапы никто не отменял, поэтому в течение недели напишу о результатах. Странно, что никто больше не написал в теме - вопрос-то действительно важный, и я не думаю, что все прямо сходу перешли на версии 1.х

Попробую на досуге воспользоваться вашим решением.

Просто выкинуть кусок кода с ним из всех файлов шаблона, где он упоминается: \catalog\view\theme\имя_темы\template\checkout\

Старая уже допилена до такого состояния, которое у новой еще не наступило, поэтому в ближайшее время ответ - нет.

Это на локалке: Заметил такое отличие - на хостинге сначала значения main_category_id равнялись "0", в то время как на локалке они равнялись "NULL"

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

Да, но кнопка Купить и корзина то все равно останутся.Первое, что мне приходит в голову - это закоммментировать вывод ненужных блоков корзины, входа в аккаунт и кнопки купить, после чего посмотреть как выглядит магазин и все ли работает, если все ок - то выкинуть подальше ненужные куски кода: для всего, что в шапке (Личный Кабинет/Корзина/Оформить + валюты если надо и т.п.) \catalog\view\theme\default\template\common\header.tpl для всего, что в футере (там Личный кабинет и все меню его убрать) \catalog\view\theme\default\template\common\footer.tpl для всего, что в карточке товара выводится (там убрать кнопку Купить и цены) \catalog\view\theme\default\template\product\product.tpl ну и наверное всё, "случайно" никто ничего купить по идее не сможет, а визуально получится тот же каталог.

Наверное рано я радовался по поводу того, что модуль сразу заработал - на локалке все как то само собой настроилось, а на хостинге - нет. На локалке я не прописывал родительские категории ни одному товару, тем не менее они автоматом откуда-то поднялись, то есть ссылка на товар стала вида: категория/подкатегория/псевдоним_товара Абсолютно такой же движок с такой же базой на хостинге, при этом после копирования модуля и замены нужных файлов ссылки на товары стали страшного вида: index.php?route=product/product&product_id=айди_товара Когда вручную в админке на хостинге указал родительскую категорию товару, то его ссылка пришла в порядок и приобрела такой же вид, как и на локалке (т.е. стала такой: категория/подкатегория/псевдоним_товара) Но проблема в том, что в магазине больше 2000 товаров и вручную проставлять каждому эту родительскую категорию будет очень неудобно. Есть ли какие-то еще способы решения такой проблемы?

Не вижу ничего глупого спрашивать о версии магазина, так как неизвестно что стоит у товарища pavelchervov, каковы его познания в htmll/css и помогут ли мои советы. Я имею кое-какой опыт работы с версиями ocstore до 0.1.4, а поскольку в новых версиях произошли определенные изменения в шаблонах, то рекомендации относительно старых версий могут быть неприменимы к новым. Мне кажется это очевидно.Если же вам кажется глупым вопрос топикстартера, то к чему цитировать меня? pavelchervov, вы так и не ответили, что вы хотите убрать из текущего функционала магазина.