r2d2

У меня вопрос, нашел в шаблоне template/product/category.tpl условие if ($product['rating']) { так вот можно ли где-то в настройках убрать вывод рейтинга в списке товаров? И вообще, для чего это условие, от чего оно зависит? В настройках ничего не нашёл...

мне пока не на чем тестировать...

А вот собственно и блекджек со... ну вы поняли. Сократил кол-во обращений к диску для записи до 1 на 1 файл за 1 загрузку страницы. Нужно затестить. UPD Перезалил. Вначале наворотил с сохранением в память всех затрагиваемых в процессе работы скрипта массивов кеша. Вернул как было раньше: те массивы которые не изменялись в процессе работы скрипта, по прежнему читаются с диска. Соответственно те что изменились — пишутся в память и по завершению работы записываются на диск. UPD Перезалил финальную версию с правкой freelancer. cache.php

Я как понял для того чтобы реализовать разбор "не уникальных" алиасов, в принципе нужно только знать родителя, для того чтобы сравнить его псевдоним с родительским из URI, и если он сходится, значит роут правильный. В принципе думаю что для этого достаточно будет только допилить подобным способом кеширование родительских связей, и можно будет юзать не уникальные алиасы. А многочисленную перезапись в цикле решил пока что с помощью tmpfs раздела в памяти в который пишутся файлы кеша. Но вполне реально сделать лишь однократное чтение из кеша в тот же объект $cache и до завершения работы скрипта работать исключительно с этим объектом. А при завершении скрипта при помощи __destruct() метода в классе Cache можно будет записать изменения на диск за 1 раз. Вроде как выглядит более чем реально... Поправьте меня если что не так говорю

да не, всё норм, просто оценю количество времени, если не слишком долго займёт, может сделаю. Ща другая проблема. Я так понял этот "кеш" это хреновая тема. Она конечно быстрее работает чем запросы к базе, но мля, за 1 цикл сохранения в кеш делается количество перезаписей 1 файла равное количеству товаров! Это жесть конечно) Ну и представить если: товаров более 1000, сответственно раз в час минимум перезаписывается 1000 раз 1 файл. Сутки - 24000 перезаписей минимум. Сколько времени проживёт винт? Надо какой то другой вариант придумывать. Возможно сразу html писать

Короче разобрался в работе всего этого дела глубже, многое понял) Ошибался.. Думаю.

Возможно мы друг друга не понимаем... Я предлагаю сделать разбор URI с обратной стороны. С конца то есть. Таким образом можно будет ТОЧНО определить id каждой категории (каждого кусочка URI между слешами) просто определив что родитель данной категории с не уникальным именем уникален. И в итоге собрать точный "path" ("20_34_67" как пример)

Вот только не пойму зачем воротить всё с нуля если можно доделать то что уже имеется? Да, только так работать не будет. Что будет например если родитель у категории сменится?

да я понимаю для чего тут кеш. Не в этом дело. Array_keys тут может понадобиться для поиска по значению элемента массива дублированных записей. Возвращать будет уникальные ключи (в зависимости от того сколько совпадений найдет). Соответственно можно будет отказаться от массива с ключами по keywords. Далее если array_keys возвращает более 1 ключа, циклом по ключам ищется и сравнивается РЕАЛЬНЫЙ родитель и его id. Ну и далее по тому же принципу — если родитель тоже дублируется, так же смотрим его родителя пока не находим элемент без совпадений. Получается разбор URI с конца а не с начала как сейчас реализовано. Таким образом можно будет вообще избавиться от массива с ключами по keywords. Поправьте меня если я что-то не так думаю. Совсем не понял что имелось в виду про "Пробуйте прописать и двигайте вариант с прописыванием полного пути к продукту /категрия1/категория2/продукт"

Ха, жестянка, перезаписываются элементы массива с одинаковыми индексами при составлении массива... Во попадос (: По этому редиректит именно на последнюю "одинаковую" категорию, потому как она в базе ниже по выдаче. Ну ясно. Единственное не понял, для чего перекрёстно 2 массива строится сначала keywords а потом queries, ведь значение впоследствии всё равно только из keywords берётся? UPD Тоже понял, для обратного преобразования и последующего сравнения в том месте где я показывал редирект. Печаль. Надо думать как запилить массив по другому. Я так понял в общем, основная проблема в реализации поиска по массиву. Но я думаю что array_keys всё равно работает быстрее чем запрос к базе (;

ага, увидел Кстати, класс Сache это стандартный опенкартовский или это часть SeoPro?

Я тут поелозил трассировщиком по seo_pro.php, нашёл где происходит коллапс. Нужна ваша помощь в пояснении. В общем вот в этом месте собственно генерится редирект на левую категорию. Происходит это из-за того что при начальном разборе URL (запросе в БД) походу не смотрится на то что при селекте категорий с одинаковыми алиасами их больше одной. Ну и подставляется почему то ID последней категории которую я добавил с таким же названием. Кеш соответственно заполняется тем же бредом. Единственное что, я не очень вдавался вглубь этого всего дела, не особо думал над каждой строкой попросту по нехватке времени, ткните меня в место где из контроллера происходит запрос в модель (в БД). Или даже лучше в то место где происходит проверка на наличие/отсутствие кеша. Ну и поговорить очень бы хотелось на эту тему, поскольку мне НУ ОЧЕНЬ НАДО. Думаю и другим тоже. Если будет возможность, киньте контакты как с вами связаться.

теперь уже И структуру И контроллер. ИЛИ уже не прокатывает. Ок, всё понял)) По структуре, поясните за правильную структуру по феншую. Я так понял вы шарите в ней.

чё то много текста, и никакой конкретики. Вы уж определитесь (если знаете конечно на практике как оно работает) структуру базы нужно менять или контролер дописывать/переписывать )) Лол

Плохо. Буду искать решение, либо если у вас есть время я бы был не против пообщаться на тему проблем допилить SeoPro. Я разработчик.