sitecreator
-
Публікації
6 116 -
З нами
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача sitecreator
-
из растра в вектор? Для чего? это невозможно. Точнее, есть, формально, конвертеры в вектор, только такой вектор будет, мягко говоря, значительно тяжелее растра, и браузером будет обрабатываться дольше растра. В графических редакторах типа фотошоп есть подобные возможности, я даже сам с этим экспериментировал, но это весьма условный вектор будет на выходе. Реального четкого вектора, который будет масштабироваться без потерь четкости, вы все равно не получите. Например, шрифт, отрендеренный из вектора в растр, вы назад уже не превратите в вектор, который бы можно было реально использовать. в svg можно также сделать вставку растрового изображения в jpg. Но зачем? svg --> jpg Вот это можно было бы еще понять. Но обратная задача по сути не имеет никакого смысла. Обычно полезно бывает написать для какой же конкретно цели вам это нужно. Чего добиться хотите? Иначе это все равно, что на форуме по какому-то автомобилю написать "ищу кто сделает из круглых колес квадратные". Тут же найдутся советчики, и скажут, что в таком-то шиномонтаже такой-то мастер своей кувалдой сделает из ваших круглых квадратные. И ведь сделает же! Клиент всегда прав? Хотя обычно все хотят квадратные поправить до круглых, и вот эти желания вполне понятны. Хотя, может быть заказчику нужно автомобиль ставить на стоянку на уклонной местности, а ручник не держит? Тогда тут квадратные колеса - это выход. Но то, что ездить не будет - то такое... Главное, что с горки теперь не укатится сама. Но " jpg в svg " - это все равно как "надо круглые колеса в квадратные"... в данном случае это не главное. Смысл самой затеи в чем?
-
Лаконичный ответ когда ответа нет. Т.е. другими словами, за свои слова вы не отвечаете? а для чего вы пишите тогда? Т.е. вы даже не знаете что именно сами собрались заменить на "MongoBD"? На замену чему? Которая, конечно же MongoDB подразумевалась? Так и скажите, что сами глупость ляпнули, но не понимаете как это теперь объяснить.
-
это зачем? и вместо чего? неужели для этого? Звучит завораживающе, но фантастически.
-
будет. скорость уменьшится с вашим twig. -
А почему вдруг такая категоричность случилась? Это хоть чем-то обусловлено? Даниель это как-то объясняет? Что такого невероятно прорывного используется в коде php опенкарт, что он даже на 7.4 не будет работать? Есть примеры? Да и для чего такая заведомо невероятная несовместимость? Далеко не у всех хостеров есть 8-ка для выбора. Да и не все расширения php есть для 8-ки. ioncube нет пока, например. Реального прогресса от 8-ки мы, думаю, вряд ли увидим в опенкарт, пока вижу это как "дурью маются".
-
это будет другой договор. персонально с вами. в свое время я с эстонскими юристами обсуждал создание такого договора, который бы не противоречил законодательству обеих стран. Создание такого документа - это вполне реальность. Иной договор не имеет смысла, т.к. его попросту может не принять банк как основание для зачисления средств в случае поступления средств из-за рубежа. Вы же именно договором подтверждаете легальность таких поступлений. в идеальном мире, может быть и т.д.
-
вот тут вы ошибаетесь. наша область - сильно специфическая, особенно если работаете с зарубежными продажами. Только недавно отменили "налог на гугл", который по дури сначала ввели чтобы "защитить отечественного производителя", но который заставлял быть предпринимателя налоговым агентом зарубежного партнера, т.е. получилось все с точностью до наоборот. Именно в последние пару лет применялись и отменялись масса законов в цифровой деятельности, очень часто крайне противоречивых до абсурда законов. С самозанятыми много пока неясного. В моей налоговой, мягко говоря, очень плохо разбираются в этой теме инспекторы. Впрочем, они в плане "цифровых товаров" вообще плавают в тумане заблуждений. @devimirochnik , попросите администрацию предоставить вам агентский договор. Далее можете обратиться с ним к вашему юристу для разъяснений и проверки на соответствие российскому законодательству.
-
возможно, если вы в этом уверены. Проблема в том, что именно четко там не прописано. Все дело в трактовке. я в свое время консультировался со своей налоговой, а также обсуждал данный вопрос на горячей линии нашей налоговой. В один голос утверждали, что невозможно, т.к. речь не шла об "агенте", а именно об "агентском договоре", именно так было прописано в законе. Но вся соль будет в толковании. Но поскольку не раз убеждался в слабой подкованности наших налоговиков, особенно в плане нововведений, то их ответам не всегда можно доверять. тут лучше юристов спрашивать. Но мне отказали именно в налоговой.
-
@devimirochnik , для самозанятых недоступен вариант работы по агентскому договору. Об этом четко прописано. Т.е. продавать вы сами имеете право, но не через посредника в виде агента. платить надо со всей суммы. Т.е. за себя и за "дядю". Т.е. даже за комиссию, которую взял банк при оплате вы тоже должны платить налог. Платить должны со всей конечной суммы, которую платит покупатель. А там еще за перевод нехилая накрутка идет если платить в рублях, а возникает она из-за двойной конвертации, т.к. оплата идет через украинские банки, а они напрямую с рублем не работают, поэтому будет рубль --> доллар ->- рубль. Все это учитывать - это особая головная боль. Есть вариант стать ИП. Но тут есть масса других проблем. Например, налоги резко взлетели в несколько раз в этом году если вы пользуетесь патентной системой налогообложения. Так, например, в Москве вы обязаны заплатить всего 300 000 руб налога и работать спокойно по схеме ПСН. Правда, неизвестно сможете ли вы в принципе столько заработать чтобы не уйти в минус, но налог обязаны заплатить в любом случае. Посмотрел по Питеру, у вас налог всего 60 000 руб. Это ерунда по сравнению с Москвой. Чудеса какие-то с этими налогами по ПСН в зависимости от региона. Да, еще, разумеется не забываем про пенсионные и мед. отчисления. Ну это еще на уровне 60 000 р. Плюс патентной системы - это не надо делать никаких отчетов в налоговую, чеки тоже пробивать не надо. Но есть и минусы (см. выше).
-
@petr34 купон на скидку в 10% (на модуль Компрессор) для Вас и всех желающих. Действует на этом форуме.
-
@petr34 , кстати, учтите, что не любой webp бывает полезен.
-
Здравствуйте. Скидки периодически возникают, но без каких-то регулярных правил. временами просто раздаю по запросу скидочные купоны. Обычно достаточно написать на мою почту или в личку. в PNG имеет смысл делать картинки товаров в том случае если есть очень очень много мелких деталей, мелкого текста на изображениях. иначе нет смысла, т.к. PNG будет раз в 5 тяжелее JPEG при незаметном на глаз различие в качестве. PNG можно переводить в webp как с потерями, так и без потерь. В любом случае webp будет меньше по весу, даже если преобразовывать как lossless. Зависит от самих изображений. в 99% случаев оптимальным будет именно JPEG. И только в редких случаях - PNG. PNG хорош для баннеров где много мелкого текста, так текст остается максимально четким. правильно понимаете. Т.к. идет борьба именно за скорость работы страниц сайта. А тут все методы хороши, вплоть до перехода на VDS и сервер. Но есть еще технология mozjpeg, которая именно сжимает сам JPEG. Можно воспользоваться ею как альтернативой вместо webp, только работает mozjpeg с бОльшим потреблением ресурсов чем webp. Как говорится, за все нужно платить.
-
Гугл в очередной раз кардинально изменил алгоритм оценки сайтов. Новая версия Lighthouse 8.0 https://github.com/GoogleChrome/lighthouse/releases Изменилась оценка ввиду нового алгоритма как для страниц до оптимизации, так и после оптимизации. Для примера показана оценка в разных версиях анализа Гугла Lighthouse ДО и ПОСЛЕ оптимизации для одной конкретной страницы. Как видим, входные данные в цифрах одинаковые, но расчет итоговой оценки дает сильно разные показатели.
-
новая версия 3.2.0
-
Неплохо бы для сообщений, на которые поступили жалобы от пользователей, тоже поставить какой-то статус. Ну это лишь "по идее", т.к. предполагается, что это относится к порядочным людям. Аноним может позволить себе все. Не каждый, конечно, аноним.
-
да, вроде как игнорирует. Тут еще хуже. Пользователи будут писать в личку, а разработчик не сможет их читать и отвечать. Т.к. вместе с баном личка тоже банится. И даже на почту уведомления не приходят, что кто-то пишет в личку. Покупатель желает поддержки, но не понимает, что происходит. Т.е. покупателей форум тоже наказывает заодно с забаненным разработчиком. Никакого сообщения покупателю, что он пишет в пустоту, нет.
-
нельзя, значит. @wcp , работаю 17 лет с двумя крупными компаниями, дата-центры в Москве. если ссылки исчезают, то писать их тут бессмысленно. Могу судить по крупным магазинам для РФ и Украины. Это более 100 000 и 200 000 товаров, например. значит, вам, скорее всего, нужен хостинг в РФ. Но вам не глядя уже порекомендовали хостинг не в РФ. Как грится, "без лишних слов".
-
В графической библиотеке php GD (в некоторых версиях и сборках PHP) есть очень распространенная проблема - это невозможность работы с альфа-каналом. Происходит замена фона на черный при конвертации в WEBP из PNG. Эту проблему умеет решать Компрессор. Он не может решить ее на 100% с работающим альфа-каналом, но может задавать белый фон, это намного лучше чем получение черного фона. Для этого используйте настройки: Остальные проблемы, которые возникают из-за GD, а они есть почти в любой версии этой библиотеки когда речь идет о работе с WEBP, модуль Компрессор решает довольно эффективно и полностью автоматически. Используйте GD только в том случае когда нет никакой альтернативы для генерации WEBP. А они почти всегда есть. GD - самая глючная библиотека для работы с webp. Самая лучшая - это cwebp. Тут всегда предсказуемый результат и максимум гибкости, включая настройку как качества, так и степени сжатия, плюс полный контроль если нужен вариант lossless. Тест cwebp выглядит так: Как видите, никакого черного фона не возникает при прохождении теста создания WEBP.
-
проблема еще в том, что хостеры не поддерживают сам формат webp. Что толку если лишь в 15% случаев графическая библиотека GD php поддерживает webp? Именно эта библиотека используется в опенкарт. И даже из этих 15% поддержка webp в GD очень проблемная - часть изображений получаются с черным фоном, часть вообще невидимые становятся. Все начинается с хостинга. Ну нет там поддержки webp в подавляющем большинстве случаев. Любой код, написаный для GD не будет работать в 85% случаев когда речь идет о WEBP.
-
@Rassol2 @WEB_COAST , создал соответствующий блог чтобы обсудить необходимость создания решения для работы с webp. так сказать, полной его поддержки в опенкарт. Далее прошу все свои соображения писать в данном блоге.
-
А разве должно? См. мой пост выше. Предполагаю, что вы ставите поддержку webp как выходного формата для отправки в браузер. Это никак не решит проблему. Да и нет ни одного бесплатного решения по работе с webp, которые работали бы нормально, а не через пень-колоду. Все они работают условно нормально только на чистом опенкарт в идеальных условиях. См. выше мой пост, в котором я писал лишь небольшие примеры неидеальных изображений, которые встречаются на каждом шагу. @Rassol2 прав, когда говорит, что его SimplePars выполняет свою работу в объеме поставленной задачи. У SimplePars нет задачи обработать webp, там есть задача закачать изображения. Впрочем, возможно, что я могу и @Rassol2 помочь в решении вопроса скачивания правильного формата вместо webp или преобразовании webp в правильный формат (jpeg,png) чтобы далее все корректно работало без переделки опенкрат. У меня есть разные варианты решения данной проблемы. Остается понять нужно ли это заказчикам и/или нужно ли это разработчикам в рамках работы парсера. Например, я могу просто сделать свое дополнение к парсеру для работы с webp. Если разработчику парсера это нужно, то я готов к сотрудничеству. Но нужно понимать есть ли спрос. Буквально на днях решал подобный вопрос с другим парсером. Там та же самая проблема с webp. @WEB_COAST , не встречал пока парсера, который не просто закачивает webp, но умеет еще и обработать его. Поскольку ко мне люди часто обращаются с разнообразными проблемами с изображениями, то я уже сталкивался с результатами работы разных парсеров.
-
Все верно, опенкарт не поддерживает webp в качестве входного формата. Нигде изначально не поддерживает, вы не сможете увидеть webp через стандартный менеджер изображения и т.д. И проблема с закаченными webp возникает не только с парсером SimplePars , они возникают с любым парсером. И парсер тут не виноват. Подружить webp как входной формат с опенкарт - это довольно нетривиальная задача, т.к. у многих хостеров даже нет средств для обработки webp. Но я знаю как решить эту задачу, и это будет работоспособным, как минимум, на 99% хост-площадках. Что касается выходного webp, который отдается в браузер, то тут могу гарантировать, что этот webp благодаря модулю Компрессор работает, как минимум, на 99.9% хост-площадках. Могу судить по статистике на более чем 1200 сайтах. Если вопрос работы с webp как входным форматом важен, то я могу подготовить для этого решение. Но данная задача сложнее чем подготовка webp как выходного формата. Нужно понимать насколько востребованным будет такое программное решение для опенкарт. Т.е. будет ли спрос или подобные задачи (переварить webp после парсинга) - это единичные случаи? Если есть хотя бы 10 заказчиков, которым нужно решение по данному вопросу, то сделаю. Без ложной скромности скажу, что съел двух собак на работе с изображениями, знаю все реальные проблемы которые возникают в реальных магазинах, а работа реальных магазинов это совсем не тоже самое, что работа идеального опенкарт в вакууме. В реальности вы встретите JPEG, PNG, сделанные не для webp, а для полиграфии (4 канала вместо 3-х), вы встретите JPEG внутри PNG и наоборот. Все эти странности приводят к искажению цвета, появлению черного фона там, где не ожидали и к прочим непредвиденным неожиданностям. Вот со всей этой чертовщиной Компрессор умеет справляться и приводить картинки в идеальное состояние. Вот вас могут ждать такие сюрпризы (после парсинга, но не только): В общем, если нужно решать задачу со входным webp, то могу посодействовать как в плане индивидуальной разработки (дорого или очень дорого), так и в плане создания универсального решения (модуля). Если нужно такое решение, то прошу писать свои пожелания на странице поддержки: Если будет спрос, то появится и реализация. Пока спроса не было.
-
@Vlad8 , еще есть самое простое решение. Если высокое качество ваших изображений вам не очень важно, то можно в коде его понизить с 90, например, до 80. Можно и до 75, но тут уже появится легкая размытость. Разницы особо не заметите если вы не сильно требовательны к качеству и деталям изображений. Но за счет этого можете выиграть процентов 10% кеша. Это в том случае если у вас совсем совсем заканчивается диск и что-то нужно делать. Но сжатие позволит без потерь самого качества уменьшить вес. И тут эффективность будет намного выше чем просто изменение параметра качества.
-
можно использовать для сжатия jpeg программу mozjpeg, входит в состав модуля Компрессор. Происходит все автоматически. Можно выиграть до 40% в размере кеша. Заодно ускорить отдачу файлов пользователям.
-
https://ru.wikipedia.org/wiki/Список_MIME-типов вероятно, что это:
