Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Starychenko

Newbie
  
  • Posts

    30
  • Joined

  • Last visited

Recent Profile Visitors

5,913 profile views

Starychenko's Achievements

Contributor

Contributor (5/14)

  • Dedicated Rare
  • First Post
  • Collaborator
  • Week One Done
  • One Month Later

Recent Badges

8

Reputation

  1. https://www.htmlhelp.com/de/reference/html40/entities/special.html https://coderstoolbox.net/string/#!encoding=js&action=decode&charset=us_ascii
  2. @deeman , добрый день В вашем модуле есть метод checkEmailForUniqueness, который проверяет зарегистрирован клиент на сайте или нет по полю Email. И если зарегистрирован - клиент получит соответствующее уведомление и не сможет зарегистрироваться повторно на эту же почту. Мы используем на сайте более упрощённый вариант авторизации и регистрации клиентов по номеру телефона с применением маски. Покопавшись в файле simpleapimain.php я нашёл, что у Вас уже заложен похожий метод для номера телефона под именем checkTelephoneForUniqueness Если сделать правило проверки для поля Телефон через метод checkTelephoneForUniqueness и передавать его в метод значения поля Зарегистрироваться - это отлично отрабатывает на странице регистрации. Клиент не сможет зарегистрироваться, если уже существует учётная запись с таким номером телефона. Но при оформлении заказа в корзине, если клиент не авторизован - он получит уведомление из текста ошибки правила проверки. И не сможет сделать заказ до тех пор, пока не авторизуется на сайте. Подскажите, пожалуйста, Как можно это поправить ? Чтобы была проверка уникальности номера телефона при регистрации. Но чтобы была возможность оформлять заказ на этот номер телефона не будучи авторизованным, так как это работает с полем Email ? Заранее спасибо за помощь. Если нужна оплата за помощь - напишите, пожалуйста.
  3. Добрый день. Подскажите, пожалуйста, кто сталкивался подобной проблемой или кто может помочь на платной основе ? Вкратце опишу ситуацию и сделаю предположения, как это можно решить. Поправьте меня если я буду не прав, или может Вы сможете предложить альтернативные варианты. Есть донор, который отдаёт 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>
  4. В логах ошибка (Версия 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, которая закреплена за Украинской версией - всё будет Ок, ссылка будет корректная. На первой странице кто-то уже писал за подобный УРЛ
    Все супер. Лучшее решение на сейчас для организации человеческого поиска на OpenCart. Заказывал сразу с адаптацией под шаблон. Автору большое спасибо ! Сделал все на высшем уровне !
    Спасибо большое автору за хороший продукт. Очень крутой модуль. Также заказал за отдельную плату адаптацию у шаблону. Все работает отлично. Гугл уже начал индексировать изменения )
  5. Есть предложение при парсинге в ИМ в рамках одного проекта дать возможность пропускать в задании ссылки с ошибками. То есть мы начали сбор ссылок. Собрали предположим 12 000 ссылок. Из которых 1000 попалась с ошибкой 404 или ещё какой-то. И в парсинг мы должны отдать в идеале 11 000 ссылок с правильным кодом ответа.
  6. С версии OpenCart 3.0.3.7 минимальная версия ПХП которая нужна для работы - это 7.3 о чем Вам и сообщает ошибка. Или поднимайте Вашу версию ПХП или используйте 3.0.3.2 . Можно конечно руками поправить файлы, чтобы устанавливалось на 7.1 , но насколько корректно он будет работать - не знаю. Вероятно не просто так требуют 7.3 +
  7. Спасибо большое за совет. Я слишком сильно зациклился на своей идеи с умножением единицы и даже не подумал про умноженную цену или просто цену в количество. Одна из тех ситуаций когда нужен свежий взгляд ))
  8. @Rassol2 Добрый день. Есть предложение по внедрению нового функционала. Возможно это будет полезно для кого-то ? Рассмотрите, пожалуйста, возможно добавить управление количеством и периодами повторных авторизаций, в случае, если при сборе ссылок и парсинге произошёл сбой авторизации. Я заметил, что у меня периодически вылетает авторизация. После двух - трёх попыток повторной авторизации самого модуля - модуль завершает работу и переходит к следующему заданию. И если Вам не трудно - подскажите, пожалуйста, как решить такую задачу: 1. Парсим цену. Получаем исходный текст "2 500 руб." 2. Удаляем лишнее с помощью регулярного выражения {reg[#([\s\D])#]}| 3. Делим число и округляем вверх до 1 с помощью наценки {1|>}*0.000000001 На выходе я получу значение 1 , в случае, если цена была. И 0, если цены не было. Задача чтобы 1 умножалась на 9999, что по итогу эта граница использовалась для количества товара. В случае, если исходное число было бы равно нулю, то умножение на 9999 приводит к нулю и количество ноль. Добавить в начало или в конец значение 9999 не подходит, так как в случае, если значение после обработки равно нулю - к нему прибавляется 9999 и мы получаем 09999 или 99990. Что не подходит. Подскажите, пожалуйста, как решить эту задачу.
×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.