Yoda

Так таки умрет? О чем дальше разговаривать?

Конечно, хочу как ваша компания тоже стать альтертнативно одаренным.

Следовательно, когда браузер закрывается, сессионные cookie сразу же удаляются. Это же ваши слова! Я о чем говорю? Именно об этом! Переобулся в прыжке.

Модераторы, или кто тут посты трет. Угомонитесь! Тут достаточно важный вопрос про время жизни кук... Еще раз повторяю пост! Куки в бразуере живут после закрытия бразера, если корректно настроен параметр. session.cookie_lifetime integer session.cookie_lifetime указывает время жизни cookies, отправляемого в браузер клиента, в секундах. Значение 0 означает, что cookies будут валидны до закрытия браузера. По умолчанию равно 0. См. также session_get_cookie_params() и session_set_cookie_params(). Вот официальная документация: https://www.php.net/manual/ru/session.configuration.php#ini.session.cookie-lifetime Вместо того чтобы тереть все под корень, разберитесь в проблематике, и немного альтернативно-одаренных на место ставьте, которые рассказывают бред.

Что вы говорите, а сколько там от magento осталось, сколько это стоило, и сколько стоит кластер на котором это вертится, озвучьте сразу.

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

Еще как относится. Так как кука твой умрет, если бразуер закрыть и открыть.

а session.cookie_lifetime у тебя скока ?

https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=18266 Есть более интересные варианты. Но это лишняя информация.

ООП - не не слышал. Это совет почти как. Если вам нужны данные из базы. Вставьте код в tpl.

Да вы правильно поняли, я надергал образцов кода из разных мест для примера вам. Решение описано выше. И это наиболее качественный способ "человеческой" сортировки. Средствами mysql подобное реализовать невозможно, так как strcmp - вот просто шикарно работает. Также если не будете ленится и сходите по приведенным ссылкам в конце - там есть очень подробное описание на php.net с кучей примеров и подробным разбором работы методов.

Да сможете, но вам предварительно необходимо поместить ващ объект $db2 в $registry, для того чтобы к нему был доступ из дочерних классов движка.

При всем уважении - это не очень хорошее решение. Более корректным будет забрать код из 1.5.6 и в конфиге поменять тип подключения на mysqli. https://github.com/opencart/opencart/blob/1.5.6.4/upload/system/library/db.php https://github.com/opencart/opencart/blob/1.5.6.4/upload/system/database/mysqli.php Конкретно в вашем случае появится еще проблема с библиотеками mcrypt - но это так же решается путем апгрейда отдельных классов движка. Тот же encryption класс можно взять отсюда и спокойно пользоваться. https://github.com/opencart/opencart/blob/3.0.1.0/upload/system/library/encryption.php С обновлением версии php с 5.x на 7.x даже с 1.5 движком проблем нет - если возникнут - пишите в личку подскажу что сделать. А вот с работой сторонних модулей могут быть самого разного рода проблемы.

<?php $dirs = array( array('name' => 'First Folder', 'path' => 'sompath'), array('name' => 'second folder', 'path' => 'sompath2'), array('name' => 'Third Folder', 'path' => 'sompath3') ); function so($a, $b) { return (strcmp (strtolower($a['name']), strtolower($b['name']))); } uasort($arr, 'so'); var_dump ($arr); ?> https://www.php.net/manual/ru/function.uasort.php https://www.php.net/manual/ru/function.strcmp.php

Тут ты не совсем прав. Очень часто, в моей практике, недоступной к сожалению большинству, встречается аномальный паттерн посещаемости. Когда у тебя на десять страниц магазина идет 90% трафика из контекстной рекламы. И поток этого трафика может быть ну оч большой. В таких ситуациях глобально кешировать весь контент страницы - мастхев (но понимая, что и без этого кеша быстро). Но в случае когда "спицилист аптемезатор" показывает вот вам главная html готовый за 50 мс прителета. А еще 10 000 страниц как были так и есть по 2-3 секунды, тут без слов!

Никак!

Класс... Я пишу - вот вам ребята... бесплатные решения. Пользуйтесь. Вот тут вас немножко вводят в заблуждение... Привожу факты и это манипуляция общественным мнением? Оруэл курит! Великолепно... То есть по вашему, теперь нельзя взять и посоветовать людям тыц и тыц.. Берите вот это и вот это. Тыц и тыц... есть альтернативное мнение... Еще раз повторю суть моих постов. Вы можете сколько угодно любить авторов которых вы советуете. Я их не люблю. И я считаю, что использовать альтернативные бесплатные решения С ОТКРЫТЫМ КОДОМ !!!! для реализации тех же самых задач, разумнее, чем пользоваться дополнениями, которые лично у меня вызывают определенные сомнения. Это мое мнение - и я не претендую в отличии от вас на истину в последней инстанции. И не показываю рисованные циферки.

Вы узко и ограничено мыслите и пытаетесь натянуть сову на глобус. Не надо никуда бегать - надо пользоваться доступными и открытыми инструментами по возможности. Вы же занимаетесь дешевым пиаром. Как и ваши друзья, не предлагая альтернативы. Сжатие картинок - это просто как дважды два. В 99% случаев поддержка не нужна и реализуется бесплатными методами с открытым кодом. Что касается того что вы показали категорию на 1300 товаров. Вот дополнение которое реализует ту же задачу что и ночной код вашего товарища, только без исполняемых кеш файлов. https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=19079 Но эти дополнения никак не решают вопросы ни нагружнных проектов, ни магазинов с большим количеством товаров. Показывать скорость отдачи сервером кешированного html - это такое же введение в заблуждение людей как и голый html или наглухо переверстанный шаблон. А так да... Рекламка такая была зачетная... И если говорить про поддержку. То за 3000 рублей сэкономленных на этих модулях, любой пользователь десять раз купит 3-4 часа работы грамотного специалиста, который минут за 20-30 решит потенциально возможные косяки. И еще 2500 останется на решение других задач.

Продолжайте....

Возможно, показывать совсем голую верстку, без 100500 ништяков которые могут быть талантливо установлены - как то не очень... И возможно не стоит верить волшебным модулям, а немного посмотреть, как же так картинка на 1мб валится? Как и лишний раз вводить людей в заблуждение про волшебные модули.

Тут вот какое дело... Просто перенести в подвал - не выйдет по нескольким причинам. Во первых гуглу это не подойдет, так как он будет все равно ждать первую загрузку контента (это нововведения такие). Во вторых можно порушить работоспособность модулей. И в третьих так или иначе надо перерабатывать всякого рода скрипты, которые добавляются не через $this->document->addScritp('somescript.js'). Та же самая история и со стилями. По нынешним рекомендациям гугла соответствующие стили надо загружать только под соответсвующий vieport и дробить базоый стиль на кучу составляющих. А все вспомогательные стили грузить уже после всей загрузки контента - на выходе тоже можно получить дергания. Так же гуглу не нравится, что мы грузим по очереди несколько десятков ресурсов, а то что уже давно существует HTTP2 и как он работает гугл не в курсе. И вряд ли в ближайшем времени будет в курсе. Также возможно просто обьединение всех стилей и заголовков в один большой файл. Но в таком случае можно забыть про то что бразуеры кешируют статику. Правда для разного типа контента все же будет кеширование, но не на уровне элементов вашей структуры, а на уровне свой стиль/скрипт на каждый роут товар, категорию и тд. Если сильно охота можете попробовать поиграть вот в такие теги: <link rel="alternate stylesheet" href="mystyles.css" onload="this.rel='stylesheet'"> и как то так: <script>function init() { $('a').addClass('ajax'); }</script> <script src="/jquery.js" async onload="init()"></script>

50-500 мс экономии на генерации страницы.

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

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

Спасибо зе рефренс, но тут скорее всего не мой случай, автор ищет волшебную таблетку, верит в чудесную силу лайтнинга и подорожника. Мне зачастую с такими людьми очень сложно найти общий язык, и еще сложнее объяснить что оценка pagespeed никак не связана со скоростью работы проекта и то что нет cуществует волшебных настроек сервера, которые могут дать волшебную оценку pagespeed, для таких людей тут есть целая плеяда блестящих специалистов брать по полсотне тысяч рублей за волшебный воздух.