MaxD

Сборник каких-то странных утверждений )

4 минуты назад, Yoda сказал:

• Лайтнинг - самоддосит сайт.

Прям выше об этом писалось, еще раз повторим:

Вообще DoS характеризуется тем, что посылаются новые запросы, не дожидаясь ответа на старые. Lightning делает прегенерацию в один поток, на каждом запросе дожидаясь, когда он выполнится - и только потом делается следующий.

Если магазину становится плохо от сканирования его в один поток - то и без прегенерации Lightning ему жопа - гугл, яндекс и бинг разтерзают его на части. Это если еще не говорить про ahrefs и прочих минорных чесалок.

Но, опять же, если прегенерация не нравится, есть галочка для ее отключения.

6 минут назад, Yoda сказал:

• Лайтнинг сливает пользовательские данные себе на сервер, через собственный скрипт.

Никаких данных никуда не сливается. Что за чушь?

7 минут назад, Yoda сказал:

• Авто лайтнинга врет как дышит, когда говорит про 20 000 на сервере за 5 долларов, потому как тупо одних ботов  с нормальным краулинг бюджетом такая помойка никогда не сможет вытащить.

Вот скрин этого инстанса на DigitalOcean:

На нем еще несколько вещей крутятся, кроме демо-сайта.

16 минут назад, Yoda сказал:

• По факту лайтинг ничем не отличается от  https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=19079

Каждая строчка в перечислении функций Lightning о том, чем он отличается https://lightning.devs.mx/ru/полный-список-функций-lightning

18 минут назад, Yoda сказал:

• Авто лайтнинга пропадает на месяцы не выходит на связь и клал на клиентов.

Да, было такое, был непростой период в жизни. И прошел. От такого никто не застрахован.

20 минут назад, Yoda сказал:

У лайтнинга нет внятной схемы деинсталляции.

Куда уж внятней? https://lightning.devs.mx/ru/как-удалить-lightning

22 минуты назад, Yoda сказал:

• Автор лайтнинга неявно лезет в robots.txt, где ему ну совсем делать нечего.

Действительно, в robots.txt вносились коррективы и на то были причины. Текущая версия Lightning не трогает robots.txt

2 минуты назад, Shureg сказал:

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

Тут вы правы, я неудачно сформулировал то предложение. Подредактировал. Естественно, баллы скорости не являются ни единственным, ни основным фактором. Намного важнее ценность контента и "авторитет" сайта.

В Lightning нет искуственного задирания показателей PageSpeed, все плюсы зарабатываются честно и работают для реальных посетителей - кроме этой одной опции

34 минуты назад, Shureg сказал:

Гугл вам сам так официально сказал? А вот остальным он говорит, что в первую очередь по ПФ ранжирует... Врёт, наверное.

Я ничего не говорил о том, по чем в первую очередь, и по чем во вторую.

А насчет PageSpeed и Core Web Vitals, было во всех новостях. Если доверяете только Google и читаете по английски - https://developers.google.com/search/blog/2020/11/timing-for-page-experience

В 07.08.2020 в 10:12, spectre сказал:

Лайтинг это вообще какая то эпическая хрень, магазин типа начинает работать быстро на главной и со второго раза

Lightning реально ускоряет магазины, и именно поэтому его покупают - а не изза маркетинга, пускания пыли в глаза или еще чего-то. Причем люди сначала его ставят, смотрят - хорошо ли работает, нет ли конфликтов, чувствуется ли эффект - и если да - то берут. Штуки, которые ускоряют создание страниц:

• кеширование медленных запросов к БД - с отслеживанием измененных таблиц, и кеши не протухают каждый раз, когда увеличивается счетчик просмотренных товаров
• устранение дублирующих запросов (иногда уменьшает количество запросов к базе в 2-3 раза)
• ускореная обработка ивентов и оптимизированый движок TWIG
• предзагрузка часто используемых данных (типа seo-urls для меню) одним блоком
• много специальных оптимизаций для Journal3 (там было, где разгуляться)

Его кеширование страниц имеет много фич, которые хейтеры выпускают из виду:

• страницы хранятся уже сжатые максимальной степенью GZIPа и выдаются без запуска кода Opencart, что позволяет невероятно быстро их отдавать практически без использования ресурсов сервера
• Lightning умеет примонтировать к странице из кеша корзину, залогиненого пользователя, список избранного и сравнений - и ничего не превращается в "тыкву", если добавить товар в корзину
• кроме того, если в магазине несколько валют - Lightning хранит кеш страниц только для одной валюты и переводит валюту на закешированой странице при надобности

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

Особенно меня удивляют ваши рассказы о том, как вы спасаете людей от Lightning. Чтобы узнать, виноват ли Lightning в какой-то проблеме - надо нажать одну кнопку:

Если проблема пропала - значит она связана с Lightning. Если нет - то дело в чем-то другом.

Как удалить Lightning за 3 шага - написано на самом видном месте. Почему, по вашим рассказам, люди вам платят за это деньги - непонятно. 

В 07.08.2020 в 10:12, spectre сказал:

но если у вас много товаров – это селф ддос со всеми вытекающими

Хоть бы терминологию смотрели, которую используете:

Вообще DoS характеризуется тем, что посылаются новые запросы, не дожидаясь ответа на старые. Lightning делает прегенерацию в один поток, на каждом запросе дожидаясь, когда он выполнится - и только потом делается следующий.

Если магазину становится плохо от сканирования его в один поток - то и без прегенерации Lightning ему жопа - гугл, яндекс и бинг разтерзают его на части. Это если еще не говорить про ahrefs и прочих минорных чесалок.

Но, опять же, если прегенерация не нравится, есть галочка:

В 07.08.2020 в 10:12, spectre сказал:

скрипт с сервера автора – в подарок

В последней версии Lightning скрипт предупреждения о куки подключается так:

Надеюсь, на этом ваши придирки по поводу скрипта с сервера закончатся.

В 07.08.2020 в 10:12, spectre сказал:

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

Прям на самом видном месте в настройках:

Ну а теперь по сути поста... В ранжировании мобильной выдачи Гугла официально учитываются показатели, которые очень близко соотвествуют Google PageSpeed - так называемые Core Web Vitals. А сами эти показатели очень близко соответсвуют удобству сайта для посетителей - насколько быстро прорисовалась самая большая картинка, и как мало все при этом прыгало и лагало.

А тыкать пальцем в Розетку, у которой PageRank 7, я бы не спешил. С такими рейтингами они могут есть младенцев на завтрак - и все равно оставаться на первой странице выдачи. И тем ни менее показывают платные обьявления практически на любой подходящий запрос.

Версия PHP у вас занизкая для этого файла, скорее всего хочет какой-то PHP 7.3 или 7.4.

А за пост спасибо, полезное и классно расписано!

3 часа назад, sitecreator сказал:

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

Не устаю повторять, что в OpenCart скорость кешей практически никогда не является узким местом. Просто потому, что другие 2 узких места (скорость выполнения запросов MySQL и кода PHP) не дают магазину развить достаточную пропускную способность, чтобы скорость работы кеша стала заметной.

Что касается конкретно кеша страниц, нет большой разницы - страница отдалась за 0.01 сек или за 0.0001 сек. Все это феноменально быстро по сравнению с генерацией страницы даже при всех мыслимых оптимизациях и самых крутых серверах.

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

debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 3)

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

1. как я могу быть уверен что если $code не пустой, что другой модуль до меня загрузил именно нужный мне файл?

Никак, но должна быть своеобразная этика этого дела. Ситуация ничем не отличается от OCModа или других обработчиков событий - и там и там можно заменить все и наломать всем остальным модулям, которые вмешиваются в это место.

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

2. каждому модулю вручную загружать код шаблона из файлов не имея вообще никакого апи и инструментов для этого?

Согласен, это достаточно странно, но в принципе ничего сложного:

if (!$code) $code = file_get_contents(DIR_TEMPLATE . $this->registry->get('config')->get('template_directory') . $route . '.twig');

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

А после загрузки что? каждому модулю так же вручную изменять его с помощью чего? str_replace и preg_replace?...

В базовом варианте да. А так - можно использовать достаточно сложную логику, недостижимую в OCMod/vQmod, что однозначно плюс.

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

Да и чем этот вариант принципиально отличается от варианта с модификаторами? 

Для шаблонов - принципиально ничем не отличается, кроме усложненной отладки. Но хоть какой-то вариант лучше, чем никакого.

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

без кеша и возможности отладки.. 

С кешем, кстати, все нормально - при первом обращении к конкретному .twig результат записывается в PHP-файл кеша, как обычно. Правда, я не разбирался, зависит ли имя файла от содержимого $code, или только от названия шаблона. Но, похоже, что не зависит.

Меня в этой всей истории смущает другое. Мне кажется, что отличительной особенностью Opencart по сравнению с Wordpress/Prestashop/Magento было то, что можно было просто читать и менять код движка, быстро добиваясь нужного результата. Низкий порог входа, прямолинейное изменение и все такое. А с переходом на события становится "как у всех", когда для даже небольшой модификации надо сильно много думать и курить кучу доков.

2 минуты назад, sv2109 сказал:

То есть изменить оригинальный код шаблона все равно никак нельзя. 
 

Ну это тривиально. В обработчике события, если передали пустой $code - в него надо самостоятельно загрузить оригинальный файл шаблона. А если не пустой - то работать, с тем что передали.

9 минут назад, sv2109 сказал:

НО никак нельзя изменить сам шаблон. 

Так вот я как-раз говорю, что в 3.0.3.5 добавили возможность изменять шаблон:

// Template contents. Not the output!
$code = '';
		
// Trigger the pre events
$result = $this->registry->get('event')->trigger('view/' . $trigger . '/before', array(&$route, &$data, &$code));

...

$output = $template->render($this->registry->get('config')->get('template_directory') . $route, $code);

Если $code не пустой, то он используется вместо фактического текста шаблона. Получается, что можно модифицировать шаблон в обработчике события, и несколько дополнений, которые вносят изменения в один и тот же .twig, могут вполне себе уживаться.

По поводу "как мы будем жить без OcMod"... Только на днях заметил, что начиная с 3.0.3.5 есть событие до загрузки файла шаблона, которое позволяет его изменить или поставить свой. Видимо это и ответ, причем не самый плохой.

Основная идея 8-ки - JIT, компиляция кода. Именно для нее и нужна повсеместная жесткая типизация.

Я раньше тестировал с компиляцией и без OpenCart 3, разницы не заметил. Никто не хочет потестировать, как в этом плане жестко типизированная 4-ка?