Scyth

В 24.03.2019 в 14:43, AlexDW сказал:

потому что зависит от сессий

если время жизни сессии меньше выставленного в правке - не поможет

в то же время, делать большой срок хранения сессий - зло

 

ну и если сессии будут удалены - то и корзины всех незарегистрированных покупателей удалятся

в отличии от модуля по ссылке выше, который не зависит от срока жизни сессий

А модуль этот что использует? Некий UID в куках + БД?

Вообще странное у опенкарт решение по хранению корзины ровно час. Притом лимит жёстко прописан в коде, когда по хорошему его надо выносить как минимум в конфигурацию. И второе, он никак не коррелирует с ограничением gc_maxlifetime, что тоже в минус разработчикам. Если уж они связывают корзину с сессией, то пусть тогда и лимиты привяжут друг к другу, чтобы не править в двух местах. Хотя требовать от бесплатного движка лучшего качества, наверное, не очень этично

22 часа назад, chukcha сказал:

Для тех кто в танке
разницы между
if
if
if

и
if eleseif
с точки зрения кода - НЕТ
То что вы глазами видите короткий путь, это не значит, что так и работает
 

Это вы не понимаете. И не поймёте, пока специального образования не получите, видимо. Разница есть. Гуглите как работает интерпретатор PHP.

16 часов назад, Otvet сказал:

https://github.com/opencart/opencart/blob/master/upload/catalog/controller/startup/seo_url.php

В продакш версии (и даже в более поздней rc-версии) это всё ещё есть: https://github.com/opencart/opencart/blob/3.0.2.1_rc/upload/catalog/controller/startup/seo_url.php

А так молодцы, поправили. Не всё так плохо у текущих контрибьюторов. В отличие от местных комментаторов, которые не понимают разницы между *if* и *else if*.
Жаль только, что стабильные релизы медленно выпускаются. Версии 3.0.2.0 уже 1,5 года как, судя по оф. сайту. 

1 час назад, chukcha сказал:

@Scyth Для тех кто в танке..
Это нормальная простота кода - все на ладони, что, где и когда

А не навороченные роутеры из других движков

 

Для тех кто плохо знаком с базовыми алгоритмами и основами ЯП:  одна и та же переменная проверяется на соответствие либо через switch ... case, либо на крайний случай, через if ... else. То что выше - бессмыслица, порождённая незнанием как что работает. Когда первое же условие  = true, нет смысла проверять ту же самую переменную на соответствие другим значениям. Ибо они все будут false.

Называть такое "простотой кода" язык не поворачивается, т.к. это усложнение кода для обработчика. Да и чтение кода замедляет. Потому что надо каждый блок глазами пробежать, что автор имел ввиду. Точно ли там простое сравнение той же самой переменной или есть доп. условия? В случае со switch ... case код понятнее и читается быстрее.

Так что это называется "грязный код", но никак не простой. И если вы не понимаете таких примитивных вещей, то не вижу смысла вообще дальше с вами вести дискуссию.
 

В 25.12.2018 в 12:52, chukcha сказал:

Вы в курсе что сеопро - сначала кеширует, а затем использует
Вы же на каждый запрос тянет кеш а потом сохраняете

Да, в курсе. У SeoPro одна операция с кэшем (вытянуть) на каждый запрос, у меня две (вытянуть и в конце сохранить).

В 25.12.2018 в 12:55, lexxkrt сказал:

 

перечитал все вышесказанное, кроме воплей как все хреново не увидел ни одного примера говнокода.

 

Я же предлагал выше заглянуть в класс ControllerStartupSeoUrl. Или вы хотите чтобы я цитатами кода тут топик заспамил? ОК. Как вам такой пример творения индийского школьника? Всё из того же класса, далеко ходить не надо.
 

					if ($url[0] == 'product_id') {
						$this->request->get['product_id'] = $url[1];
					}

					if ($url[0] == 'category_id') {
						if (!isset($this->request->get['path'])) {
							$this->request->get['path'] = $url[1];
						} else {
							$this->request->get['path'] .= '_' . $url[1];
						}
					}

					if ($url[0] == 'manufacturer_id') {
						$this->request->get['manufacturer_id'] = $url[1];
					}

					if ($url[0] == 'information_id') {
						$this->request->get['information_id'] = $url[1];
					}

13 часов назад, Otvet сказал:

допустим на странице 30 ссылок

всего записей ЧПУ 70тыс

что быстрее:  30 запросов по 1мс или обращение к ФС, чтение с диска пары/десятка мегабайт и потом распарсить json всё это ?

Я писал выше, что можно было бы сделать кэширование поумнее и с многоуровневой вложенностью (чтобы не тянуть полный кэш, а только необходимые данные из него и вообще обойтись без JSON-кодирования), но опенкартовская реализация кэша ограничивает входящие данные строковым типом. 

Для интереса, глянул seoPro, который тут выше Чукча расхваливал, так вот он использует подобный же принцип кеширования. Вытягивает ВСЕ записи ЧПУ и помещает их в кэш. И уже с кэшем работает. Так что можете проверить производительность метода на своих 70 тысяч товаров с включенным seoPro и без него.

Но навскидку могу сказать, что кэш из 2 мегабайт (если предположить что ключ и значение каждой ссылки занимает в среднем 32 байта) отработает быстрее, чем 30 запросов к БД. Для справки, БД тоже тянет данные и свой кэш с ФС. Но в первом случае идёт одно обращение к ФС, во втором - 30.
Если же подключен memcache, то СУБД вообще сосёт палец в сторонке, т.к. обращения к ФС вообще не произойдёт в первом случае.

Блин, зачем я всё это рассказываю. Люди, погуглите про кэширование, что это, как оно применяется и зачем оно нужно. Такие примитивные вопросы задаёте, ей богу.

2 часа назад, chukcha сказал:

Чем кешированные данные отличаются от реальных запросов?

Минимум 200-кратное увеличение производительности данного метода ни о чём, конечно не говорит, да?

И в сравнении "очень много не нужных сущностей" против "очень много ненужных запросов", я выбираю первое. Хотя можно и поумнее сделать кэширование, согласен. Но смысла не вижу тратить на это время, если все всё равно "хавают" этот корявое коробочное решение, то для них 200-кратное увеличение производительности против 1000-кратного роли никакой не сыграет.

Кроме того, кэш ограничен хранением строк (даже если подключить какой-нибудь memcache или APC, ограничения OpenCart не позволят использовать его в полную силу). Это ещё одна причина не тратить своё время на экстра-оптимизацию.

В общем доработал коробочное решение.
Базируется полностью на стандартной функциональности SEO URL.

Что добавлено:
 

1. Кэширование ссылок ЧПУ.
   Теперь каждый раз при отрисовке новой ссылки с ЧПУ, система не делает запрос в базу (иногда она делала и по несколько запросов на одну ссылку). Сто ссылок на страницу могло обернутся более сотней запросов в БД. Кому оно надо?
   Кэш ЧПУ очищается при добавлении/редактировании/удалении ссылки через стандартный интерфейс в админке.
   По тестам на реальных данных кэширование ускоряет отдачу ссылок на 2-3 порядка (минимум в 200 раз быстрее) .
2. Гибкость в создании ЧПУ.
   Отныне любой маршрут без дополнительных параметров можно преобразовать в ЧПУ. А не только закостыленные раньше 4 варианта. Старый алгоритм, кстати, также работает, патч расширяет его, а не заменяет.
   ЧПУ для домашней страницы также работает! Достаточно добавить запись следующего вида:
   

Патч прикрепляю (применять через git apply):
SEO_URL+.patch

SEO URL+ работает для Opencart 3.0.2.0. Для других версий не тестировалось.

UPD: Действительно, нашёл где используется _route_. В методе ControllerStartupSeoUrl->index() обрабатываются адреса с этим параметром. И если в SEO URL создать запись, как показал lexxkrt, то страница site.local/contact действительно откроет контакты.

НО! Это не работает для генерации ссылок! Т.е. ссылка ЧПУ как бы есть, но она нигде не выводится (если только вы не вобьёте её вручную).

В методе ControllerStartupSeoUrl->rewrite() закостылен ограниченный набор маршрутов, которые я описал в предыдущем сообщении. И ссылки по ключам, указанным в админке, в разделе SEO URL вы нигде не увидите. Хотя они и будут работать, но не будут генерироваться в коде.

Кто же всё ещё сомневается в "говнокодости" системы opencart, добро пожаловать в этот самый класс ControllerStartupSeoUrl. Там полный набор bad practice, начиная от индусского перебора одной и той же переменной через if()... if()... if()... if()... и заканчивая ограничительными костылями or ... or ... or ... для конкретных маршрутов.

9 часов назад, chukcha сказал:

Если вы не разобрались как работает seo_url, то не надо гнать пургу на движок.

Буду рад если просветите. Пожалуйста, с сылками на код оригинальной коробочной сборки.

P.S. Но идеи говнокода это не отменяет. Худшей и более затратной по ресурсам реализации ЧПУ я ещё ни в одном фреймворке не видел.

Третий день копаюсь в Opencart 3.0.2.0. Случай свёл меня с ним как с "наиболее популярным интернет-магазином". Уж лучше бы выбрал платный, ей богу. Такого говнокода под капотом я не видел со времён чтения "творений" индусских разработчиков.
 

В 28.09.2018 в 11:34, lexxkrt сказал:

все работает в 3020, открывается по opencart/contact

lexxkrt, не обманывайте  пользователей. Из коробки это не работает. По крайней мере без каких-то дополнительных правок/модулей. Могу привести вам кусок кода, где обрабатываются ЧПУ перед выводом. И там закостылена обработка ссылок только на: 1. продукты, 2. производителей, 3. категории и страницы с информацией (только information/information!). Остальное игнорится и выводится без ЧПУ.

Так что каких-то красивых и правильных решений здесь предлагать не буду. Ударим костылями по говнокоду.

В 22.12.2018 в 22:52, vitalino000 сказал:

Добавляли, к сожалению, не работает. Проблема всё ещё актуальна (используется OC 3.0.2.0)

Вам поможет следующее: 

web\catalog\controller\startup\seo_url.php, строку 124 

			return $link;

заменяете на 
 

return str_replace(['index.php?route=','common/home'], [], $link);

Также удостоверьтесь что в файле .htaccess у вас есть строчка 
 

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

Именно "route=", а не "_route_=", как в оригинальном коробочном .htaccess!