sitecreator
-
Публікації
6 116 -
З нами
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача sitecreator
-
если вы делаете шаблон полностью сами, то можете использовать это решение. просто оно не применимо к готовым шаблонам, иначе все правила CSS нужно переписывать, т.к. правила вроде этого: div + img { } не будут работать. В общем, вылезет куча подводных камней. если используете готовый готовый шаблон и не планируете его переделывать, то проще реализовать все через конфиг nginx. Суть простая. Браузер , запрашивая картинку с сервера дает информацию о поддерживаемых браузером форматах. Если webp входит в этот список, то отдает сервер webp не смотря на то, что браузер просил jpeg/png. Если в списке нет поддержки, то сервер отдает картинку как обычно. Если смотреть в инструментах браузера, то получаемый файл webp будет с расширением jpeg/png соответственно, т.е. расширение не меняется. Можно, конечно, и через Апачи решать, но для статики это не рекомендуется. Лучше через nginx. -
почему же не получится? при желании все получится. у вас для разных языков начальный тег имеет разные атрибуты lang. пример: <html dir="ltr" lang="ru"> <html dir="ltr" lang="en"> Соответственно ничто не мешает вам сделать два правила CSS под разные языки.
-
там, где можно было просто решить вопрос грамотной версткой и стилями CSS, создатель опенкарт даже в самой свежей 3-ке по-прежнему использует белые поля. Довольно нелепый архаизм для 21-го года. Изначально эти поля использовались для центрирования картинок даже в IE6 в каком-то далеком и лохматом году. Для современных браузеров такой подход не нужен при правильной верстке. Уже и flex давно везде активно используется, включая бутстрап 4-й, а тут все еще полями картинки центрируются. Для некоторых макетов заказчики просили меня еще давным давно сделать возможность не использовать эти поля, что я и добавил в свое решение.
-
но я тоже использую решения других программистов когда нужно готовое. с ним по крайней мере не бывает тех косяков, которые есть в GD (и в меньшей степени в imagick). В GD самая дурная реализация, даже в составе довольно свежих версий php 7.*. Нужно лепить костыли, иначе получаются неприятности, которые вы видели. у imagick есть неприятная особенность - это вываливать fatal error в тех случаях когда GD просто делает warning и программа работает дальше. Это все нужно учитывать если будете писать универсальное решение. Cwebp в плане предсказуемости результата работает лучше всего. И не забывайте еще решить задачу вывода webp, ведь создать - это только половина дела. Самый простой способ вывода - это средствами веб-сервера. Довольно все универсально, и каждый браузер получит то, что он умеет читать. Обычно нужно изменить конфиг nginx для этого. Собственно в таком случае никакого программирования не нужно.
-
Это известные баги от GD. я их описывал несколько лет тому назад еще. может быть есть смысл использовать готовое решение? Я предлагаю на выбор три движка для создания webp: 1) GD (работает с исправлением, а потому картинок-неведимок не получите, корректная замена альфа-канала на белый чтобы избежать черного фона) 2) imagick 3) cwebp . Самый верный алгоритм создания webp. Работает в 99.9% случаев даже когда у хостера запрещен в php веб-сервера exec. Можно создавать через cron по расписанию с целью равномерной загрузки сервера и полного устранения ненужной нагрузки на веб-сервер. Также корректный вывод webp в браузеры, которые его поддерживают и отдача jpeg,png в другие. Учтены масса нюансов и проблем, о которых вы сейчас не знаете. Например, поддержка jpeg внутри png и наоборот. Решение платное, но зато учтены практически все нюансы с изображениями, которые когда либо возникали у пользователей. Т.е. это не только webp.
-
в РФ нет такой проблемы. Никто не обязывает ИП-шника открывать расчетный счет, он имеет право по закону использовать свой личный счет. Заплати, например, патент и используй какие угодно кошельки, размер дохода уже не интересует налоговую. Нет желания связываться с ИП, платить отчисления в пенсионный фонд, медицинский? Пожалуйста, вполне по закону становись элементарно самозанятым и спокойно принимай оплату на свою личную карточку, отчисляй 4% с полученных сумм и будет все ОК. Вообще никаких проблем нет работать легально. 4% отчислений государству - это все ваши расходы при совершенно легальной деятельности. Правда, многие люди и эти несчастные 4% не готовы отдавать в виде налога. А вы помимо этого еще и 30% предлагаете сверху? И как тогда сможет конкурировать честный исполнитель, который платит налоги, отчисления и тд. с демпингатором, который вообще положил болт на налоги и прочее? Вы себя ставите в совершенно неравные условия. Заказчик пойдет к тому, кто предложит лучшую цену, а она будет там, где нет лишних посредников. Испокон веков в разделе "Услуги" заказчики договариваются с исполнителями без всяких посредников. Вряд ли они решат, что нужно отдавать 30% сверху еще кому-то от договоренной суммы. Будет очень сложно их убедить за что именно они должны сверху переплачивать.
-
Просто статистика по реальному магазину, взято из отзывов реального заказчика. https://opencartforum.com/files/file/4572-image-compressor-watermark-webp-lazy-load-etc-by-sitecreator/?do=findReview&review=34939 При наличии помимо jpeg еще и png эффективность применения WEBP значительно возрастает. Режим работы через CRON полностью исключает использование веб-сервера во время создания изображений, тем самым устраняются любые подтормаживания страниц даже в момент создания изображений. И у вас есть полный контроль над использованием ресурсов сервера чтобы процесс был максимально равномерным без всплесков нагрузки.
-
Здравствуйте. Можно для сайта отображать картинки с водяным знаком, а выгрузку для всевозможных агрегаторов делать без знаков. в таком случае будет создан отдельный кеш изображений для яндекс-маркета, Google Merchant и т.п. Т.е будут одинаковые картинки, но для разной целевой аудитории соответственно со знаком и без него. это задача для искусственного интеллекта, да и для него часто невыполнимая, т.к. непонятно чем заполнять пустоты под водяным знаком если он непрозрачный. не наш сценарий. можно делать две группы как описал выше. фактически это так. замечу, что в модуле заложен супер-быстрый алгоритм наложения водяного знака. Такого вы не встретите ни в одном модуле водяного знака.
-
https://ckeditor.com/ckeditor-4/demo/ (на этом демо представлена НЕ полная версия, но таблица там есть). вы можете применять стили к таблице, есть несколько готовых стилей для таблиц. а можете и не применять.
-
Что нового в версии 1.0.3 1.0.3 Обновление редактора CKEdit до актуальной версии 4.16.0 Обновление инструкции.
-
Вы можете оставить отзыв на специальной вкладке: https://opencartforum.com/files/file/7265-true-file-manager-menedzher-i-redaktor-izobrazheniy-dlya-opencart-2-i-30/?tab=reviews
-
Бывает... Внимательность - ключ к успеху.
-
@zemix , для начала кеши почистите в движке кроме кеша изображений. загрузите страницу через ctrl+F5. Возможные причины (предположительно): зависать может если у вас в одной папке многие тысячи изображений (десятки тысяч, сотни тысяч). Движок elFinder делает превьюшки. Может быть памяти php слишком мало на вашем тарифе, а файлов слишком много. Проходили варианты когда в одной папке было, например, 250 000 или 400 000 картинок. Только какой смысл в визуальном менеджере если просто физически нереально глазами искать картинку в таком массиве информации? Да и есть известный факт, что при огромном кол-ве файлов в одной папке начинает сильно тормозить операционная система при доступе к таким файлам. Да и любой менеджер сломается при таком объеме файлов в одной папке при попытке получить список всех файлов. Это очень затратная по времени операция для операционной системы. Например, менеджер файлов в ISPmanager тоже не может такой массив данных переварить. Повторюсь, что описанное выше относится к исключительным случаям, когда в одной папке картинок очень и очень много. Напишите мне в личку с доступами. Обязательно укажите доступ в панель управления хостера. Не вижу смысла засорять тему вашим частным случаем.
-
Здравствуйте. у вас причина указана в ошибке: невозможно создать папку, нехватка прав. причина, скорее всего, в неверных правах (и/или пользователе linux) на папки и файлы. Не рекомендуется использовать фтп для ocmod. для опенкарт 2.3 рекомендуется использовать фикс чтобы загрузка через ocmod-загрузчик происходила без использования фтп, это позволит избежать коллизий. Например, Local copy OCMOD by iSenseLabs. приложил. И внимательно посмотрите что у вас делается с правами на папки и файлы. Заметьте, сто проблема возникает не в моем модуле, а в установщике ocmod. Вам нужно сделать работоспособным этот загрузчик. localcopy.ocmod.xml
-
Учел ваши пожелания в новой версии модуля Компрессор. Но сделал это с более правильным подходом. Внедрил дополнительный режим lossless для преобразования pnp в webp без потерь. Визуальных изменений не заметно, но вес при этом примерно в 1.5 раза меньше чем в PNG. Сравнивал на представленных вами образцах изображений. использовал при этом алгоритм максимального сжатия, поэтому WEBP lossless будет существенно легче по весу чем PNG (который по определения является форматом без потерь). даже в этом случае OptiPNG дает существенно более худшее сжатие чем WEBP lossless, но при этом OptiPNG еще и работает крайне медленно.
-
Версия 2.1.25 Мелкие фиксы. Улучшена работа на серверах Windows Server для старых версий опенкарт (древнее 3.0-й версии). Для PNG добавлен режим преобразования в WEBP Lossless (без потерь).
-
какая чистая наивность! Кстати, назовите, пожалуйста, хоть один работающий механизм такого отслеживания. Как вы в сети будете это делать? Сколько %% ворованного вы сможете найти? И сколько %% от найденного ворованного сможете "вернуть", т.е. уговорить владельцев еще раз заплатить за модули? Ведь они в большинстве случаев уже заплатили. В итоге, получается, все сводится к лозунгам борьбы "за все хорошее против всего плохого" и к теоретизированию насчет возможных "эффективных" методов. А ионкуб, как ни крути, работает не в теории, а на практике. Все нормальные разработчики именно так и поступают. Поэтому страшилки про невозможность доработки закубированных модулей сильно преувеличены. И на куб многие разработчики перешли не прямо с самого начала. Жизнь заставила. Был выбор: прекратить развитие модуля или закубировать и идти дальше.
-
не закладывал такую возможность. никто пока не обращался с подобной просьбой, да и сам не встречал пока разительной разницы между изображениями, но в случае очень качественного png разница может быть, т.к. png - это формат без потерь. Можете скинуть в личку файлы для сравнения? Возможно, что нужно применить особые параметры для подобных изображений.
-
Да, он объективно сложный в плане оптимизации. По вашему сайту можно сказать, что определенные положительные перспективы есть. У вас есть виджеты типа VK, Живочат и тп. Это вполне можно оптимизировать. Кроме того тяжелые шрифты можно оптимизировать. Со стилями что-то можно сделать. Они у вас очень тяжелые, к тому же грузятся гигантские стили с сайта битрикс. Т.е. помимо непростого шаблона есть очень много дополнительных факторов от сторонних сайтов. Пишите в личку или на почту.
-
-
не заменяются. это в принципе не считаю, что особо целесообразно делать. ocstore умеет нормально работать с именами файлов, содержащими неправильные символы вроде кириллицы и т.п. Речь вовсе не про файловый менеджер. Не существует запрета на использования "левых" символов в названиях файлов внутри операционной системы. Эти символы могут быть в названии файла при использовании их внутри ОС Linux, Windows, но не могут быть в URI/URL согласно стандарту RFC3986. Согласно стандарту кроме латинских букв и цифр могут быть еще только следующие знаки в названии файла, передаваемом в URL : Вот ocstore нормально кодирует все эти "левые" символы в правильные последовательности согласно стандарту RFC3986. Т.е. проблема не возникает. И решена она уже внутри самого ocstore , что довольно правильно, т.к. закачивают часто по фтп и т.д. минуя менеджер. И решена она вовсе не за счет перекодирования в менеджере файлов - это лишь костыли, которые не всегда работают. В родном opencart и сборках на его основе (не ocstore) проблема остается с "левыми" символами в названиях файлов изображений, но она решается, например, за счет использования комплексного решения для работы с изображениями (модуль Компрессор):
-
В отличие от примитивных решений, сделанных на коленке, при создании модуля Компрессор учтены реальные ситуации, которые часто очень далеки от идеальных. А это, например, битые входные изображения, или изображения с неверным типом. Простые решения годятся лишь как экспериментальные, но не для работы. Модуль Компрессор использует контроль над выполнением самой задачи в cwebp (imagick, GD). Отслеживаются ошибки выполнения, отслеживается конечное изображение, т.е. создано ли оно, создано ли оно без ошибок и т.п. Ничего подобного в простых решениях просто нет. Простой свежий пример. Реальный сайт. Здесь могла бы быть фатальная ошибка, возникающая бесконечно. На реальных сайтах не бывает битых изображений? Причем они битые были до установки Компрессора. Но браузер может вам простить битый JPEG и сможет его все же как то отобразить, но вот imagick/ cwebp вам не простит такое изображение как входное. Если входное изображение - битое, то Компрессор не будет до бесконечности пытаться из него сделать webp, а именно пометит его как поврежденное. И, главное, покажет пользователю его битое изображение специальной надписью "БИТОЕ ИЗОБРАЖЕНИЕ (CORRUPTED IMAGE)". Если бы этого не было, то пользователя ждала бы гора сообщений об ошибках PHP, но пользователь мог бы этого и не заметить никогда пока лог ошибок не разросся бы до неимоверных размеров. Да и не понимал бы пользователь почему вместо некоторых картинок у него пустое место. Например, тот же imagick будет вываливаться с фатальной ошибкой, и вы даже не увидите отображение страницы кроме сообщения о фатальной ошибке в лучшем случае, и это еще хуже чем просто пустое место вместо картинки. И если не предпринять меры, то это будет происходить до бесконечности. В простых решениях нет никакой защиты от таких реальных ситуаций, а в модуле Компрессор есть. В нем нет даже нет не то, что контроля изображения на выходе, т.е. проверки создалось ли оно вообще, насколько удачно создалось и тп., но нет даже никакого контроля за выполнением программы в exec. Т.е. запустили exec, а дальше хоть трава не расти. А запустилось ли оно вообще, а завершилось ли оно, а успешно ли завершилось, насколько долго работало по времени? - таких вопросов в простом решении никто не задает. И не задает потому, что никогда не тестировались подобные решения массово на реальных сайтах, на которых бывает куча проблем. На реальных сайтах слишком много всего неидеального. Пример битого изображения: Его даже покажет браузер насколько сможет, но подавится imagick с фатальной ошибкой. GD поперхнется, но выдаст предупреждение. Такие изображения на сайтах - это реальность. Также как и реальность "PNG внутри JPEG" или "JPEG внутри PNG". Да, такого быть не должно в идеальных условиях, но в реалиях это далеко не так. Если не учитывать такие моменты, то будут возникать проблемы у пользователя. Модуль Компрессор учитывает.
-
Что нового в версии 1.0.2 Добавлено автоматическое определение и переключение языка при изменении языка в админке. Обновление редактора CKEdit до актуальной версии 4.15.1 ВАЖНО!!! При обновлении модуля нужно учитывать тот факт, что браузер кеширует файлы редактора (js, css), поэтому важно обновить/очистить этот кеш. В админке на странице, где появится редактор, необходимо сделать обновление страницы в браузере через ctrl+F5 чтобы обновить файлы редактора в кеше браузера. Обычно достаточно сделать это один раз. Проверить, что все в порядке можно вызвав информацию о редакторе.
-
@booss , я не приостанавливал. Просто на демо модуля было название сайта. Я его убрал в демо и замазал на скриншоте чтобы было все согласно требованиям. В общем, теперь идет проверка модератором. Ждем. Поддержка заказчиков осуществляется по прежнему. Развитие не останавливается, новые версии выходят и будут выходить. Перемодерация не связана никак с функционалом модуля.
-
Первый раз наблюдаю картину когда на хостинге imagick не умеет работать с альфаканалом для webp. Но это не проблема если использовать cwebp. Его всегда рекомендуется использовать как приоритетный движок для создания webp в Компрессоре. Компрессор позволяет сделать тщательный анализ корректности работы движков (библиотек), которые могут быть использованы для создания webp: GD imagick / imagemagick cwebp
