sitecreator

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

если вы про название файла изображения, то это название не меняется. если название файла кириллическое и/или содержит невалидные символы, то ссылка с названием такого файла (но не сам файл) будет закодирована как полагается по стандарту RFC3986.

Версия 2.2.1 Добавлена диагностика для контроля свободного пространства на диске, т.к. бывает, что пользователи банально не контролируют свободное место на диске, а оно имеет тенденцию заканчиваться. Если остается менее 500 Мбайт (0.5 Гиг), то строка информации меняет цвет на красный, что должно заставить обратить внимание на малое кол-во места на диске.

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

Интересно, а как ведется подсчет размера очень большого файлового кеша, например, изображений? За один раз? Каждый раз заново? В ряде случаев он занимает объем в десятки гигабайт, иногда сотни гигабайт. Да и файлом может быть сотни тысяч. Вы это делаете средствами php в предположении, что за ограниченный (стандартный лимит 30 сек) отрезок времени подсчет будет завершен? А если не будет? Другими словами: на больших магазинах тестировали, будет ли работать? И что значит "норма" для кеша изображений? На основании чего определяется эта норма? И что предлагается делать если "не норма"?

Новая версия для опенкарт 3.0 1.3.1 для opencart 3.0 и ocstore 3.0. Улучшена совместимость. установлена актуальная версия elfinder 2.1.57

Версия 2.2.0 Улучшена поддержка сложных структур изображений с использованием тегов <picture> и т.д. и т.п. в плане создания и вывода формата webp. например, таких: <picture> <source media="(max-width: 539px)" srcset="./image/catalog/icon/more_bannermobkopija.jpg"> <source media="(min-width: 540px)" srcset="./image/catalog/icon/more_bannerpk2kopija.jpg"> <source media="(min-width: 940px)" srcset="image/catalog/icon/more_bannerpk2kopija.jpg"> <source media="(min-width: 1240px)" srcset="/image/catalog/icon/more_bannerpk2kopija.jpg 1x, /image/catalog/icon/more_bannerpk2kopija.jpg 2x"> <img src="./image/catalog/icon/more_bannerpk2kopija.jpg" alt="Слайдер" class="img-responsive" /> </picture>

будет. а куда ж деваться то? за все приходится платить.

можно и так сказать. Чтобы все было идеально на экранах с высокой плотностью точек нужно делать соответствующую верстку, поддерживающую такие экраны. например, так (через srcset заданы картинки для разных экранов по плотности пикселей): <img src="/image/catalog/2.Jpg.webp"srcset="/image/catalog/2.Jpg.webp 1x, /image/catalog/_media_folder/2-sm.jpG.webp 2x" alt="Магазин" title="" width="331" height="67">

все банально как всегда. я оказался прав. на странице товара @Greyphon смотрит вот так: Разумеется, что картинка 1200 х 800 будет существенно лучше выглядеть в окошке просмотра 363 х 322, особенно на экранах с высокой плотностью. Вот и весь секрет. Никакого замыливания не создается. Просто вы получаете разницу в качестве картинок исключительно за счет их геометрических размеров и, соответственно, их веса. А экран высокой плотности позволяет воспроизвести больше деталей с картинки бОльшего веса.

это запросто. Т.е. сама картинка может быть нормальной если смотреть ее отдельно, но за счет преобразования браузером может ухудшиться. Т.е. дело может быть не в опенкарт, да и вообще не в сервере и его обработке. Как и прочие ресайзы как на стороне сервера, так и на стороне клиента (в браузере). Множественные ресайзы в любую сторону (от большего к меньшему, от меньшего к большему) могут ухудшить качество. Нецелочисленный ресайз может ухудшить качество. Чтобы не гадать предлагаю показать сайт и сами изображения. Кстати, когда появилась поддержка WEBP в FireFox, то он крайне некачественно рендерил эти изображения если требовался для них ресайз, появлялась замыленность. При этом он делал хорошо рендеринг JPEG, PNG при таком же ресайзе.

там и 90 было достаточно выше крыши обычно. Есть крайне редкие случаи когда этого мало. Но в этих случаях лучше использовать PNG, а не JPEG. он этого и не делает по умолчанию. вероятно, что у вас проблема в чем-то другом. а, вообще, обсуждать такие темы не видя ни сайта, ни картинок (предмета обсуждения) - занятие неблагодарное и бесперспективное. Источников проблем может быть очень много. например, на хостинге (сервере) включена оптимизация изображений (webp), но по умолчанию качество равно лишь 75, и никак не регулируется, а потому сервер может замыливать ваши изображения. разница в плотности пикселей изображения. Может проявляться как на экранах обычной плотности, так и на экранах повышенной плотности пикселей. Например, картинка 400х400 будет всегда более качественно смотреться в окошке 200х200 по сравнению с картинкой 200х200 даже на обычном мониторе (не 4К). картинки JPEG, подготовленные в Фотошоп с максимальным качеством будут всегда более качественные и бОльшего веса чем преобразованные на сервере за счет библиотеки GD и т.п. Т.е., грубо говоря качество 100 в фотошопе и 100 в GD - это две большие разницы по качеству и весу. Но заметно на глаз это далеко не всегда, а только на очень специфических изображениях с массой мелких деталей. Но если делать в PNG, то разницы практически нет, но это крайне тяжелый формат. другие причины.... В Опенкарт используется для работы с и изображениями графическая библиотека GD, обычно ее качества достаточно в подавляющем большинстве случаев. Но есть боле качественная графическая библиотека - это imagick (imagemagick), с помощью нее можно добиться наилучшего качества. Imagick делает более качественно ресайз изображений, особенно от маленького размера к большому, в сравнении с библиотекой GD. Есть программное решение, разработанное мною, которое поддерживает практически все необходимые действия с изображениями и полный контроль над качеством изображений, включая сжатые изображения. Сжатые - без потери качества, включая преобразование формата без потерь PNG в WEBP Lossless. Модуль Компрессор может использовать в приоритетном порядке библиотеку Imagick вместо GD, которую использует опенкарт. (Кстати, преобразование в WEBP Lossless не равносильно выставлению качества = 100) Это программное решение (модуль Компрессор) неоднократно используется в магазинах, которые сами делают фото-сессии своих товаров, а потому у таких заказчиков крайне повышенные требования к качеству конечных изображений, включая качество сжатых изображений. При желании могу помочь вам полностью разобраться с вашей проблемой размытых изображений, а также настроить модуль Компрессор.

Модуль Компрессор поддерживает использование двойной плотности и использование в шаблонах srcset не смотря на то, что такие шаблоны можно пересчитать по пальцам одной руки. А вот возможностью Компрессора "не создавать белые поля" мало кто пользуется. Пока Вы - первый и единственный заказчик, кто решил эту возможность перенести на изображения для экранов высокой плотности (и т.п), т.е. там, где используются коэффициенты 2х 3х 4х и т.д. Поэтому речь идет не о телефонах с двойной плотностью (они поддерживаются, и srcset поддерживаются), а о крайне редкой комбинации функционала, не востребованного до сих пор никем. К тому же идет непрерывная борьба за скорость загрузки контента, поэтому все эти 2х...4х в любом случае будут сильно тормозить страницу. Палка о двух концах. Да и исходники должны быть соответствующего качества с хорошим разрешением, т.е. большие и тяжелые. У большинства магазинов просто нет таких хороших исходников, т.к. контент просто парсится у конкурентов как распространенный вариант. И тяжелые картинки, особенно в большом кол-ве резко увеличивают требования к мощности хостинга, т.к. нужно хранить в несколько раз больше изображений, и обработка на лету может оказаться очень долгой, а на части хостингов просто не будет успевать завершиться за лимитированные 30 сек, я говорю про обычные jpeg, png. Итак, srcset для двойной (2х) и какой угодно плотности пикселей модуль Компрессор поддерживает, но редкую функцию "не создавать белые поля" для таких опционных изображений я не делал, т.к. это просто никому не нужно. Большинство вообще только webp + lazyload используют, даже водяной знак людям нужен лишь в 20% случаев, а остальные редкие функции еще меньше востребованы. Поэтому по заказу могу сделать любую индивидуальную разработку.

Здравствуйте. Не имеет значения где находится ссылка на изображение в коде HTML, главное, что изображение попадает в кеш, который создает опенкарт. Изображения идентифицируются по их геометрическим размерам, и не важно где они будут использоваться. Опенкарт когда создает изображение для кеша, то понятия не имеет где оно потом будет использоваться, да и использоваться оно может в самых разных местах одновременно. Поведение организовано правильно, и будет неверно его менять, т.к. может неопределенность получаться. Если у вас используется srcset для изображений под экран Retina, например в шаблоне Journal 3, то функция "не добавлять белые поля" не сработает для этих изображений. Но Journal 3 - это по идее уже даже и не шаблон в обычном понимании, т.к. сам меняет библиотеку для работы с изображениями. Кроме Journal 3 не встречал пока шаблоны, которые создают дополнительные изображения под экраны высокой плотности. Можно, конечно, запрограммировать код специально под Journal 3. Но указанную выше функцию мало кто использует, поэтому это будет заказная индивидуальная работа. В принципе могу сделать на взаимовыгодной основе. Код в этой части открыт и ничто не мешает его изменить вам самостоятельно при желании.

Адаптивная обрезка (адаптивный ресайз) может быть полезна в ряде случаев. Можно более красиво отображать товары. И сделать это можно совершенно автоматически. С помощью модуля Компрессор. Напоминаю, что модуль Компрессор имеет огромные возможности по управлению различными параметрами изображений, например, все мыслимые манипуляции с полями: создание нужных полей там, где это нужно изменение цвета полей. поля могут быть не только белые НЕ добавлять поля там, где вы считаете это ненужным и даже удалять сложные поля прямо из исходников интеллектуальным способом (как отдельная опция) Пример ниже. ДО и ПОСЛЕ:

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

Я примеры привожу лишь для поднятия интереса к теме создания относительно НЕВЗЛАМЫВАЕМОГО софта. Можно также назвать ТЯЖЕЛО ВЗЛАМЫВАЕМОГО софта, т.к. при желании взломать можно, что угодно - было бы время и целесообразность. Разумеется, что в публичном пространстве никто вам готовых решений не выложит по вполне понятным причинам. Но, как минимум, такие простейшие примеры заставляют работать голову и кто-то усомнится в том, что ионкуб - это полное фуфло в плане защиты. Простой пример. Для тренировки мозга и способностей хакера. Есть, например, один единственный закубированный файл программы. И вы точно знаете, что он использует один единственный внешний (удаленный) ключ, получаемый удаленно с тоже известного сервера. Ключ получается по протоколу https. Кто возьмется взломать? Найдется ли хакер? Кстати, защитить один единственный файл - это намного проще и надежнее. Одна из проблем при защите - это взаимодействие с массой других открытых файлов через публичные функции и т.д. и т.п.. Черный ящичек защитить можно намного сильнее. -------------- чтобы защититься от хакера-пионера, купившего абонемент за 15 евро на взлом закубированных модулей, достаточно использовать хотя бы один даже очень примитивный динамический ключ внутри программы вида: x = 2 + 2;

Нет. Причины разные. Например, одна из самых распространенных. Автор желает чтобы его модуль работал на древних php , например, на 5.5 или еще более древних. И автор желает чтобы ионкуб лоадер 6, который встретишь в 1 случае из 500, тоже поддерживался. Люди не хотят покупать, например, "ионкуб про" за 300 $, да еще и с ограниченным сроком использования, но хотят пока остановиться на ионкуб онлайн. Это не то, что догадки, я просто знаю этих людей, мы обсуждали эти темы. И чтобы поставить защиту хорошо недостаточно просто выполнить какие-то простые манипуляции, нужно потратить довольно много времени на это. Если модуль написан за неделю, например, то не каждый захочет еще тратить время на составление защиты. Разработчики в 95% случаев не желают использовать для генерации лицензионного ключа (не связано с ионкубом никак) несимметричные криптометоды, а потому в этих 95% случаев хакеры просто выдирают генератор ключа из самой программы. @Shureg , как вы думаете почему разработчики так поступают? Даже далеко не новички. А ведь это намного проще чем использовать грамотно защиту ионкуба. И ничего не стоит в деньгах, не надо никакой коммерческий софт для защиты покупать. Эффективность в том, что хакер не сможет сделать так любимый варезниками KEYGEN. Хакеру нужно каждый раз заново ломать новую версию программы. Но не делают же! Думаю, что просто не знают. Не знакомы с базовыми методами криптографической защиты.

@Shureg , а еще есть удаленный ключи. Это тоже ВНЕШНИЙ ключ, но до которого при всем желании вам не добраться. могут находиться на каком угодно "далеком" сервере, передаваться по закрытому протоколу (с сертификатом и т.д.) и практически не отлавливаются (не перехватываются ) на сервере. Это чисто для понимания возможностей. Я, например, противник привязывания работы любого приложения к серверу разработчика или любому подобному серверу. Я лишь привел как пример. Этот ключ вы никак случайно удалить тоже не сможете. Как и ключ внутри другого ключа, например, внутри нативной лицензии ионкуба. Предвидя ваш возможный страх, скажу, что я не использую в своих модулях зависимость от сторонних серверов во время работы сайта заказчика. По разным причинам связь с удаленным сервером может отсутствовать. Я считаю, что покупатель должен поставить модуль и работать, да хоть на локальной машине вообще с отключенным Интернетом. Поэтому прошу считать пример с удаленным ключом именно как академическим примером. Но чисто в экспериментальных целях стоит попробовать, просто для понимания как работают НЕстатичные ключи. Взломать такой закубированный файл с подобным ключом невозможно чисто в автоматическом режиме. Варианты взлома есть, но они довольно сложные.

@Shureg , вы хотите сказать, что у вас возникнет непреодолимое желание изменить что-то в подобном файле? Сильно сомневаюсь, что вы получите от этого пользу. А вот неработоспособность - это запросто. Не стоит все доводить до крайностей и абсурда. Понятно дело, что закрытые кубом файлы не подлежат редактированию по умолчанию, это бессмысленно. Я лишь сделал маленький намек на то, что в ионкуб есть интересные средства. Но любой серьезный инструмент требует аккуратности. Постарался сделать это наглядно. Но, то, что годится для наглядного эксперимента, не всегда нужно переносить в готовый релиз. Для этого голова вроде бы и дана.

@Shureg , динамический ключ находится как бы "внутри " закубированного файла. Хоть его там и нет если понимать буквально, т.к. он вычисляется в результате определенных действий и в результате определенных последовательности событий. Он не потеряется, не волнуйтесь.

Надеюсь, что вы просто шутите. я лишь привел возможные варианты для наглядности. и простоты понимания. это не значит, что нужно тупо использовать то, что годится как простой пример. я в блоге подробно описывал какие есть подводные камни у тех же динамических ключей. Их можно использовать, но осторожно - крайне осторожно. И в профессиональном форуме на сайте ионкуба тоже есть информация на эту тему. Не стоит доводить до степени абсурдности вроде "заставь дурака Богу молиться...", согласны? А вы хотите изменять закубированный файл? "Понятно, буду иметь ввиду" (с) Надеюсь, что вы поняли эту шутку как намек? В качестве ключей используют такие данные, которые не могут быть просто так изменены.

Вы сильно заблуждаетесь. Боюсь, что даже не представляете насколько. защита от простачка - это только если вы используете онлайн ионкуб. Но настоящие пацаны этим средством от лохов (или для лохов?) не пользуются. Я еще в 2017-м доказал на практике, что грамотно поставленный ионкуб сломать невозможно ни за день, ни за полгода. Точнее, уже сил и мотивации не остается у хакера, хоть и делает он свою работу за деньги и одновременно ради удовлетворения собственных амбиций. вот прямо начиная с версии 5.6 php можно хорошо защитить. и если вы делаете под ионкуб лоадер 10, а он уже более 3-х лет на всех хостингах, и иного вы не найдете. К чему эти мифы, пропахшие нафталином, а точнее, неверная информация? Не пора ли поучить матчасть и убедиться, что мир изменился за эти 5-6 лет? Если вы хоть чуть-чуть знаете как работает ионкуб, то должны понимать, что даже элементарный внешний ключ или единственный динамический ключ приводит в полную негодность декодоры ионкуба, т.к. статический код php без запуска в соответствующей окружающей среде невозможно декубировать по той простой причине, что ключа то в принципе нет, а потому нечем делать расшифоровку. А взлом в ручном режиме в реальном программном окружении - очень дорогая задача. Не в пример автоматическому декубатору. И прогнать вам нужно программу во всех режимах и со всеми на свете разветвлениями. И комментариев в коде у вас не будет, впрочем как и читаемых переменных, названий функций и т.д. и т.п., а будет у вас кругом абракадабра. автоматические декодеры построены по принципу, что ключ для дешифрования запрятан внутри самого закубленного файла (в случае онлайн кубирования это так). Поэтому сперва декубатор ищет этот ключ, хоть в старших версиях (7.1-7.4) это делать сложно или уже почти невозможно. А если ключ внешний? Декубатор сделает круглые глаза и попросит дать ему ключ. Думаете вам вместе с ключом на блюдечке закубированный файл подадут, а на ключике будет бирочка "это ключ"? А этим ключом может быть любой файл опенкрт (или НЕ опенкарт), например, любая картинка может быть. Ключом может быть вовсе и не файл. Динамическим ключом может быть вообще что угодно, чего нет, пока не произошло какое-то вычисление в связи с каким-то событием, которое еще знать нужно. Это я вам рассказал лишь детский минимум, которого достаточно чтобы сделать сервис декубирования абсолютно бессмысленным. Но когда вступают в схватку серьезные хакеры, то и для них много чего припасено. Зубы обломали, но не сломали. Полгода бились! В итоге выудили какой-то бессмысленный и нерабочий код, и признали, что ничего не могут поделать. @Zlobny , в общем, предлагаю вам почитать документацию к полноценному ионкубу. Появится пища для размышления. Возможно, что перестанете быть таким категоричным. Тот, кто воспользовался в свое время хотя бы минимальными моими советами, того не ломают. А совет простой: 1) читайте документацию на ионкуб прочитав эту документацию вы поймете, что онлайн ионкуб вам не подходит, т.к. для него документация состоит всего из одной строчки "нажмите на кнопку [закубировать]". Вот взлом закубированного через онлайн кубатор файла настолько же сложен насколько сложна инструкция к онлайн ионкубу. Я никого не агитирую, просто констатирую факты.

@sashaustenko , кавычки только сделайте двойными для украинского текста. Я поправил, а то вначале почему-то не отредактировалось сообщение как надо.

да там и не очень то сложно. примерно так (доп. стили делаете на свое усмотрение): html[lang=ru] div.required .control-label::before { content: 'Обязательно '; color: #F00; font-weight: bold; } html[lang=ua] div.required .control-label::before { content: "Обов`язково "; color: #F00; font-weight: bold; }