sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
Какие у ocstore 2.3 уязвимости, что начали появляться эксплойты?
sitecreator replied to ladOK's topic in Вопросы безопасности
@stickpro , а у вас есть тайные знания и статистика об этом чтобы что-то утверждать? Поделитесь? Да и у топикстартера, если вы не заметили, даже модуля этого нет. Так что мы тогда обсуждаем? Расскажите каким образом можно взломать сайт через известный модуль если он даже не установлен на нем? -
я об этом уже писал многие месяцы назад. и какой результат? Только заклеймили как нытика и "всем недовольным". Там вообще чудеса с этими выборочными удалениями происходят... желания описывать нет, ибо ни у кого из ответственных нет желания это править в письмах.
-
Какие у ocstore 2.3 уязвимости, что начали появляться эксплойты?
sitecreator replied to ladOK's topic in Вопросы безопасности
Справедливости ради нужно сказать, что история не знает реальных взломов через ту самую "дыру", о которой так много говорил "непогрешимый разоблачитель". -
Какие у ocstore 2.3 уязвимости, что начали появляться эксплойты?
sitecreator replied to ladOK's topic in Вопросы безопасности
смех без причины? или что конкретно вас рассмешило? -
Какие у ocstore 2.3 уязвимости, что начали появляться эксплойты?
sitecreator replied to ladOK's topic in Вопросы безопасности
через него крайне маловероятно взломать сайт. В том понимании в каком пишет топикстартер. Ну а наличие по соседству, джумлы, вордпресса и прочих cms - это вполне вероятная причина. -
это вас ввели в заблуждение. Там как небо и земля. 4-ка практически везде идет бесплатно как бонус, ибо никому она и не нужна сейчас, разработчик ее несколько лет не поддерживает. с 4-кой вы также вынуждены использовать старую ОС и прочий древний набор софта. Ну зачем вам все это надо? Вся эта древность? Зачем в 2019-м намеренно ставить софт 10-ти летней давности? Это ж мазохизм какой-то. В производительности сильно проиграете. Но никогда не поздно сделать правильный выбор. Ставьте лучше свежую ОС Centos 7.*. Накатывайте сверху ISPmanager 5 lite. И пользуйтесь две недели (это в любом случае) или месяц бесплатно (от хостера зависит). А далее по 200 р. в месяц. Или берите сразу VDS с ISPmanager 5 , которая входит в комплект. В итоге будет дешевле чем 200/месяц. Есть также вариант купить вечную лицензию. С ISPmanager 5-кой жизнь покажется намного веселее. А высвободившееся время лучше потратить на что-то полезное другое.
-
Все там есть. И даже больше. Просто изучайте. У вас же свежая ОС и ISPmanager 5 Lite? Или древний 4-й версии? С 4-кой толку не будет. Там, действительно, все руками надо.
-
смотрите, если вы переустановили OC, то что вам мешает ее переустановить с ISPmanager и получить колоссальное удобство? 200 руб/месяц - довольно смешная цена за удобство в бизнесе. В любом случае, конечно, выбирать вам. Да и модулей побольше надо бы. зачем вам mysql? вам mysqli нужен. Для апачи поставьте модуль php. Ну или работайте в нужном вам режиме. Но с ISPmanager в тысячу раз проще все сделаете. Но если хочется покопаться и разобраться, то другое дело.
-
@Roumek , как видите сами, у вас уже установлен нужный вам репо. Находите сходство с моим скриншотом? На нем тоже есть репо remi. Поэтому устанавливайте далее уже php. если выбрали этот путь. По инструкции, коих миллион в сети. еще совет по скриншотам. когда открываете ссылку на скриншот, то правой кнопкой выбирайте "копировать адрес ссылки". а сюда вставляете эту ссылку, и она превращается сразу в изображение. Это всем удобно. и никакой лишней рекламы.
-
@Roumek покажите ваши репозитории: yum repolist Сдается мне, что у вас уже репо подключен, а вы его еще раз пытаетесь подключить. Собственно такие как у вас ошибки бывают именно в этом случае. Вам гуру это не подсказал? Может быть он хочет нажиться на вашем неведении? Вам же так и пишут "нечего делать", намекая, что и так уже сделано. Это привычное для Linux сообщение. Надо его правильно интерпретировать. Означает обычно не "не могу сделать", а "не делаю потому, что это уже сделано ранее". Но от контекста тоже зависит. var/tmp/yum-root-espof3/remi-release-6.rpm: does not update installed package. Error: Nothing to do У вас же написано, что невозможно сделать апдейт уже установленного пакета. Т.е. он у вас уже есть. Пробуйте пользоваться переводом с английского. бывает полезно. Если рассуждать логически, то он у вас скорее всего актуальной версии для вашей ОС, а потому update и невозможен. Ну и, возможно, что мое предложение будет вам интересно. Ведь с linux вы на "Вы", похоже.
-
@Roumek , вам совет чтобы не мучиться со скриншотами и не делать их камерой (смаотфоном). Поставьте бесплатный скриншотер. очень удобная вещь. Например, http://joxi.ru/ или подобный. В браузере FireFox есть встроенный, даже ставить не надо.
-
Возможно, что вам будет интересно. Предлагаю вам изменить кардинально подход к вашему серверу (VDS) в плане увеличения производительности и, главное, удобства и прозрачности управления для вас. Могу установить все. И зачем вам такая древность как 6.8? Сколько ей лет? лет 8 или больше? И ядро 2.6 от 2003 года рождения..... Больше трех лет уже не поддерживается - никаких обновлений безопасности и надежности не выпускается. Предлагаю установить самую последнюю centos 7.* Целиком и в комплексе. С грамотной настройкой. Установить самый актуальный сервер БД Mariadb 10.3 (MySQL 8 как вариант) с настройкой и переносом ваших БД. У вас какой сейчас? В лучшем случае 5.5. А возможно, что MySQL 5.1 из дефолтной поставки. и т.д. и т.п. все самое современное и производительное. Нормальную связку поставлю nginx + апачи в самой производительной конфигурации. Или чистый (для макс. быстродействия) nginx (+ php-fpm) при желании. с переносом вашего сайта. и панель управления стоит поставить нормальную чтобы вы не мучились, раз уж у вас поддержка ничего не делает. тоже сделаю. будете в два клика ставить любую версию php. И управлять другим софтом. все это 5000 р. А если захотите ускорить поиск, то поставлю сервер Сфинкс актуальной 3.* версии. Поиск летать будет. Но это отдельно. Сервер Мемкешт при желании и пр.
-
я люблю оперировать цифрами и фактами. зато есть балаболы, которые только словами и какашками любят кидаться, а подтвердить свои слова не могут. для дотошных читаем документацию: https://www.modpagespeed.com/doc/filter-image-optimize Если обратите внимание, то речь о рекомпрессии как jpeg, так и webp. Т.е. это лишний раз доказывает, что никакого сжатия (по типу mozjpeg) в этом термине искать не нужно. Если исходить от обратного, то в таком случае для WEBP пейджспид тоже умеет применять сжатие. В данном контексте термин "recompress_jpeg" уместнее понимать как пересохранить jpeg (с другим качеством), но не "пересжать" в том понимании как вам хотелось бы. Тоже самое и к webp относится. В пейджспид есть (теоретически) способ уменьшения объема за счет уменьшения оттенков цветов (если упрощенно), но это не сжатие, да и результат может вам не понравиться. Эта опция не используется на общих хостингах ввиду не всегда предсказуемого результата. Еще пейджспид умеет выкидывать метаданные, за счет этого тоже можно уменьшать вес. Т.е. делает то, что jpegoptim. Но и модуль Компрессор это делает. А никаких реальных встроенных алгоритмов сжатия в пейджспид я не встречал. Я изучал исходный код в том числе. Для png был обнаружен мною optipng в составе пейджспид. Для JPEG ничего нет в нем. Но я изучал еще старую версию. Если в новую что-то встроили, то хотелось бы узнать что именно. По сути алгоритмов сжатия JPEG немного. один от Mozilla - это mozjpeg, другой от Гугла - это Google Guetzli Все. ничего больше нет для JPEG . Но Guetzli Гугл может позволить использовать лишь на собственных серверах ввиду нереально долгой его работы. Возможно, что я отстал по части алгоритмов и что-то упустил? Возможно кто-то знает больше меня? Вполне возможно. Учиться никогда не поздно. Это я про себя. Но я все же считаю, что держу руку на пульсе в этой области, и вряд ли лучше меня кто-то умеет работать с изображениями на этом форуме.
-
ну это как настроить. Если правильно, то будет, конечно. смотрите результат на примере таймвеба. совместно работали. еще раз (качество mozjpeg q=85): Здесь на примере видно, что пейджспид подхватывал наилучший результат (от mozjpeg) и не смог его улучшить, а потому и положил его в свой кеш пейджспида как свой. Только не имеет смысла включать в вашем случае в пейджспид оптимизацию изображений. Для jpeg, по крайней мере. Только пустая трата ресурсов (процессора, памяти). С webp если хотите, то можете поиграться. Если понимаете что и как настраивать и вам хочется разбираться и экспериментировать с настройками. Еще учтите один неприятный момент. Пейджспид создает свой собственный кеш изображений на диске. А потому не удивляйтесь что занятой место на диске увеличится в два раза и больше. Т.е. у вас будет кеш в движке магазина, да еще дублирующий кеш от пейджспида. Вам, конечно, про неприятные моменты никто не расскажет. Как и про то, что от экспериментальных возможностей пейджспида бывают глюки. Стоит помнить об этом. Иногда вреда получается больше чем пользы. Видите сколько красных восклицательных знаков? Только тот, кто толком не работал с пейджспид может рекомендовать его как панацею от всего. А тут нужно с умом и пониманием и без эмоций. Я еще два года тому назад тщательно рассматривал и изучал это решение как под апачи, так и под nginx. Именно в плане оптимизации изображений не в последнюю очередь. Из-за глюков оно меня не устроило совсем. Про отсутствие сжатия JPEG уже говорил. Я бы работу с JS, CSS делал бы реками с пониманием. Иначе возможны неожиданные сюрпризы. Делать это на автомате - не вполне правильно. Но у вас есть выбор.
-
Вот ссылка на изображение, созданное оптимизацией pagespeed. И ниже изображение созданное mozjpeg (q=80). pagespeed весит 44К mozjpeg весит 25К (в предыдущем сообщении файл 28 К получился при качестве mozjpeg q=85) Если мод пейджспид покажет результат близкий к 25К-28К, то будет замечательно. Мы на таймвебе под пейджспид не смогли этого добиться. (Заказчик не даст соврать) Возможно, что у вас получится.
-
эксперимент на таймвебе с включенным "ускорить сайт" и "оптимизировать изображения". вот размер за счет сжатия mozjpeg пока модуль Компрессор был включен. далее отключаю модуль Компрессор. очищаю кеш изображений сайта. и даю возможность мод пейджспид самостоятельно все оптимизировать. разумеется, что кеш пейджспида тоже очищается для чистоты эксперимента. получаем через некоторое время итог: Итого вместо замечательного размера в 28 К, полученного за счет сжатия mozjpeg, вы получаете оптимизированный файл размером уже в 44 К. Заказчик не даст соврать, что именно это и наблюдаем. Эксперимент довольно простой. 1) Работает только модуль Компрессор. Результат: 28К 2) работает модуль Компрессор + мод пейджспид. Результат: 28К 3) работает только мод пейджспид. Результат: 44К Если вы умеете делать иначе, то поделитесь. Никакой тонкой настройки оптимизации изображений у таймвеба не предусмотрено. Это если кто-то подумает, что что-то не настроили. Но вы можете попробовать сжать JPEG на VDS. Из положительного, что заметил в пейджспиде: он перестал менять файл меньшего размера на бОльший при своей рекомпрессии. Если у него не полчается сделать файл меньшего размера, то он берет просто оригинал. Раньше он тупа заменял все на свои "оптимизированные" изображения даже когда они были по весу больше оригинала.
-
Еще важный момент. Тот же таймвеб создает WEBP, что вроде бы и неплохо уже. Но он их не выводит! Именно так это реализовано на таймвебе. И не важно, что сам пейджспид предусматривает вывод. Нужно смотреть не на заявление, а на реальную реализацию. Кроме того у пользователя нет никакого контроля за таким важным параметром изображения как качество. По умолчанию оно идет в пейджспид, например, для webp равным 80. А этого достаточно далеко не всем пользователям. Тоже само и для JPEG. Я же предлагаю полный контроль над качеством. Помимо качества предлагаю и другие настройки WEBP, которые позволяют добиться наилучших результатов, т.к. качество - это не единственный параметр. Например, "m"-параметр от которого в итоге зависит тоже конечный вес файла. В следующей версии модуля Компрессор вывод WEBP уже встроен. Для любого хостера. И что же реально в итоге дает мод пейджспид от таймвеб в плане оптимизации изображений? JPEG он не сжимает. WEBP создает, но не выводит в браузере. В итоге mod padgespeed у вас есть, а сжатых JPEG нет, и WEBP в браузер не отдаются. mod padgespeed: Браузер в итоге не получает ни сжатого JPEG, ни WEBP, т.е. отдается все в несжатом виде. Вот как отдаются изображения (показываю, что webp не загружается): Не смотря на то, что само изображение webp существует. Да, и почему же чуда не произошло и попугаев так мало после mod pagespeed? Ведь почти все галочки включили. И про изображения не забыли галочку. А гугл ругается на изображения. Говорит про современный формат что-то. Вот же ж все оптимизировали:
-
как раз таймвеб четко все поясняет насчет JPEG. сжатия JPEG нет. Есть оптимизация за счет прогрессивного формата. Скорее всего, что в этом и есть вся соль "Recompress JPEG" от гугла. Т.е. работает jpegoptim. Для браузера Сафари довольно актуален именно сжатый JPEG, т.к. он не понимает WEBP. А гугл конечную оценку сайту дает по реальным показателям скорости, т.е. замеряет реальную скорость в реальном браузере пользователя. Попугаи - это лишь предварительная оценка гугла. Реальная будет зависеть от информации, которую каждый браузер (благодаря "счетчикам" гугла) передает в гугл. попугаи - это лишь имитация. гугл просто так не обмануть. заметьте, что на картинке 92 балла попугаев (на основе имитации), и совсем другие баллы реальных наблюдений. И тут уже гугл пишет о низкой скорости. Для многих это будет вообще непонятно. Как так? 92 попугая и низкая? Поэтому полезно тому же Сафари отдавать именно сжатый JPEG, гугл будет замерять реальную скорость и собирать ее в Данные наблюдений. Конечный вывод гугл делает именно по этим данным.
-
В любом случае если есть альтернатива, которой для вас достаточно, то это хорошо. у вас есть возможность выбора. Реальную возможность сжатия JPEG проверю. Она (точнее - оптимизация) была заявлена и в моей бете пейджспида, но не работала. Заявить - не значит работать. Возможно, что все сильно изменилось. Буду проверять. Тут бы наглядно посмотреть результат, а не заявление. # Lossy image recompression quality (0 to 100, -1 just strips metadata): ModPagespeedImageRecompressionQuality 85 Очень сильно сомневаюсь, что здесь идет речь о сжатии в привычном нами понимании. Если хотя бы исходить из того факта, что JPEG - это сам по себе сжатый формат с потерей качества, т.е. та самая "Lossy image recompression quality ". Рекомпрессия в данном случае не аналог сжатия того же mozjpeg. Если откроете википедию, то станет понятно насчет этого "сжатия": Вот JPEG как раз и есть формат, использующий сжатие с потерями. Это совсем не то сжатие. А вот mozjpeg сжимает уже сжатое. Те результаты, которые я вижу сейчас, говорят о том, что JPEG не сжимается (не сопоставимо с результатом mozjpeg или webp). Сужу по сайтам, где включен пейджспид сейчас. Мои заявления строятся на знании вполне конкретной версии пейджспид под nginx, довольно уже устаревшей. Да, что-то уже неактуально. остальное проверю.
-
когда получите реально сжатый JPEG, то милости просим с цифрами. Например, если размер получается примерно равный WEBP, то можно говорить, что сжимает. у меня с JPEG ничего в этом плане не получилось хорошего. В моей бета-версии пейджспида не было встроенного механизма именно для сжатия JPEG. Лишь для оптимизации, что не одно и то же. Для PNG он в бете был. И я это отметил выше. назовете механизм сжатия JPEG, который использует пейджспид? Я это все изучал до того момента когда выбрал mozjpeg и сделал Компрессор. Возможно, что в плане сжатия что-то изменилось с выходом релиза?
-
@stickpro , да вижу, что новая версия умеет делать webp. я писал с оговоркой. судил по еще бете. да, это плюс. @rassigor , кстати от пейджспида есть довольно странные эффекты. При оценке он сам на себя ругается. А потому страница Категория имеет низкую оценку.
-
Оппонент, мягко говоря, не замечен был в честности. Зато в другом - это сколько угодно. @rassigor Судите сами. 1) Вы использовали сжатые изображения, но не озаботились элементарной оптимизацией JS, CSS. 2) Далее оптимизируете за счет mod pagespeed ваши JS, CSS и одновременно отказываетесь от сжатия изображений. Вы считаете, что ваш план № 2 - замечательный? Могу сделать косвенный вывод, что в вашем случае для главной страницы оптимизация JS, CSS была более приоритетная по сравнению с изображениями. Но это не для всех магазинов так. Вы выбираете что-то одно в оптимизации, что довольно неправильно. Комплексный подход?
-
жаль, что только сжатие JPEG не подключают....
-
Друзья, какой смысл в одну кучу валить функционал работы с изображениями (водяной знак, обрезка, сжатие и т.д.) и оптимизацию за счет правильного подключения JS, CSS? Mod Pagespeed поднял попугаи за счет оптимизации JS, CSS? Да, это так. Но этот же мод не умеет сжимать JPEG и делать их вес, действительно, меньше. Не умеет делать WEBP (актуально для прежней беты, нынешний релиз может). Но на общем хостинге, например, Pagespeed не отдает в браузер картинку WEBP. Тот же таймвеб именно так это делает. Т.е. он вроде как есть, но воспользоваться им просто так вы и не сможете. На VDS - это другое дело. @rassigor , что мешает вам использовать одновременно возможности Mod Pagespeed и модуля Компрессор? Возможно, что вы решили, что этот мод и изображения тоже сжимает? Или, может быть, есть посыл, что изображения - это неважно, а вот оптимизировать JS, CSS - это супер? Призываю прежде всего всех учиться анализировать. Вот смотрите сами. Вы отказались от сжатых изображений, т.к. Mod Pagespeed не умеет сжимать. Вот ваше изображение (c вашего сайта): Оно уже НЕСЖАТОЕ после пейджспида. Оно, правда, лучше чем после дефолтного GD опенкарта. А вот ваше изображение, сжатое mozjpeg. а вот WEBP: А теперь сравните. ================================== Итак, @rassigor , что же вы получили? Ваш файл JPEG после mod pagespeed стал "оптимизированным" и равен 66 К. А вот webp, который выдает модуль Компрессор равен 51 К. И примерно столько же весит файл после mozjpeg. 66 К после пейджспид и 51К после модуля Компрессор. Кто лучше оптимизирует изображения?
-
Ну вы же их спровоцировали. Без ссылки на говнометателя никак нельзя было обойтись? Так и говорили бы про нее. Зачем ссылки про "аферистов то кидали"? думаете, что этим улучшение сделаете? Могли же просто на примере вашего сайта все рассмотреть? Я бы вам даже детальный анализ сделал. Показал бы что и как влияет. При отключенном и включенном моде. (Если его собрали как динамический модуль) а вы сами никак не могли объединить JS, CSS? Ведь это мод никаких чудес не делает. Может еще встроить ленивую загрузку. Но вот только со сжатыми изображениями у этого мода есть проблемы. Они их не делает даже на уровне модуля Компрессор. Он их делает хуже. И знаете почему? Потому, что у гугла нет лицензии на mozjpeg для jpeg. Поэтому для сжатия JPEG он его не использует. Гугл мог бы использовать для JPEG свой алгоритм guetzli, но не использует, т.к. он крайне медленный. Поэтому в mod pagespeed нету нормального алгоритма для сжатия JPEG. Я этот мод изучил вдоль и поперек. Если кто-то хочет возразить, то пусть назовет каким чудом mod pagespeed умеет сжимать JPEG ? Может быть, jpegoptim? Так он может оптимизировать и несколько уменьшить вес, но он не сжимает! Для PNG я сказал, что использует mod pagespeed .
