sitecreator
-
Публікації
6 116 -
З нами
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача sitecreator
-
верно. для сообщений это совершенно неприемлемо. ни собеседник, ни вы сами можете никогда не узнать, что вам отправили еще несколько сообщений. Многие именно читают только на почту. Хорошо, что прислушались к разработчикам. -
в личке я вам сразу же написал, что вы просто ошиблись. впрочем, вы сразу исправили по моей подсказке. нужно быть просто внимательным. верный конфиг показан у меня выше в предыдущем сообщении.
-
резерв резерв
-
все довольно просто. правится в файле config.js. я вам в точности привел пример как внести нужные вам шрифты и размеры шрифтов. \admin\view\javascript\sitecreator\ckeditor этот файл найдете по указанному пути. Если ваш шаблон подключает шрифт Open Sans то вам ничего дополнительно подключать не нужно. Например, дефолтный шаблон подключает этот шрифт сразу и подтягивает его из гугла. конфиг: /** * @license Copyright (c) 2003-2019, CKSource - Frederico Knabben. All rights reserved. * For licensing, see https://ckeditor.com/legal/ckeditor-oss-license */ CKEDITOR.editorConfig = function( config ) { // Define changes to default configuration here. For example: // config.language = 'fr'; // config.uiColor = '#AADC6E'; config.fontSize_sizes = '12/12px;13/13px;16/16px;24/24px;48/48px;'; config.font_names = 'Arial/Arial, Helvetica, sans-serif;' + 'Times New Roman/Times New Roman, Times, serif;' + 'Verdana;'+ 'Open Sans'; };
-
это не проблема. можно подготовить собственный набор кеглей - именно тех, которые будете использовать вы. Тоже самое касается шрифтов. Любой набор. Конфигурацию можете составить на свой вкус. config.fontSize_sizes = '12/12px;13/13px;16/16px;24/24px;48/48px;'; config.font_names = 'Arial/Arial, Helvetica, sans-serif;' + 'Times New Roman/Times New Roman, Times, serif;' + 'Verdana;' + 'Open Sans';
-
Какие вопросы - такой и ответ. Конкретики не было в ваших вопросах. Я вам предложил перейти к конкретике на предмете вполне конкретно интересуещего вас сайта. Можно было бы увидеть текущие минусы вашего сайта и сделать прогноз как изменится оценка гугла после устранения минусов. Я не понял какой абстрактный предмет вы желали обсуждать. нет ясности, что вы понимаете под итоговым результатом, да еще с пруфами. Вас оценка скорости гуглом интересует или в целом продвижение сайта и влияние разных факторов на ранжирование и СЕО в целом? оценку гугла вроде бы вы и сами можете увидеть при желании. Какой из факторов и как влияют на продвижение - тут я не берусь судить, это не моя задача.
-
Здравствуйте. Могу предположить, что вы не вполне понимаете каким образом отображаются нестандартные шрифты на веб-странице. Тут дело не в редакторе, а в том каким образом вы будете поставлять в браузер конечному клиенту нестандартный шрифт. Ведь если у конечного пользователя на компьютере нет определенного шрифта, то он не сможет его отобразить, а значит, что сперва нужно это шрифт загрузить в браузере пользователя. Шрифт, как правило, загружается в блоке <head></head>. Сам редактор это не делает. Поэтому вам нужно самостоятельно заботиться об этом. Поэтому просто " выбирать произвольный шрифт и кегль " будет недостаточно, хоть организовать сам выбор - не проблема.
-
@MichAle , не вижу смысла здесь что-то показывать с примерами. Да и не вполне понятно, что вы хотите увидеть. Смотреть надо конкретный сайт сперва. Если вы не заметили, то мое предложение (услуги по оптимизации) почему-то было удалено без уведомлений и пояснений словно форуму стало не выгодно упоминание вполне тематической услуги. Это же не реклама сторонних услуг? Форум получает свои 20% с этого. Но модераторы удалили. Не знаю, что сочтут еще недопустимым в этой теме.
-
если вы мне, то я не скрываю счетчики от гугла. иначе как же они будет тогда работать?
-
тут самое важное не шаблон, а фотографии готовых блюд. вся красота указанного сайта на них и построена. А в целом он довольно просто построен с минимумом элементов оформления, эти элементы практически сведены к нулю. Поэтому вполне уместно взять дефолтный шаблон и даже из него выкинуть все лишнее. Картинки там замечательные! захотелось всего и сразу!
-
все верно. там код под 2-ю версию Сфинкса. В 3-й много чего изменилось. актуальная сейчас 3.1 версия. Код на опенкарт.ком давно уже не обновлялся. В любом случае под индивидуальные задачи нужен индивидуальный подход и индивидуальное программирование.
-
не вырастет. вам верно заметил @i3bepb не надо так делать. это очень дурной подход. гугл очень не любит когда пользователям показывают одно, а гуглу подсовывают другое. PageSpeed Insights отчасти умеет обходить такие хитрости, как вы предложили. И подход к решению через php - крайне негативным может быть. Если происходит кеширование (есть ускоритель, например), то вы рискуете получить сильно непредсказуемые ситуации. Я довольно много работал над подобными задачами. На основе анализа десятков сайтов могу сказать, что в моем решении не страдает качество сбора информации, т.е. метрика и аналитика работают как надо. Не сразу пришли к наилучшему варианту оптимизации всяких метрик, но в итоге нашли наиболее стабильный вариант. Считает все без проблем, включая конверсии гугла и пр. Самый идеальный вариант пока не придумал, т.к. идеальный - это отсутствие метрик и аналитик вообще, но результат в оценке гугла поднимается.
-
Новая версия 1.3.0 для opencart 3.0 и ocstore 3.0. Улучшена совместимость. установлена актуальная версия elfinder 2.1.56 После обновления не забывайте чистить кеши кроме кеша изображений, разумеется. После обновления перезагрузите страницу админки, где будете использовать True File Manager менеджер через ctrl+F5 чтобы обновился кеш браузера.
-
нет полностью. админка модуля не влияет ни на что. на front он полностью отключен при этом, а для админки он не работает даже во включенном состоянии. Инструкция по установке и настройке Конкретно про ваш сайт можете писать в личку. Есть множество факторов, которые влияют на показатели pagespeed. смотрите на этот счет FAQ FAQ для Компрессора Для комплексной оптимизации есть это:
-
это само собой. но это для настройки темы. но тему же еще и выбрать нужно сперва. для чего то же выбор в настройках магазина сделан?
-
@AlexDW , @Exploits у меня еще такой прикол: используется якобы шаблон по-умолчанию. и другого выбора нет. но на самом деле используется отдельный шаблон - не заказной, а вполне серийный от одного из авторов форума. Не знаю, то ли разработчик шаблона так намудрил, то ли сам заказчик. И смешное дело в том, что редактор тем в админке предлагает мне отредактировать файлы дефолтного шаблона, не ведая, что работают файлы иного шаблона. согласен. дурь полнейшая. Все, что делается для облегчения задач ламерам - это в итоге проблема для специалиста.
-
да, это может объяснить магию. Сегодня снова столкнулся с магией кеширования. на другом сайте. движок тот же ocstore 3 поправил header.twig. Без проблем увидел изменения в конечной странице HTML. поправил footer.twig. А изменений никаких! Чищу все мыслимые кеши, обновляю модификаторы. Ноль изменений в HTML! При этом если переименовать footer.twig в _footer.twig, то изменения отображаются в HTML, т.е. низа страницы нет как и положено. При этом даже в кеше модификаторов footer.twig в правильном виде отображается. Где же кешируется? Что за магия не к месту?
-
точно. причем такой гадости не наблюдал никогда на родном опенкарт. там где-то глубже причина. хоть и это тоже может быть в добавок ко всему. Мне тоже показалось, что js тоже влияет как-то. сам запрос на выполнение модификаторов отправлялся и что-то выполнялось. иначе бы лог файл не менял бы время последнего обновления, хоть и оставался пустым при этом. Раз лог файл обновлял свое время, значит, в него просто писалась пустая строка, т.е. php отрабатывал. Я подозреваю, что кто-то заложил, вероятно, какой-то механизм, который не делает обновление модификаторов если считает, что их не нужно обновлять. жесткой логики такого поведения я не смог проследить.
-
Похоже, что где-то что-то, действительно, кешируется жестким образом. Само собой заработало. Ошибок в консоли браузера не было. Надо будет еще понаблюдать если повторится.
-
Версия ocStore 3.0.2.0 Обновление модификаторов - дело привычное. выглядит это так (исправный вариант) : Неисправный вариант: Файл лога остается нулевым по размеру, меняется лишь время его обновления, и то не всегда. Включение/выключение и обновление модификаторов не приводит к результату. Но иногда срабатывает.
-
Я нашел одну (две...) картинку, которую Компрессор не переводит в WEBP, почему? Какие символы в адресе картинки URI/URL модуль Компрессор воспринимает как верные (валидные), а на какие не реагирует? Это к вопросу а почему модуль картинку Код: Doska заборнаяMPK,281,29.jpg не преобразовал в WEBP? Потому, что символы пробела, запятой и кириллица в принципе не должны быть в URI/URL. Эти символы могут быть в названии файла при использовании их внутри ОС Linux, Windows, но не могут быть в URI/URL согласно стандарту RFC3986. Согласно стандарту кроме латинских букв и цифр могут быть еще только следующие знаки в названии файла, передаваемом в URL : Код: - _ . ~ Все остальные символы URL (вроде той же кириллицы, арабской вязи и т.д. и т.п.) в названии файла (папки) должны быть обязательно закодированы. Процентно-кодированный символ представляет из себя символьный триплет, состоящий из знака "%" и следующих за ним двух шестнадцатеричных чисел. Спецсимволы вроде : & ? и т.п. используются в URI/URL для специальных целей. Вот так должно выглядеть название файла Doska заборнаяMPK,281,29.jpg в URI/URL: Код: Doska%2520%D0%B7%D0%B0%D0%B1%D0%BE%D1%80%D0%BD%D0%B0%D1%8FMPK%252C281%252C29.jpg Т.е., как видите, никаких пробелов, запятых и кириллицы быть не должно в URL. Для картинок, которые обрабатывает движок получается именно такого вида URL. Если у вас это не так, то это значит, что, возможно, один из основополагающих механизмов движка поломан или намеренно изменен неграмотным образом. Или просто используется сторонний код, автор которого не предполагал, что в названии файла может быть помимо латиницы и цифр нечто иное. Вообще, в принципе использование в названиях файлов пробелов, кириллицы и т.д. - дело неблагодарное, т.к. это всегда приводит рано или поздно к некоторым неудобствам или неприятностям. Но в идеальном мире правильно URL-кодированные такие имена не должны приводить к проблемам. Движок Opencart использует для кодирования "неправильных" символов функцию rawurlencode, которая как раз работает по стандарту RFC3986. Откуда тогда берутся на странице невалидные URI/URL (ссылки)? Из-за ошибок, когда ухитряются непонятными способами все же разместить в итоговом коде такие запрещенные стандартом URI/URL. Почему же браузер показывает изображения по таким неверным ссылкам? Потому, что браузеры научились исправлять многие ошибки, причем, даже нередко очень грубые ошибки. Но верно исправить ошибку браузер может не всегда и не везде, да и не любой браузер. ВАЖНО IMPORTANT Модуль Компрессор во избежании непредвиденных ситуаций не пытается обработать изображения со странными URL. Потому, что таких URL в исправном движке Opencart в принципе не должно быть. Конечно, ничто не мешает пользователю руками вбить в код HTML какую-угодно ссылку. Но, как минимум, сам движок при обработке изображений дает для них валидный URL. Движок Opencart всегда работает по стандарту RFC3986. Модуль Компрессор тоже работает в полном соответствии с этим стандартом. Попытка обработки невалидных (не соответствующих стандарту) ссылок на изображения может привести к непредсказуемым коллизиям, глюкам и багам, а потому такая обработка не производится, сами невалидные ссылки не приветствуются, но и не мешают нормальной работе Компрессора, нестандартные ссылки просто игнорируются. Все это сделано ради повышения общего уровня надежности и стабильности работы сайта. ИТОГ. Для внутреннего использования внутри операционной системы название файла может содержать самые разные символы, буквы различных алфавитов и определенные специальные символы. Но для внешнего использования (когда веб-сервер передает информацию в браузер) URL, в котором будут представлены подобные названия файлов, определенным образом кодируется.
-
Я нашел одну (две...) картинку, которую Компрессор не переводит в WEBP, почему? Какие символы в адресе картинки URI/URL модуль Компрессор воспринимает как верные (валидные), а на какие не реагирует? Это к вопросу а почему модуль картинку Код: Doska заборнаяMPK,281,29.jpg не преобразовал в WEBP? Потому, что символы пробела, запятой и кириллица в принципе не должны быть в URI/URL. Эти символы могут быть в названии файла при использовании их внутри ОС Linux, Windows, но не могут быть в URI/URL согласно стандарту RFC3986. Согласно стандарту кроме латинских букв и цифр могут быть еще только следующие знаки в названии файла, передаваемом в URL : Код: - _ . ~ Все остальные символы URL (вроде той же кириллицы, арабской вязи и т.д. и т.п.) в названии файла (папки) должны быть обязательно закодированы. Процентно-кодированный символ представляет из себя символьный триплет, состоящий из знака "%" и следующих за ним двух шестнадцатеричных чисел. Спецсимволы вроде : & ? и т.п. используются в URI/URL для специальных целей. Вот так должно выглядеть название файла Doska заборнаяMPK,281,29.jpg в URI/URL: Код: Doska%2520%D0%B7%D0%B0%D0%B1%D0%BE%D1%80%D0%BD%D0%B0%D1%8FMPK%252C281%252C29.jpg Т.е., как видите, никаких пробелов, запятых и кириллицы быть не должно в URL. Для картинок, которые обрабатывает движок получается именно такого вида URL. Если у вас это не так, то это значит, что, возможно, один из основополагающих механизмов движка поломан или намеренно изменен неграмотным образом. Или просто используется сторонний код, автор которого не предполагал, что в названии файла может быть помимо латиницы и цифр нечто иное. Вообще, в принципе использование в названиях файлов пробелов, кириллицы и т.д. - дело неблагодарное, т.к. это всегда приводит рано или поздно к некоторым неудобствам или неприятностям. Но в идеальном мире правильно URL-кодированные такие имена не должны приводить к проблемам. Движок Opencart использует для кодирования "неправильных" символов функцию rawurlencode, которая как раз работает по стандарту RFC3986. Откуда тогда берутся на странице невалидные URI/URL (ссылки)? Из-за ошибок, когда ухитряются непонятными способами все же разместить в итоговом коде такие запрещенные стандартом URI/URL. Почему же браузер показывает изображения по таким неверным ссылкам? Потому, что браузеры научились исправлять многие ошибки, причем, даже нередко очень грубые ошибки. Но верно исправить ошибку браузер может не всегда и не везде, да и не любой браузер. ВАЖНО IMPORTANT Модуль Компрессор во избежании непредвиденных ситуаций не пытается обработать изображения со странными URL. Потому, что таких URL в исправном движке Opencart в принципе не должно быть. Конечно, ничто не мешает пользователю руками вбить в код HTML какую-угодно ссылку. Но, как минимум, сам движок при обработке изображений дает для них валидный URL. Движок Opencart всегда работает по стандарту RFC3986. Модуль Компрессор тоже работает в полном соответствии с этим стандартом. Попытка обработки невалидных (не соответствующих стандарту) ссылок на изображения может привести к непредсказуемым коллизиям, глюкам и багам, а потому такая обработка не производится, сами невалидные ссылки не приветствуются, но и не мешают нормальной работе Компрессора, нестандартные ссылки просто игнорируются. Все это сделано ради повышения общего уровня надежности и стабильности работы сайта. ИТОГ. Для внутреннего использования внутри операционной системы название файла может содержать самые разные символы, буквы различных алфавитов и определенные специальные символы. Но для внешнего использования (когда веб-сервер передает информацию в браузер) URL, в котором будут представлены подобные названия файлов, определенным образом кодируется.
-
здравствуйте. починить загрузчик ocmod. Это ошибка не модуля, а загрузчика. Или загружать файлы по фтп, например, но с соблюдением всех рекомендаций. В описании все указано. . Инструкция по установке и настройке
-
с 50% опоздали. Но если очень нужно, то могу для вас сделать 20% скидку тут на форуме. напишите в личку, предоставлю вам купон.
-
с темы то не съезжайте. Наврали то вы про фтп. И за линейку не нужно хвататься. простой вопрос. Работа пользователя с файлами в фтп-клиенте FileZilla через протокол SFTP считается безопасной? Да или нет? и что же мешает клиентам использовать хотя бы SFTP (по паролю) или SFTP + крипто-ключи если у них есть такое желание? Пока из всех рассуждений получается, что у пользователя с самого начала заведомо есть альтернативный выбор: использовать обычный ftp или Secure (shell) ftp - SFTP. Кто-то видит логику в рассуждениях @stickpro ? Сам он никак не может построить логичную цепь выводов. Вот клевету он как-то очень даже с легкостью пишет, а за свои слова ответить не может? @stickpro обманывает людей?
