Starychenko
-
Публікації
30 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача Starychenko
-
https://www.htmlhelp.com/de/reference/html40/entities/special.html https://coderstoolbox.net/string/#!encoding=js&action=decode&charset=us_ascii
-
Перемога )
-
@deeman , добрый день В вашем модуле есть метод checkEmailForUniqueness, который проверяет зарегистрирован клиент на сайте или нет по полю Email. И если зарегистрирован - клиент получит соответствующее уведомление и не сможет зарегистрироваться повторно на эту же почту. Мы используем на сайте более упрощённый вариант авторизации и регистрации клиентов по номеру телефона с применением маски. Покопавшись в файле simpleapimain.php я нашёл, что у Вас уже заложен похожий метод для номера телефона под именем checkTelephoneForUniqueness Если сделать правило проверки для поля Телефон через метод checkTelephoneForUniqueness и передавать его в метод значения поля Зарегистрироваться - это отлично отрабатывает на странице регистрации. Клиент не сможет зарегистрироваться, если уже существует учётная запись с таким номером телефона. Но при оформлении заказа в корзине, если клиент не авторизован - он получит уведомление из текста ошибки правила проверки. И не сможет сделать заказ до тех пор, пока не авторизуется на сайте. Подскажите, пожалуйста, Как можно это поправить ? Чтобы была проверка уникальности номера телефона при регистрации. Но чтобы была возможность оформлять заказ на этот номер телефона не будучи авторизованным, так как это работает с полем Email ? Заранее спасибо за помощь. Если нужна оплата за помощь - напишите, пожалуйста.
-
Добрый день. Подскажите, пожалуйста, кто сталкивался подобной проблемой или кто может помочь на платной основе ? Вкратце опишу ситуацию и сделаю предположения, как это можно решить. Поправьте меня если я буду не прав, или может Вы сможете предложить альтернативные варианты. Есть донор, который отдаёт XML файл следующей структуры (будет ниже). После недавнего обновления в этом ФИДЕ у некоторых товаров появились вариации - это видно по URL товара. Есть одна и та же ссылка на товар (то есть один товар) с параметром ?variant= Если зайти по этой ссылке на сайт донор - станет понятно, что они предлагают: 1. Купить, к примеру 1 шт. по 913 гр-н 2. Или 6 штук (кол-во станет понятным только если посетить сайт) за 4 838 грн. То есть 1 шт. по 806 грн. Первая проблема: 1. При парсинге в ИМ для модуля это, по сути, один и тот же товар. Так как сопоставляю товары я пускай по имени товара. То есть при парсинге модуль сначала заливает цену 913, а потом 4838. Или, наоборот, если очерёдность в XML файле будет обратная. Можно было бы использовать проверку границ, и убрать из парсинга ссылки с содержанием ?variant= . И тут мы сталкиваемся со второй проблемой. 2. Большая цена не всегда в товаре с ссылкой у которой есть параметр ?variant= Я так понимаю, что эту проблему можно было бы решить с помощью PHP скрипта используя его перед парсингом в ИМ. Когда у модуля под рукой будут все обработанные и собранные данные, чтобы скрипт проверил: 1. Есть ли несколько строк с одинаковым артикулом 2. Если есть – нашёл все дублирующие строки одного артикула 3. Выбрал строку с наименьшей ценой, остальные дублирующие строки этого артикула с высшей ценой или удалил 3.1 Или перезаписал полностью все дублирующие строки этого артикула информацией из строки с низкой ценой. <offer id='1242' available='true'> <url>https://domain.com/products/75998a1-statuetka-nika-26-sm-75998a1</url> <price>913</price> <currencyId>UAH</currencyId> <categoryId>351</categoryId> <picture>https://domain.com/files/products/n6b4256eb6dd911e78f6cfcaa1403f838.500x500.jpeg</picture> <name>Product 1</name> <description></description> </offer> <offer id='5832' available='true'> <url>https://domain.com/products/75998a1-statuetka-nika-26-sm-75998a1?variant=5832</url> <price>4838</price> <currencyId>UAH</currencyId> <categoryId>351</categoryId> <picture>https://domain.com/files/products/n6b4256eb6dd911e78f6cfcaa1403f838.500x500.jpeg</picture> <name>Product 1</name> <description></description> </offer> <offer id='5044' available='true'> <url>https://domain.com/products/2003-023-chasy-2003-023</url> <price>1075</price> <currencyId>UAH</currencyId> <categoryId>89</categoryId> <picture>https://domain.com/files/products/ne210e939b92911ebb3f5ac1f6b279639.500x500.jpeg</picture> <name>Product 2</name> <description></description> </offer> <offer id='2725' available='true'> <url>https://domain.com/products/2003-023-chasy-2003-023?variant=2725</url> <price>185</price> <currencyId>UAH</currencyId> <categoryId>89</categoryId> <picture>https://domain.com/files/products/ne210e939b92911ebb3f5ac1f6b279639.500x500.jpeg</picture> <name> Product 2</name> <description></description> </offer>
-
В логах ошибка (Версия 1.0.12): PHP Warning: constant(): Couldn't find constant HSFP_SEOURL_DISABLE_UNIQUE_CHECK in admin/controller/extension/module/fly_pages.php on line 8 И на мультиязычном сайте к примеру если зайти сначала на русскую версию /all-products , а потом переключиться на украинскую версию, за которой закреплена ссылка /uk/all-products-uk - по какой-то причине УРЛ будет /uk/index.php?route=product/category&fly_page_id=1&path= Но если попытаться сразу зайти на ссылку /uk/all-products-uk, которая закреплена за Украинской версией - всё будет Ок, ссылка будет корректная. На первой странице кто-то уже писал за подобный УРЛ
-
Поисковая система с морфологией и релевантностью PRO
file залишив відгук до Starychenko sv2109 в Поиск
Все супер. Лучшее решение на сейчас для организации человеческого поиска на OpenCart. Заказывал сразу с адаптацией под шаблон. Автору большое спасибо ! Сделал все на высшем уровне ! -
Спасибо большое автору за хороший продукт. Очень крутой модуль. Также заказал за отдельную плату адаптацию у шаблону. Все работает отлично. Гугл уже начал индексировать изменения )
-
@Rassol2 Вот мы обсуждали доработку. Это по Вашей просьбе напомнить.
-
У меня каждый день собираться по cron ссылки и после этого обновляются товары. То есть в этом нет смысла. Я их удалю и потом они добавятся повторно.
-
Есть предложение при парсинге в ИМ в рамках одного проекта дать возможность пропускать в задании ссылки с ошибками. То есть мы начали сбор ссылок. Собрали предположим 12 000 ссылок. Из которых 1000 попалась с ошибкой 404 или ещё какой-то. И в парсинг мы должны отдать в идеале 11 000 ссылок с правильным кодом ответа.
-
С версии OpenCart 3.0.3.7 минимальная версия ПХП которая нужна для работы - это 7.3 о чем Вам и сообщает ошибка. Или поднимайте Вашу версию ПХП или используйте 3.0.3.2 . Можно конечно руками поправить файлы, чтобы устанавливалось на 7.1 , но насколько корректно он будет работать - не знаю. Вероятно не просто так требуют 7.3 +
-
Спасибо большое за совет. Я слишком сильно зациклился на своей идеи с умножением единицы и даже не подумал про умноженную цену или просто цену в количество. Одна из тех ситуаций когда нужен свежий взгляд ))
-
@Rassol2 Добрый день. Есть предложение по внедрению нового функционала. Возможно это будет полезно для кого-то ? Рассмотрите, пожалуйста, возможно добавить управление количеством и периодами повторных авторизаций, в случае, если при сборе ссылок и парсинге произошёл сбой авторизации. Я заметил, что у меня периодически вылетает авторизация. После двух - трёх попыток повторной авторизации самого модуля - модуль завершает работу и переходит к следующему заданию. И если Вам не трудно - подскажите, пожалуйста, как решить такую задачу: 1. Парсим цену. Получаем исходный текст "2 500 руб." 2. Удаляем лишнее с помощью регулярного выражения {reg[#([\s\D])#]}| 3. Делим число и округляем вверх до 1 с помощью наценки {1|>}*0.000000001 На выходе я получу значение 1 , в случае, если цена была. И 0, если цены не было. Задача чтобы 1 умножалась на 9999, что по итогу эта граница использовалась для количества товара. В случае, если исходное число было бы равно нулю, то умножение на 9999 приводит к нулю и количество ноль. Добавить в начало или в конец значение 9999 не подходит, так как в случае, если значение после обработки равно нулю - к нему прибавляется 9999 и мы получаем 09999 или 99990. Что не подходит. Подскажите, пожалуйста, как решить эту задачу.
-
Благодарю, решил таким образом {reg[#/catalog/[0-9]+/#]}
-
В меню "Пасинг в ИМ" есть в самом низу проверка границ. По примеру как ниже сделайте цену себе
- 13 587 відповідей
-
- 2
-
-
- simplepars
- парсинг товаров opencart
- (і ще %d)
-
Понял, спасибо большое, буду разбираться
-
Модуль пишет, что авторизация проведена не успешно и не найдено проверочное слово. Окей, я попробую ещё когда будут компьютера. У меня ещё используется proxy. Предположительно из-за этого могут быть проблемы ?
-
@Rassol2 Добрый день. Ловлю периодически ошибки авторизации при сборе ссылок по Cron и также при парсинге в ИМ по Cron. Пользуюсь авторизацией по POST запросы. Если в настройках проекта произвести авторизацию - она проходит нормально. Дальше в поле cookies заполняются куки и сбор ссылок или парсинг в ИМ идёт по cron идёт до момента, когда вероятно заканчивается срок жизни кукисов. Дальше парсинг или сбор ссылок останавливается, так как модуль не может найти мой логин, чтобы подтвердить авторизацию. Если к примеру перед запуском Cron в настройках проекта удалить cookies, и не проводить авторизацию вручную (то есть поле кукисов пустое, но настройка авторизации заполнена). То при запуске cron проект завершается по причине того, что он не находит фразу (мой логин, который подтверждает авторизацию). Я могу предложить, что модуль не может провести авторизацию по cron и провести повторную авторизацию, когда время сессии закончилось. Подскажите, пожалуйста, как это можно поправить ? Товары, которые я забираю с сайта донора - доступны только после авторизации на сайте. Заранеет спасибо большое за помощь
-
@Rassol2 Добрый день. Подскажите, пожалуйста, возможно ли использовать каким-то образом к примеру диапазон в отборе ссылок ? Есть сайт, у которого ссылки на товары и категории находятся на третьем уровне. И в данных ссылках всегда присутствует слово /catalog/. Итого для сбора ссылок я использую такую настройку Далее нам необходимо убрать из результата ссылки на категории. Все категории отображаются вот так /catalog/2745/ Я пока что руками вырезаю такие категории через доп фильтр. Ставлю в исключение /catalog/93/ ; /catalog/299/ ; /catalog/2745/. То есть приходиться каждую такую категорию указывать в доп фильтре. Возможно ли сделать это более правильным способом ? К примеру /catalog/[0-9999]/
-
@Rassol2 Что я сделал не так ? Все согласно инструкции. Как наценка, так и округление. 1. Диапазоны чисел указаны верно (1-9) 2. Умножение указано верно *0.1 3. Для того чтобы применить второе действие внутри правила используется символ & 4. Округление указано верно {1|>} после символа & как второе действие 5. Правила разделены ; как в Ваших примерах. Я комбинирую наценку и округление. Согласно Ваших мануалов - должно работать. Если я делаю не так, то что ? Можете, пожалуйста, как вариант показать правильный пример ? Строчка условий вроде как правильная. Пускай мы её даже упростим (1-999999)*0.000001&{1|>} - это все равно не работает
-
@Rassol2 , добрый день. В финальной версии модуля не работает наценка в пункте "Поиск и замена". Округление {1} или {1|>} не работает, хотя судя мануалу - должно работать. Логика такая, что если у товара есть цена = значит есть и наличие. Предположим, при цене 7500 я умножаю ее на 0.0001 на выходе получаю 0.75 , далее остаётся только округлить число вверх, чтобы получить 1 для поля БД status. Если цены у товара нет, значит нет наличия. Значит выражение ниже в любом из результатов вернёт 0 и статус будет 0. Умножение работает, а округление нет. И в пунктах "Парсинг в CSV" или "Парсинг в магазин" не работает арифметические выражение. К примеру если я хочу в статус добавить 1 или 0 таким образом: {gran_14}{/}{gran_14}. Где {gran_14} = 0,75 То для того чтобы получить 1 нужно прописать выражение {gran_14}{/}{gran_14}. В результате 0,75/0,75=1 , но результат я получаю 0,75. Третье, с чем я столкнулся - при установке через /inst.php я получал ошибку подключения к БД. По той причине, что у меня MySql работает на не стандартном порту. Вместо 3306 у меня 3310 (MySQL запущен через докер). По этому в файле /inst.php пришлось делать правку такого рода подключения к MySQL (колхоз, но как сумел).
-
Всем привет. Столкнулся с ситуацией, что после добавления кастомного поля формата "Дата" браузеры нагло пытались предложить заполнить в данное поле сохранённый E-Mail. Это очень жутко бесило, так как не давало возможности нормально ввести дату рождения. Поле это добавлял для проверки даты рождения клиента при регистрации, так как сам сайт подразумевает пользование лицам достигших совершеннолетия. Что было сделано: По адресу ниже, в файле simple_row_field.twig /catalog/view/theme/default/template/common Находим строчку кода: <input class="form-control" type="text" data-type="date" name="{{ name }}" id="{{ id }}" value="{{ value }}" placeholder="{{ placeholder }}" {{ attrs }} {{ reload ? 'data-onchange="reloadAll"' : ''}}> И меняем её на: <input class="form-control" type="text" data-type="date" autocomplete="off" readonly onfocus="this.removeAttribute('readonly')" name="{{ name }}" id="{{ id }}" value="{{ value }}" placeholder="{{ placeholder }}" {{ attrs }} {{ reload ? 'data-onchange="reloadAll"' : ''}}> Что изменилось: Добавлен атрибут autocomplete="off" , который не всегда спасает, но как заплатка указан. Добавлен атрибут readonly , то есть, сначала запрещаем редактирование поля. И добавлен атрибут onfocus , то есть по фокусу разрешаем редактирование поля. Таким образом мы решаем проблему не правильного autocomplete, автозаполнения у кастомного поля даты. Также бонусом ниже привожу регулярное выражение для проверки корректности даты. Регулярное выражение, пожалуйста, проверяйте под свои нужны. У кого-то возможно будет работать не правильно, в случае, если формат даты отличается от заданного в регулярное выражение. Но в принципе самые основные в нём заложены. Регулярка не моя, взята из просторов интернета. ^(?:(?:31(\/|-|\.)(?:0?[13578]|1[02]))\1|(?:(?:29|30)(\/|-|\.)(?:0?[1,3-9]|1[0-2])\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:29(\/|-|\.)0?2\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\d|2[0-8])(\/|-|\.)(?:(?:0?[1-9])|(?:1[0-2]))\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$
-
Отписался Вам в лс Спасибо большое
-
Всем привет. Стоит модуль Simple регистрация и чекаут. Настроить DaData на роуте checkout/simplecheckout и account/simpleregister удалось. По инструкции все сделал, работают все подсказки, все как следует. Но никак не получается завести DaData в личном кабинете но роутах account/simpleedit и account/simpleaddress/update Для примера на account/simpleaddress/update стоит код из третьего спойлера ниже. Макет для него создал (для всех роутов делал отдельный макет). Селекторы я поменял на свои. Во всех роутах они разные, поменял для каждого нужный. Все коды вызова из Simple ниже. Кто что может подсказать ? Что нужно сделать, чтобы запустить его ? if('checkout_simplecheckout' in window) checkout_simplecheckout(); if('account_simpleaddress/update ' in window) account_simpleaddress/update (); if('account_simpleedit' in window) account_simpleedit(); if('account_simpleregister' in window) account_simpleregister();
-
Вот в этой ветке обсуждали проблему блога, вроде с этой ветки я проблему и решил у себя когда-то Если магазин прям совсем новый - можно скачать уже правленую версию с GitHub https://github.com/ocStore/ocStore На крайний случай можно будет с GitHub достать уже правленые файлы и заменить их у себя
