

DmitryBugrimenko
Користувачі-
Публікації
80 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача DmitryBugrimenko
-
Здравствуйте, хотел бы уточнить вопрос лицензирования модулей оплаты, обычной и отложенной, в связи с выдачей отдельных лицензий на домен и каждый из его поддоменов. Модули куплены. Конфигурация системы такова. В DNS для моих поддоменов (для удобства назову домен 2-го уровня 'domain') www.domain.ru, ftp.domain.ru, mail.domain.ru, т.д. моего домена 2-го уровня domain.ru настроены CNAME-записи так, что по ним поддомены разрешаются сначала в domain.ru через CNAME-записи и затем в IP-адрес через A-запись. Иными словами, делаю перенаправление www.domain.ru и остальных 3-го уровня на domain.ru средствами DNS. (За этим может следовать перенаправление на конкретный сервер пула балансировщиком по TCP/80, TCP/443, TCP/21, проч., но это уже другая история.) Обычная практика. URL магазина – http://domain.ru/..., в config.php – define ('HTTP_SERVER', 'http://domain.ru/...'). Настройки на стороне Яндекса для сheckURL, paymentAvisoURL – https://domain.ru/... Лицензии на модуль получал 1) для домена 2-го уровня в пром. эксплуатации domain.ru, 2) для домена 3-го уровня разработки и тестирования test.domain.ru. ВОПРОС: будет ли обоснованным предположить, что модули оплаты при проверке лицензии проверяют доменную часть URL-а магазина в точности как оно настроено для магазина в OpenCart? Покрывает ли лицензия, запрошенная на домен 2-го уровня domain.ru, также и общепринятые для веб-сервисов домены 3-го уровня вида www.domain.ru, www1.domain.ru, т.п.? (Хотелось бы, ибо это общепринятая практика, но посмотрим.) Спасибо.
- 604 відповіді
-
- art&pr
- ип и юр лица
- (і ще %d)
-
Интересная информация на http://store.pe-art.ru/key: "Обработка Вашего запроса на получение ключа может занять некоторое время. (до 72 часов, но обычно сроки более короткие до 24 часов)" 72 часа = трое суток! Но мы ж никуда не торопимся.
- 604 відповіді
-
- art&pr
- ип и юр лица
- (і ще %d)
-
Для других покупателей – автор делает индивидуальные ключи для каждого поддомена основного домена. Имейте в виду, чтобы, как я сейчас, не попадать в длительно-утомительную переписку через ЛК (а нафиг нам email, у России же свой особенный путь) и ждать нужных прямо сейчас тестовых ключей непонятно сколько.
- 604 відповіді
-
- art&pr
- ип и юр лица
- (і ще %d)
-
"Написать личное сообщение" вынести в шапку темы и в readme.txt, пожалуйста. Покупал здесь, ессно ни на какие pe-art не ходил, есть и без этого чем заняться. Спасибо за понимание.
- 604 відповіді
-
- art&pr
- ип и юр лица
- (і ще %d)
-
На странице настроек модуля отсутствует адрес электронной почты, на который слать запрос на ключ. В файлах поставки модуля также отсутствует адрес электронной почты, на который слать запрос на ключ. Это нормально? Нужно продолжать упорно искать способ?
- 604 відповіді
-
- art&pr
- ип и юр лица
- (і ще %d)
-
Simple 4.6.0, Доставка Плюс 3.6. В модуле Доставка Плюс настроены 27 способов доставки, из которых 1 выключен. В Simple на вкладке "Оплата" при выборе "Отображать данный метод только для указанных вариантов доставки" = "Для выбранных" отображаются лишь 24, в т.ч. выключенный. Не хватает крайних трёх. Почему? Что делать?
-
Я что, спрашивал как отключить??? Я это вообще читать не буду - я спрашивал, как создать геозону из 86 регионов. Отключение части из них ни меня, ни остальных читателей этой нитки не интересует. Тем более платными (!!!) модулями за элементарное редактирование таблицы базы. Это к ламерам. Мне нужно решение моей задачи, а не любой другой и не методом грубой силы. Прошу не засорять эту нитку. Подождём ответа знающих PHP и OC...
-
Я не понял, вы успешно создали геозону из всех регионов РФ, или с тем, что вы создавали (что???) всё было в ажуре? Метод удаления "типа ненужного" – не наш метод, негодная безответственная рекомендация, не вариант. Вспоминаем, что система будет эксплуатироваться продолжительное время и разными людьми, которым эти зоны могут понадобиться. Это предостережение – начинающим админам и владельцам интернет-магазинов, которые могут читать эту ветку. Залечивание методом грубой силы ударит вас в самый неожиданный и неподходящий момент. Не вопрос ударит ли, вопрос когда и насколько больно. Кто не верит – пусть проверит, как говорит Петрович (ударение на Е). 100500 – это чушь, их всего 86. Теперь подождём ответа знающих PHP и OC...
-
Именно так и добавляю – каждый из регионов вручную. Зачем изначально добавлять ненужные? Ненужных – пара-тройка, и на наблюдаемый косяк они не влияют. Никаких посторонних импортов/модулей/SQL-запросов. Геморройно не создание геозон, сказки это всё, а архитектура OC в части геозон и её ущербность для применения за пределами США, но это отдельная история. Неужели у всех такая зона создаётся без проблем? Кто-нибудь может у себя проверить? Всего-то 86 регионов, делов на 5 минут.
-
Здравствуйте, создаю геозону "Вся Россия" из 86 регионов (чтобы затем селективно удалить избранные регионы), сохраняю, снова открываю и в некоторых строках в поле "Регион" – пусто. Выхожу из описания зоны, снова открываю её – появились новые пустоты. В ниспадающих списках пустот тоже пусто. Зона из ~80 регионов ведёт себя пристойно. Снимки экрана прикрепил. ocStore 2.1.0.2. В чём может быть проблема и как с этим злом бороться?
-
Здравствуйте, модуль доставки по области в названии метода доставки использует название геозоны, напр., для г. Дубна в зоне "Московская область" метод получает название "Московская область (Дубна, 100 км от областного центра)". В OC название геозоны ограничено по длине от 3 до 32 символов. Однако, для геозоны существует обязательное поле "Описание", такими ограничениями не страдающее. В поле "Описание" геозоны можно вписать, напр., "Доставка курьером интернет-магазина" (длина 35 символов). Прошу добавить в модуль использование для названия метода доставки поля "Описание" геозоны вместо ограниченного имени геозоны. Или, ещё лучше, индивидуальное поле "Название способа доставки" для каждой из подхваченных модулем геозон. Модуль куплен. Спасибо.
-
Здравствуйте, модуль доставки по области не имеет настройки названия общего заголовка для блока выбора способов доставки, в отличие от, напр., модуля Доставка+ ('Общие > Название'). Как следствие, в форме оформления заказа безусловно выводится заголовок "Доставка по области" и разрушается дизайн формы, который не предусматривает вывод заголовков модулями доставки. Прошу добавить в модуль настройку названия заголовка для блока выбора способов доставки, с возможностью оставить это поле пустым, когда необходимо подавить вывод заголовка полностью. Модуль куплен. Спасибо.
-
Ещё раз перечитал своё непорочно чистое и искреннее первоначальное предложение и соображения. Старался, но не смог найти в нём бла-бла-бла, прочего текста, требующего бесконечных тупых переделок, свое тупости (но я ж не менеджер проекта?) и не состояние понять чего-то. Каюсь, слаб умишком, держу всего лишь два интернет-магазина, работаю там главным бухгалтером, генеральным директором и по совместительству учредителем, иногда водителем-экспедитором. (В своё время сам развозил товар и Ингвар Кампрад, основатель компании IKEA, значит, и нам не стыдно?) К Вашим обидчикам по предыдущим местам работа отношения не имею, хотя и места озвучены не были. Боль и горечь разделяю, сочувствую. Использовать коммерческих пользователей продукта как бета-тестеров это точь-в-точь по 1С-программистски, т.е. негодно, при всём уважении. Ну а так-то я лошара, вне всяких сомнений ;) Ответ же обидел до глубины души. Чего хотел для дела - не получил. Ухожу. Хорошего дня!
-
Кстати, есть такая удобная фенька как автозаполнение адреса в формах оформления заказа. И всё бы хорошо, только реализует его кто как может, мне известны, как минимум, четыре первоисточника, используемые авторами модулей автозаполнения: эталонный справочник почты россии, КЛАДР, ФИАС, самопал. Желающие чуть ближе познакомиться с ущербностью КЛАД и ФИАС – читать здесь: https://habrahabr.ru/company/hflabs/blog/230823/ Соответственно, в поле "Город" Вы можете найти (программно, разумеется) всё что угодно, напр., "Комсомольск на Амуре", "г Комсомольск на Амуре", "г. Комсомольск на Амуре", далее вариации на тему "Комсомольск-на-Амуре". Понятно, что это не МО, но наглядно демонстрирует идею в худших её проявлениях. Добавляйте е/ё, и/й по вкусу. И все эти вариации для покупателя – одно и тоже место на карте. ВЫВОД: чтобы пользователь модуля не налетел на вилы в один прекрасный день (иными словами, ковыряем один модуль/форму – слетает другой/всё, покупатели матерятся, менеджеры матерятся, все недовольны, заказы срываются), во-первых, перед сравнением поля "Город" с тем, что перечислено в настройке "Доставки по области" обязательна нормализация обеих текстовых строк – выкинуть whitespaces, пунктуацию, преобразовать к одному регистру, е/ё и и/й обезличить, проч. Во-вторых, искать не точное соответствие строк, а вхождение подстроки (из перечня населённых пунктов в настройках) в строку (поле "Город" формы). Согласны?
-
Идея прекрасная! Однако, имею практический вопрос: у меня есть доставки пешими и конными курьерами магазина, курьерами транспортной компании, ПВЗ. Каждый способ имеет предпочтения и далее непреодолимые ограничение по весу брутто и габаритам в транспортной упаковке (это не то, что в карточке товара – там вес нетто и габариты товара для покупателя). Способы доставки в OC обсчитываются и выводятся плохо неуправляемым зоопарком модулей (в т.ч. Доставка+, Доставка по области, Simple, ПВЗ, Почта России от других разработчиков, проч.) Как теперь эту прекрасную (особенно, если добавить ещё характеристик товара из реального мира – вес, хрупкость, жидкость, проч.) идею модуля "Габариты товара" заставить оркестрировать весь этот зоопарк? (orchestrate ['ɔːkɪstreɪt] – гл. 1) инструментовать, оркестровать 2) планировать, организовывать (что-л.); быть организатором (чего-л.)) Альтернативные решения? (В рамках OC, без задолбавшего уже PHP-программирования всего и вся с чистого листа каждый раз; про Magento, Broadleaf и Prestashop знаю.) Спасибо! P.S. Чем дальше в лес, тем больше OC = детский сад.
-
Да похоже нету нифига. Как водится в великой и могучей России – всё нужно сделать самому. Пойду и, наконец-то, прочитаю "OpenCart Theme and Module Development" https://www.packtpub.com/web-development/opencart-theming
-
Удлинить сутки я не смогу, а сократить трудозатраты на этапе проработки требований к модулям мы все здесь в состоянии. Вы вполне можете опубликовать ТЗ (product requirements document, или как там оно зазывается кириллицей), и заинтересованные лица здесь осмыслят, исправят, дополнят, посоветуют. Это сократит время на непосредственное кодирование и бесконечные переделки. Если Вы участвуете в больших/тяжёлых софтовых проектах - не мне Вам про это рассказывать. Эту часть работы считаю архи-важной, ибо то, что мы видим сегодня из модулей для OC, пригодно к промышленному применению в условиях РФ либо весьма приближённо, либо исключительно в определённых конфигурациях бизнеса, когда вдруг чудом оказалось, что из всех незапрограммированных (читай не заложенных в дизайн) функций и параметров вам вдруг ничего не понадобилось. Хотя, с другой стороны, если магазин продаёт товар с наценкой в 300% (наш совковый случай!), ему должно быть просто наплевать, сколько машин отправить по цене пешего курьера за 100 км от МКАД. Это никоим образом не умаляет усилий разработчиков и кодеров, не поймите меня неправильно. Далее, Вы вполне можете предоставить новую редакцию модуля группе бета-тестеров (я не ворую, остальные здесь, полагаю, тоже), и мы подвергнем его в наших контурах разработки и тестирования такому насилию, что вылезут все мыслимые и немыслимые дефекты дизайна и кодирования. Попробуем на модулях курьерской доставки со статически задаваемыми параметрами? С нашей стороны всё совершенно бесплатно, пользуйтесь ;)
-
Было бы то что нужно! Осталось определить условия и сроки :) На мой взгляд, параметры в модуле доставки по области должны в точности повторять параметры "опорного" способа в Доставке+, ибо из города отправление вывезти всяко придётся, т.е. внегородской сегмент является ничем иным как продолжением городского, и отличие внутри- и внегородского двух сегментов – лишь в добавлении километража на внегородском. Возможно, правильной реализацией этой модели ценообразования было бы добавление доставки из нескольких сегментов в Доставку+. А может быть, и расширение модуля доставки по области, код же переиспользуемый, по всей видимости. Аккуратное планирование заменяет продолжительное кодирование ;) Наличие поддержки групп в моём конкретном случае помогло бы устанавливать правильную стоимость доставки для крупногабаритного и при этом не обязательно массивного товара. Но машина-то не резиновая.
-
Настраиваю для совместного использования "Доставку+" и "Доставку по области". Стоимость доставки по области суммируется со стоимостью доставки по городу, которая, в свою очередь, зависит от веса. Однако, модуль доставки по области не позволяет указать цену за 1 км пробега в зависимости от веса. Сможете ли добавить в областной модуль код и настройку цены за 1 км пробега, зависящей от веса? Спасибо. Дополнение: Ещё, конечно, очень помогла бы поддержка "Группы товаров" в "Доставке по области". Напр., для создания отдельных для крупногабарита, хрупкого, т.п. Это возможно добавить?
-
В корзине пишу "Удельная". Если бы модуль не нашёл – не было бы вывода названия населённого пункта и расстояния до него, а он есть. Снимки с экрана, демо-сайт: https://drive.google.com/file/d/0B6jJgft1-HT7eC1JOURvYTJ0Nlk/view?usp=sharing https://drive.google.com/file/d/0B6jJgft1-HT7QlBITF9LS1d3Vnc/view?usp=sharing https://drive.google.com/file/d/0B6jJgft1-HT7TWNPUmk0a2ZSX0k/view?usp=sharing
-
Будет ли для ocStore 2.1 ? Кто какие аналоги и замены использует, пока не появилось?