Ive

Приветствую, форумчане!

Уже несколько дней ломаю голову пытаюсь найти причину досадной ошибки: вылазит окно "error undefined" и невозможно оформить заказ - часть корзины с суммой в бесконечной загрузке.

ошибка возникает, когда в корзине меняешь язык несколько раз (к примеру на укр> рус > укр) и остается (как подозреваю) с куки файлами на стороне клиента.

При детальном рассмотрении и, танцами с бубном и клацаньем во все кнопки, выяснилось:

>>> что проблема пропадает при отключенном SEO PRO - чпу. 

>>> в логах пишется, что ошибка 301 xhr / Redirect, при этом редирект происходит по след. принципу, ссылаясь на самого себя с другим языком : (фото) 

jquery
> /index.php
> /ru//index.php
> /index.php
> /ru//index.php
> ..... 

при этом затрагивается только два файла: shipping_method&ajax=1 и country&country_id=220 

>>> При дальнейшем переключении языков ошибка не пропадает

>>> Обновление кеша, его удаление, перегрузка модификаторов на стороне сервера (сайта) не сбрасывает эту ошибку, она "в куки" клиента

>>> Отключение методов доставки не влияют на появление ошибки (ошибка так же появляется) 

>>> скрипт jquery не модифицировался 

>>> config.php настроены на htps

>>> код htacces (части строк заккоментированные: пробовал и так и так

RewriteBase /
#RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
#RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

RewriteCond %{HTTP:SSL} !=1 [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteRule ^system/download/(.*) index.php?route=error/not_found [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)


RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

Помогите, пожалуйста, я уже не знаю в какую сторону копать

> версия ocStore 3.0.2.0

Установленные модули:
> Шаблон Revolution

> SEOPRO базовый (встроенный в ocStore) 

> Seo мультиязык/мультирегион

> доставка Новая почта API 

В 04.05.2020 в 00:51, Rassol2 сказал:

@ILexus сразу сходу плюсу!
Достойно уважения если у вас есть задача и вы сами начинаете ее решать это всегда ценно.

 

это все есть в задачах на реализацию, и будет сделано.

 

этого действительно никто еше не писал, о системе бонусов нет ни единого упоминания.
 

по двум причинам.
1. как уже написал действительно никто не спрашивал.
2. мне не совсем понятно как это вяжется с идеологией парсинга товаров. Навряд ли кто то эти данные будет парсить. Если их нужно заполнять в товары тогда для этого есть свои инструменты. Какие не будь пакетные редакторы товаров. Что то на подобие bath_editor, данный функционал подходит под пакетный редактор товаров чем под парсинг.

 

Если и буду реализовывать то это будет уже в виде функции на вкладке редактора товаров.

 

 

В данном случаи используется стандартный подход опенкарта. У вас более специфичный подход к своему товару.
В данном случаи это поле еше можно парсить а не только использовать стандартный подход.

 

Но ведь по сути вы используете тот же самый id товара только прибавляете к нему 67941
В этом я не вижу большого смысла. Допустим код товара 87651 и вы добавляете к нему 67941 и получаете уникальный 155592
Почему в таком случаи не использовать просто уникальный 87651 он такой же уникальный как и 155592
Возможно для вас лично это критически важно, но давайте взглянем на саму задачу является ли для всех пользователей интернет магазинов на опенкарте критически важным иметь model численным и обязательно отличающимся от id товара. Ну или хотя бы какому количеству пользователей это действительно важно?

 

 

Вот ответ на этот вопрос может породить много недовольства ко мне. Но попробую правильно объяснить мой выбор.

Ситуация такова. Если я приму ваше решение и внедрю в ядро модуля то я как минимум должен убедится что все работает верно и это вяжется с заложенным фундаментом модуля. Я не говорю что вы сделали неправильно я только про то что для меня будет сложнее сейчас убедиться в том что все сделано с заложенными идеями чем реализовать самому.
К примеру банально если пользователь выбирает обновить SKU и SKU является идентификатором товара, то модуль это обнаружит и не даст сделать проблему.
То же самое касается выхлопов в логи, модуль проверяет и делает сообщение в логи по поводу того спарсен не спарсен идентификатор, он пуст или не выбран.
То есть есть все обработчики этих событий. Вы их предусмотрели при внедрении этих дополнительных полей ?

PS. В остальном я тоже не силен в PHP скажем так я начал его изучать тогда когда начал писать модуль
Так что если вы смогли разобраться в этом безумстве то думаю уже поняли что я тоже далеко не профи. Но у нас есть идеи для реализаций это куда важнее.

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

  Показать контент

 

И мой код уже отличается от того что есть в релизе.

А вообще так сообщу что сейчас идет по планам.
1. Допилы редактора товаров на горячую.
2. Сбор ссылок по крону.
3. Загрузка фото описаний. (Возможно загрузка файлов типа инструкция и тд.)
4. Система проверки границ парсинга и допусков к работе с товаром. Типо указываем если граница пустая то не добавляем товар не обновляем .... Или если граница равна какому то значению.
5. переработать систему работы с ссылками, дать возможность получить список ссылок которые не были спарсены или спарсены с ошибками, и тд. Возможность перезапустить парсинг исключительно по проблемным ссылкам.
6. Автоматическая авторизация на сайте доноре, и работа этой схемы в связке с кроном.

Это все планы на следующие месяцы. Так сказать основные точки отсчета.

Добрый день и с Новым Годом) 

Хочу поблагодарить за действительно полезный и удобный модуль.

Так же очень хотелось бы видеть работу с бонусными балами (цитированное сообщение, а так же вопрос от пользователя @ILexus ). На мой взгляд удобно форматирование, которое предложил пользователь @ILexus. Спасибо