sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
от банков нет. ю касса - это не банк, точно также и paypal - это не банк, но это те самые обходные средства, с помощью которых можно (чисто технически) принимать платежи с карт даже физическим лицам без регистрации деятельности, но все это уже остается на совести "бизнесмена". свои услуги, например. свои программы и тп. разумеется, что торговать нельзя если вы перепродаете что-то, т.е. в прямом смысле слова "магазин" нельзя устраивать. -
Вероятно, что вы говорите про интернет эквайринг. Но он доступен для ИП или юридических лиц. Ни один банк не подключит вам интернет-эквайринг на сайт если вы работаете неофициально или официально, но лишь как самозанятый. У вас есть расчетный счет в банке? Поэтому определитесь для начала с этим. Для физ. лиц остаются обходные маневры без использования расчет счета. Итак, сначала решите организационные вопросы, потом технические.
-
а вы и не объяснили толком свою проблему. поэтому никто вам не скажет, что делать. это непонятно. куда, откуда заходите, как смотрите? через фтп-доступ и через фтп-клиент? Через панель управления хостера? Не каждый фтп-клиент умеет корректно видеть символьные ссылки, некоторые их вообще не видят и не понимают. От вас подробностей, похоже, не получить... мой вопрос вы проигнорировали, но говорите "помогите"? Так помощи не просят. Никакой конкретики от вас не получилось добиться. Значит, не очень то вам и нужна помощь? Ни названия папок, ни названия симлинков, ни скриншотов. Ничего нет. Может быть, вы под разными пользователями Linux заходите? Например, для каждого сайта может быть свой пользователь. мы же не знаем никаких подробностей. Почему мы должны гадать? вот это верно. тем более, что вы подробности не желаете разглашать. заплатите специалисту, и вам все сделают. Вас устроит помощь за вознаграждение?
-
каким боком символьные ссылки к опенкарту? Кто-то кого-то вводит в заблуждение? Вы же смотрите просто папки? Или что вы делаете? нормально работают символьные ссылки для image. Почему бы им не работать если это чисто свойство ОС и его файловой системы? И вы выбрали правильный подход. Многие пытаются решит подобную задачу через создание мультимагазина, но при этом получают кучу разного геморроя.
-
можете не включать сжатие в модуле Компрессор. А можете включить - это не имеет значения, т. к. при совместной работе с лайтингом нет проблем.
-
кстати, GD, которая работает в опенкарт по умолчанию, еще и квадратами это делает. Т.е. пикселизация из крупных квадратиков получается. GD иначе не умеет. Это графическая библиотека. Imagick, который есть в модуле Компрессор, хотя бы делает более плавную экстраполяцию без квадратности. но лучше поставить опцию как я выше написал.
-
есть такой вариант: Настраивать можно практически какие угодно параметры для изображений, хоть фон заливки (по умолчанию - белый). Поля можно не добавлять. Для вплывающих изображений это только лишнее. и т.д. и тп.
-
да, два модуля. версия дополнения SEO CMS mod for Image Compressor 1.2.1 работает с актуальной версией seo cms 56.6 и модулем Компрессор версии 2.1.0 и новее. Водяной знак накладывается на изображения в статьях блога в том числе, включая всплывающие изображения в colorbox.
-
вы путаете. Если есть только WEBP, то именно она будет отображаться гуглом в списке проиндексированных. Я вам выше показал пример вполне конкретный. Там гугл ссылается именно на WEBP. Но если есть пара JPEG+WEBP, то гугл на свое усмотрение покажет ссылку на JPEG. Но это никак не означает, что webp не индексируется. Гугл сам всегда ищет пару JPEG+WEBP даже когда в HTML коде есть только WEBP. Вы хотели бы чтобы гугл индексировал совершенно одинаковые изображения, но в разных форматах? Гугл так не делает, для него пара JPEG+WEBP выступает как одно изображение, он делает так называемую склейку JPEG+WEBP если изображение одинаковое.
-
@toolsap , попробуйте разобраться. Не думаю, что дальше имеет смысл обсуждать этот вопрос касательно конкретного сайта в паблике. Все у вас работает как вы сами можете убедиться. Если что-то непонятно, то лучше пишите в личку. Я вам на ваших же конкретных примерах все покажу. Любой человек может заблуждаться, ошибаться и т.д. Поэтому лучше в личке. А в паблике все эти заблуждения и напрасные сомнения насчет WEBP рассмотрели досконально еще года два назад.
-
@toolsap , вероятно, что вы вводите и себя, и меня в заблуждение. Я не вижу проблем с индексацией на вашем сайте. Интересно, а что же я сейчас тогда наблюдаю на вашем сайте? Огромное кол-во проиндексированных изображений вашего сайта. Чтобы не писать здесь никому не интересные кроме вас тексты предлагаю общение перенести в личку. Указывайте в личке сайт. Я пока вижу, что с действительностью ваши слова расходятся.
-
разумеется. нужно время чтобы индексирование произошло заново. Фактически вы в одночасье поменяли все названия изображений, для поисковика это выглядит как полное удаление всех существовавших изображений. Разумеется, что нужно учитывать такой риск когда делаете переименование. Одно дело когда это делается в момент начала наполнения магазина, и совсем другое - когда магазин уже наполнен и изображения проиндексированы. это ваш частный случай. пожалуйста: этой картинки вообще нет в JPEG, она есть только в WEBP, но она проиндексирована гуглом. вот ее код: <img src="https://////image/catalog/webptest/ptichka-800x600.webp" title="Птичка и зеленые листья" alt="Птичка и зеленые листья" /> Эта картинка существует только в WEBP на странице. и она отлично проиндексирована гуглом. Поэтому ваш вывод о том, что гугл не индексирует неверен в корне. Возьмите для примера любой магазин кроме вашего с модулем Компрессор. Нет проблем с индексацией. Да и в вашем нет. вот, например (все проиндексировано, хоть магазин давно на webp, год как минимум): Но отображать в списке проиндексированные webp гугл может в виде кодированного прямо в HTML jpeg-а. не имеет под собой почвы. И яндекс (маркет) и алиэкспресс отображают в webp. Куда уж мощнее? Разбирали еще года два назад эти тонкости. Все отлично индексируется. вы можете, например, сделать важные изображения в png и отключить для этого типа преобразование в webp. Можете вообще отказаться от webp и использовать как альтернативу mozjpeg. Это если опасаетесь. Но, вы делаете неверный подход. Вы выдвинули как истинный постулат, что поисковики не индексируют вообще WEBP. А это ложный постулат. Я вам прямо на конкретных примерах, включая реальный интернет-магазин, показал ошибочность ваших рассуждений.
-
это не так. гугл нормально индексирует webp. Это здесь рассматривалось довольно подробно на конкретных примерах. Вероятно, что у вас другая причина. Но вы также можете установить в настройках модуля опцию: Улучшение индексации поисковиками Webp+JPEG/PNG Это позволяет оставлять ссылки на существующие jpeg, png. и гугл будет видеть их.
-
конечно же, сделает, если подождать.... а, может быть, и не сделает. Да и каким образом это приложение вообще сделает сжатый формат если оно не умеет этого делать? вот этим чудом? @Blade , самое смешное, что советы будут давать люди, которые не сильно разбираются в теме. Спросите их каким образом сжатие исходников автоматически приведет к сжатию (созданию сжатых) изображений в кеше? И как "убрать exif данные" может хоть как-то помочь с уменьшением объема файлов? Все эти метаданные в лучшем случае позволят получить выигрыш в 0.01...1% от общего веса изображений. Это ничтожно. а вы заметили хотя бы в этой теме какую-то объективность и последовательность в этом вопросе? Сами исходники, действительно, можно обработать на ПК в пакетном режиме если причина в их чрезмерно большом геометрическом размере, например, что-то подобное 6000 * 4000. Но это решит только отчасти задачу, т.к. объем кеша изображений в итоге почти всегда превосходит значительно объем исходников.
-
Правильные ссылки URI позволяет делать ocstore или opencart (любых сборок) + модуль Компрессор. Но это относится только к изображениям, которые выводятся из кеша. Чтобы переименовать сами файлы и поправить пути в БД в свое время пользовался софтом одного индийского программиста, под опенкарт 1.5 это работало весьма сносно даже при больших объемах данных. Названия сейчас не вспомню, и не уверен, что это есть под 2.* версию.
-
Еще учитывайте, что для изображений, который выводятся из кеша, нет проблем нанести водяной знак независимо от того будут ли они выводиться как теги <img> или еще как-то. Если же вы желаете нанести водяной знак на изображение, которое выводится как исходник, то тут возможны нюансы. Во-первых, такие изображения не видит сам опенкарт, они никак не обрабатываются самим опенкарт. И если такие изображения (не из кеша опенкарт) отсутствуют в коде как теги <img>, но выводятся через javascript (или еще каким-то хитрым способом), то тут также возможны нюансы, т.е. водяной знак может и не воспроизводиться. еще обратите внимание на это ( RFC3986.): Для картинки из кеша у вас указан валидный URI. А вот для картинки оригинала (исходник) у вас уже - невалидный URI. Невалидные ссылки модуль не будет обрабатывать во избежании возникновения коллизий. Таких ссылок согласно указанному выше стандарту быть не должно. Такие сложные моменты тоже можно учесть, но это уже индивидуально.
-
смотреть страницу с перезагрузкой ctrl+F5 чтобы не мешал старый кеш браузера. и написать мне (на почту или в личку) вместе со ссылкой на страницу и скриншотом , на котором указано нужное изображение.
-
нет. это обозначает именно то, что написано. просто читайте внимательно. нет, конечно же. Наоборот. Четко написано, что было 100%, а стало 43%. Считается суммарный вес уже обработанных изображений. Что именно не понятно в этой фразе? Вы прочитали информацию, которую я выделил красным прямоугольником? И что же здесь удивительного? Обработка (создание webp) по расписанию происходит постепенно согласно расписанию. Соответственно и результат меняется. Это итоговая эффективность. Означает, что удалось добиться суммарно размера сжатого формата в 43% от первоначального 100%. Т.е. сжали более чем вдвое. Действуют настройки основного модуля. На время создания водяного знака рекомендуется на время отключать создание webp чтобы снизить нагрузку, возникающую сразу после очистки кеша изображений.
-
@Dimasscus , все вам гугл говорит правильно. Сравните сколько занимает файл bootstrap.min.css в сжатом виде (он сжимается до 23К из ваших 119К):
-
Без указания адреса сайта бессмысленно гадать. да он не настолько глупый как вам кажется. у вас могут быть не сжаты отдельные файлы. эти файлы могут грузиться со стороны, могут грузиться через прокси/облака, например. это вы HTML проверили, а на нее у вас гугл и не ругается. вы проверяйте файлы, про которые вам гугл говорит не случайно. вот на демо сжатие тоже не включено (это видно из соответствующих столбцов очень наглядно): А теперь смотрите что бывает когда включено сжатие: Передается файл существенно меньшего размера, т.к. он сжатый. "Размер" - это размер файла после РАЗсжатия. опять у вас путаница в голове. что вы показываете? Заголовок запроса, т.е. то, что отправил браузер. А браузер лишь говорит, что умеет читать сжатые файлы. Заголовок ОТВЕТА сервера вы и не показали. Вас должно интересовать это: Смотрите здесь: https://demo.ocstore.com/ тут нет сжатия сейчас. вот заголовки: На демо ocstore сжатия тоже нет. В общем, надо матчасть вам подучить. Надеюсь, что мое старание объяснить максимально понятно не прошло даром.
-
@klaos27 , немного позже сделаю как только разберусь.
-
В общем, описание разработчика elfineder не соответствует действительности в отдельных местах. Разработчик пишет, что параметр содержится в куке, а на самом деле - в локальном хранилище. Т.е. отсюда видно, что функционал реализован иначе. Если посмотреть код JS elfineder, то видно, что храниться может как в локальном хранилище, так и в куке при невозможности локального хранилища. Это отнимает довольно много времени когда пытаешься понять почему не работает в соответствии с инструкцией. Это лишь один момент как пример. И таких моментов полно, т.е. инструкция очень противоречивая. Эта информация не для обычного пользователя. Это мысли вслух программиста.
-
тогда это называется "сменить файл изображения". Просто фраза "отредактировать изображение" воспринимается буквально, т.е. изменить размеры, повернуть и т.д. и т.п. Это тоже можно делать, т.е. редактировать само изображение не меняя названия файла. я не смог это реализовать из-за неадекватного поведения elfinder в случае использования некоторых параметров. Инструкция заявляет одно, но на деле имеем другое. Я не вижу кук для хранения пути к последнему файлу, хоть инструкция уверяет, что последняя папка запоминается в куке. Но самой куки в браузере нет. Если кто-то сможет внести ясность, то тогда будет проще.
-
Здравствуйте. Не смог понять, что именно нужно.
