MaxD

29.09.2023 в 13:52, sv2109 сказал:

3. Сам двіжок дуже простий в освоєнні та роботі та дуже швидкий, я бачив магазини на опенкарти де було більше мільйона товарів!

Якраз Opencart простий в освоєнні та швидкий тому, що в ньому по суті немає івентів і додаткових рівнів абстракцій, а просто код, який читаєш, розумієш і міняєш.

Порівняйте час освоєння розробки для Opencart та Prestashop/WooCommerce.

28.07.2023 в 15:19, Vladzimir сказал:

Чому саме 3.*? TWIG - взагалі якийсь анті-паттерн.

До Twigа якраз найменше питань. Синтаксис простий, останні його версії по швидкодії не так сильно відстають від TPL. Ось зараз копирсаю, додав в Opencart можливість одразу робити {{ load('common/header') }}, код контроллерів ще трохи почистився. Правда, лише в адмінській частині, інакше би одразу збилася сумісність з усіма шаблонами для вітрини.

28.07.2023 в 15:19, Vladzimir сказал:

Ось як мають робитися події, потрібно використовувати ORM/ODM

І в результаті вийде Prestashop в початковій стадії. Події та ORM сильно підіймають поріг входу та вартість розробки.

28.07.2023 в 15:54, SergeTkach сказал:

Я готовий виконати якесь одне завдання для нової збірки, якщо що. Наприклад, змінити код якогось вбудованого модуля або безкоштовного модуля.

Супер - якщо прийде час, запрошу долучитися.

28.07.2023 в 15:54, SergeTkach сказал:

Окрім зміни коду, було б чудово бачити зміни в функціональності системи з моменту ії встановлення. Верніше, наразі це може бути просто перелік.

Звичайно, є орієнтовний план і потрібно зробити немало роботи до того, як чимось заявлятись. Основна концепція - щоб усе нагально-потрібне було з коробки, і було настільки хорошим, щоб уже в цю зону не було потрібно робити комерційних доповнень. Хоча це теж засада, бо весь час Opencart тримається на розробниках, що продають базовий функціонал, your pain is my gain, Daniel ))

Программа-мінімум:

1. Зміна структури бази під швидкодію з великою кількістю товарів/категорій/атрибутів

2. Вбудоване SEO, більшою частиною автоматичне і підкапотне

3. Хороший та швидкий модуль фільтрів

4. Імпорт/експорт

5. Оновлення Opencart по кнопці, перевірка нових версій доповнень і теж оновлення їх по кнопці

6. Блог/статті/новини

7. Хороша робоча дефолтна тема вітрини, на якій можна реально крутити магазин

27.07.2023 в 12:29, chukcha сказал:

Кому не прозорий?

Тому, хто читає код і намагається зрозуміти, що в ньому відбувається - непрозорий. Банально, дивишся на файл шаблону і намагаєшся зрозуміти, чому на сайті є кнопка, а в шаблоні нема. Або читаєш код моделі, а її видачу уже перепахало три різних доповлення внахльост, іди шукай і розбирайся. І IDE тобі тут не поможе, хіба дебаг.

27.07.2023 в 12:42, rb2 сказал:

Не зрозумів, що з сумісністю з величезним гамузом існуючих розширень.
OCMOD, vQmod? Вони наче підуть лісом, бо кодова база змінилась.

Так, ocMod/vQmod треба буде підрихтовувати. Але принаймні прості розширення в класичному opencart-стилі - доставки-оплати-модулі працюватимуть, що вже добре. У Opencart4 і цього нема, а переробляти розширення під нього ще той цимес, змінилося буквально все.

27.07.2023 в 12:50, markimax сказал:

Але той код що ти дав повне лайно тим паче в світі підтримки та т п
Навіщо прибирати registry, як основу 

Registry мало того, що є супер-збоченим способом емулювати глобальні класи, який не дає IDE зрозуміти, де що, він ще й дає пенальті на швидкість, бо кожен пук викликає магічну функцію.

Чому мій код лайно, можна більш конкретно? В світлі підтримки порівняно з Opencart3?

Спробуйте профайлером xdebug, він ніби нормально це реєструє.

Може профайлер багато часу витрачає на фіксацію викликів, тоді багато дрібних викликів будуть репортитись затратнішими, ніж без профайлера.

Але все рівно півтора тисячі перевірок наявності файлів трохи забагато, може там щось негаразд.

Начиная с 22 марта, все деньги, вырученные с продажи лицензий Lightning будут передаваться на поддержку ЗСУ (Збройних Сил України).

Отчеты будут публиковаться по мере перечисления средств.

Если вы из Украины и необходима бесплатная лицензия - пишите в ПМ.

Подтверждаю, видел сегодня у нескольких клиентов. Плотность запросов такая, что сайты ложатся.

Также видел станное - у одного клиента админка была запаролена через .htaccess, но apache перенаправлял эти запросы корневому index.php. Сайт лег еще быстрее, естественно.

Добавьте в начало файлов index.php и admin/index.php строчку:

if (!empty($_POST) && @$_SERVER["REQUEST_URI"] == "/admin/") exit;

Выложил обновление Lightning с защитой от брутфорса админки и этой ситуации.

А вот эта работа?

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

Вынес бекапы на внешнее удаленное хранилище, почистил логи (200 гиг было), добавил архивацию свежих логов, удалил старые базы, хламушник от обмена с 1с

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

Ну и поиск sphinx

Замечательная история, приятно почитать.

Для полноты картины не хватает главной цифры - сколько стоила вся описанная работа. 

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

Подмена тезиса! А PageSpeed из чего слеплен?

PageSpeed формируется на 30% - из ТВТ (который есть синтетическим выражением FID), на 25% - из LCP, на 15% - из CLS и еще по 10% из FCP, SI и TTI.

То есть 70% веса баллов PageSpeed формируются из показателей, которые сейчас входят в Core Web Vitals.

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

и, условно гуглоспид (обработка скриптов, оценка качества + передача данных в индексатор)

Роботы Google не оценивают синтетически показатели Core Web Vitals, а снимают эту статистику с браузеров Chrome у реальных посетителей сайта.

3 минуты назад, RGB сказал:

Я пытаюсь доказать очевидный тезис, что в контексте скорости/удобства важна именно фактическая скорость/удобство, а не то, 90 у вас попугаев или 95.

О, я думал тут спор о том, влияют ли показатели PageSpeed на позиции в выдаче Google. А то, что для скорости/удобства важнее всего скорость/удобство - странно поддавать сомнению  

8 минут назад, RGB сказал:

Я писал про циферки PageSpeed от 0 до 100, а не циферки Core Web Vitals, у последних вообще нет такого абстрактного деления в виде шкалы от нуля до ста

На данный момент не существует лучшего синтетического способа оценить Core Web Vitals, чем PageSpeed Insights. Если он появится - будут использовать его, а не PageSpeed. Да, PageSpeed показывает баллы - но они вычисляются из того, насколько у вас хороши Core Web Vitals. Если они все в зеленой зоне - балы PageSpeed будут 90+

Ну, вы и спорите )

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

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

По факту, выдача строится на том, насколько ваш контент удовлетворяет конкретный поисковый запрос пользователя. Но дополнительным фактором ранжирования при поиске с мобильного выступают Core Web Vitals (вот прямо циферки), и гугл дает небольшой бонус в позициях сайтам, у которых с этими показателями все хорошо.

Core Web Vitals (FCP, LCP, CLS и FID - время первой прорисовки контента, время прорисовки самой большой картинки на экране, суммарный сдвиг контента и задержка ввода) официально учитываются гуглом, как один из факторов в мобильной выдаче. Все эти показатели практически полностью коррелируют с баллами PageSpeed Insights.

Но люди и так уже в основном в курсе, потому что Google Search Console прямым текстом предупреждает, если какой-то из этих показателей на каких-то страницах сайта ниже нормы.

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

Покажите интернет магазин на OpenCart.

А в чем принципиальная разница? ) Ясное дело, что мало кто работает без аналитики.

Но, например, если поискать в Google по какой-то строчке, которая прописана в стандартном языковом файле Opencart и врядли будет встречаться где-то еще в точно такой формулировке, то выдаст в основном сайты на Opencart.

https://www.google.com/search?q="Please+note+that+this+is+not+connected+in+any+way+to+your+customer+account"&oq="Please+note+that+this+is+not+connected+in+any+way+to+your+customer+account"&aqs=chrome..69i57.1808j0j7&sourceid=chrome&ie=UTF-8

7ая позиция - https://bessielondon.com/trade/

10ая - https://www.sowkea.com/

5 часов назад, buslikdrev сказал:

Есть сайт пример без аналитики в ТОПе?

https://ru.wikipedia.org/

11 минут назад, buslikdrev сказал:

Поведенческий фактор - значит учитывает. И советует аналитику так подключать:

https://developers.google.com/analytics/devguides/collection/analyticsjs

 

По вашей ссылке нет ни словосочетания behavioral factors, ни намека на то, что данные Аналитики могут влиять на позицию в поиске.

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

Для вычисления поведенческих факторов Google использует взаимодействие пользователей с окном поиска и анонимные данные, которые посылает Chrome.

8 часов назад, Yoda сказал:

Вставлять в коробочное решение стучалку на свой сервер в виде пингера - это отсутствие совести!

Это о чем конкретно? Какая стучалка, какой пингер?

8 часов назад, Yoda сказал:

Нарушать работу скриптов аналитики и портить пользовательские показатели. Это за гранью.

Google не использует данные Google Analytics для ранжирования поиска:

https://seoukraine.com.ua/ispolzuyutsya-li-dannye-google-analytics-dlya-ranzhirovaniya-saytov/

У меня mysql не поднималась, приходилось вручную (

У меня было на моем сервере, что раз в месяц-два падал MySQL - тоже говорил, что по нехватке памяти.

Решил подключением своп-файла. Это из той же оперы?

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

И у нас была одна единственная проблема в одну строчку кода, которую мы искали 6 часов

Вот плюешься ты на XDebug, а он бы сразу это показал.

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

Ни один твой лайтнинг кеш, ни одно твое решение, рядом даже не может такого сделать

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

Может наконец-то перестанешь сравнивать несравниваемое, и будешь меряться эффективностью с другими мастерами с жирным ценником, а Lightning сравнивать с другими коробочными решениями, которые можно установить самостоятельно, не обладая специальными знаниями?

Так можно уже где-то почитать о сабже?

Очень ждем, не томите уже

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

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

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

Да, была такая проблема... Победили с большим трудом, в последних версиях Lightning все супер. Если у постадавшего анонима все еще есть эта проблема, пусть стукнет в личку.

Но для меня до сих пор остается загадкой, может кто-то из вас знает? Почему обычный AJAX-запрос через jQuery гугл упорно представляет как отдельную страницу в результатах? Это как-то совсем расходится с логикой. В результате так и не выяснилось, пришлось сделать через загрузку генерируемого JS-файла вместо AJAXа.

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

ТОЛЬКО ТОЛКУ ОТ ОДНОГО ПОТОКА НА 20 000 товаров - ноль. Кеш будет перегенерироваться неоправданно долго и боты будут видеть тупые страницы, равно как и пользователи, которые зашли на страницу без кеша.

Лучше иметь часть выдачи из кеша, чем всю выдачу не из кеша. Ну и 20000 страниц по секунде на страницу - это 5 с половиной часов, вполне неплохое время.

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

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

С лайтнингом тем более как вы говорите ОПА. Но люди вам верят, а вы вот только про это вскрылись, напишите пожалуйста это жирным в описании модуля - тогда будет по честному!

Я нигде не заявлял, что Lightning оживляет абсолютно нерабочие магазины. Конечно, иногда бывает, но обычно если магазин совсем не функционирует - Lightning ему врядли поможет.

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

Без перегенерации, какой толк от вашей поделки?

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

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

и на все 100 000 сайтов, куда вы подложили свой скрипт пойдет какой нить зловредный js?

Жаль, что вы не читаете темы, в которые пишете комментарии. Вот код подключения этого скрипта:

В параметре integrity указан хеш скрипта. Если он по какой-то причине изменится, браузер его не загрузит.

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

Серьезно? А есть скрин с нагрузкой хотя бы в 5000 хостов в день, логами и ботами в количестве тысяч 150 в сутки?  На таком же никчемном впсе?

С чего бы демо-сайту иметь 5000 хостов в день? Все, что было сказано - вот демо-сайт на 20000 товаров на VPS за $5 в месяц. И это абсолютная правда.

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

А про роботс есть там хоть строчка?

Согласен, про robots.txt стоило там писать, когда Lightning в него добавлял свое. Повторюсь, сейчас robots.txt не трогается, писать не о чем.

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

Кстааати. а что там с отложеными скриптами ?

А что с ними?

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

Какой вьюн, тут ответы есть, а здесь технично промолчал!

Мне кажется, я отвечаю на все вопросы. Если на какой-то не ответил - повторите, обязательно отвечу.

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

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

Есть много довольных клиентов, которые используют Lightning годами. И это тоже видно в отзывах. А насчет перлов - опять процитирую вышенаписаное:

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