rb2

Некоторые вот отдают себе отчёт, что сборка может быть удобна не только конечным пользователям, начинающим с нуля, а и разработчикам. И цена такого подхода не отличается от нынешнего. Садить картошку любит и OCSHOP, понимаю. Идущий ровно по тем же граблям, что и ocStore. Ну и упоминание темпов при разговоре про ocStore я считаю очень символичным :) Очень.

Seopro бесплатен и для 2.x, и для 1.5.x. H1 и title не настолько сложны, чтобы их было затратно добавить в оригинальный OC. Так что про единственное решение за $100 - это преувеличение. Неправильно локализовать - я даже и не знаю, как это :) Тоже совершенно не проблема. Оптимизация - да, присутствовала местами. Но это тоже гораздо удобнее было бы иметь в виде поддерживаемых сообществом патчей или vqmod/ocmod расширений, а ocStore собирать из них.

Ну самое очевидное - редиректом в контроллере common/home. Если это по каким-то причинам не подходит - разбираться, как роутинг устроен и то ли в index.php, то ли в seo_url/seo_pro менять.

Я так понимаю, что всё же в _RU.zip они на русском, а в UA.zip на украинском. Чтобы сделать "И" и иметь географию на нескольких языках одновременно, надо движок и структуру БД менять.

Без понятия. Не пользовался.

Будем обсуждать значение слова "подобный"? Да, там не то же самое один в один. Там модуль расылки уведомлений и слежения за одним из полей товара. В каком-то из описаний была заявлена совместмость с несколькими модулями обновлений остатков, цен и т.п.

Был. OCU Waitlist (автор Shaman) года 3 как лежит на гитхабе.

Seopro?

Если главная не нужна, надо не впихивать невпихуемое на неё, а просто отказаться от её использования и сделать стартовой страницу категорий.

Я написал, что именно я не понимаю и хочу уточнить. В первом сообщении Вы пишете, что не используете в опенкарт поле модели, потом оказывается, что оно, возможно, таки используется каким-то модулем. Если используется (Вами, модулем - какая, блин, разница? Используется у вас на сайте? Значит используется в вашей установке опенкарт, Вами, у Вас), то этот совет может не подойти и оказаться вредным. Поскольку судя по вопросам Вы не слишком уверенный пользователь Опенкарт, я и пытаюсь максимально точно очертить круг применения и предостеречь от экспериментов в неверном направлении, как только появились новые детали.

Это всё равно неполная постановка вопроса. Главный вопрос звучит так: вы будете требовать от покупателей указания email? Или хотите полностью про email забыть и требовать от покупателей только номер телефона? Все остальные детали второстепенны. Если задача заключается в отказе от email как от обязательного к заполнению поля - надо обязательно переделывать все имеющиеся места отправки писем и вставлять проверки на его существование. Потому что движок просто не готов к тому, что поле может быть пустое.

Ну как не зависит, если по приведённой ссылке на мой древний рецепт - дебильная опенкартовская реализация через рекурсию? На каждую вложенность - запрос (или несколько, не помню уже). Если делать нормально, то необходимое кол-во уровней спокойно вытаскивается ОДНИМ запросом. И потом результат лучше всего закешировать, т.к. категории не ежеминутно меняются.

Я не понимаю. Поле модель не используется (см. первое сообщение), но используется (см.последнее). Это как? Если модель не используется в Вашей деятельности, но движком уже везде выводится - храните в этом поле нужную Вам строку SKU и просто переименуйте поле.

Другие предложения - приобретать программиста. Или продублировать SKU в поле Модель, раз её не используете. Тогда в уйме мест ничего менять не придётся, просто в языковых файлах поменять все "модели" на SKU.

Почему? Помедитируйте над таблицей `oc_product_option` и привязывайтесь к `product_option_id` Хотя я бы поискал какой-нибудь готовый модуль для объединения кучи товаров в один. Возможно, гораздо меньше переделывать придётся - скачивание, покупку с разграничением, обслуживание всего этого зоопарка файлов скорей всего удастся оставить и не трогать.

В такой сценарий я бы поверил, если бы получил в тикетах задачу от тимлида/ПМ-а, хорошо знающего кишки опенкарт и аутсорсящего задачи разным разработчикам. И то уточнил бы. А в той ситуации, которая есть на форуме, приходится думать за спрашивающих и предугадывать на 10 шагов вперёд все следующие вопросы и проблемы.

Очень сомневаюсь. На обязательный email много функционала завязано. Чтобы от него избвиться - переколбасить придётся и каталог, и админку. Боюсь, цифра порядка 50 файлов будет ближе к правде.

http://www.opencart.com/index.php?route=extension/extension Да и весь опенкарт.ком. youtube.com habrahabr.ru

Какую такую заплатку? Для этого просто в настройках магазина надо указать, что UAH - валюта по умолчанию в магазине.

Что-то мешает использовать стандартные статьи?

Похоже на REST API.

Иногда мне кажется, что SMTP настройки надо просто выпилить из Опенкарта и у всех всё внезапно станет работать. Покажите мне хостинг, где отправка через `mail()` не работает?!

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

Удалите 2.0.0.0 и поставьте 2.0.1.1

Ставлю задание научиться пользоваться поиском и читать правила.