Yoda

Это может быть все что угодно. От вируса на сайте до какого-то системного файла с BOM. Откройте исходный код страницы и покажите скрин, что у вас там.

Да вы совершено правильно размышляете, но есть маленький нюанс, объем данных, которые вы сэкономите сократив пару десятков строк HTML, с включенным сжатием - это чистой воды экономия на спичках. Если заморачиваться на подобном уровне оптимизацией, то имеет смысл совсем отказаться от бутстрапа, так как он может весить лишних 400-500кб, и написать свой микрофреймворк адаптивных элементов, либо иные @media стили. Если вы паритесь касательно того что в display:none никто не мешает использовать LazyLoad. И еще есть интересный момент, для mobile и для desktop полезноотдавать разного размера изображения. Но реализация через чур громоздка в силу нескольких моментов. Во первых надо пережать сразу изображения в кеш в несколько размеров, во вторых в верстке или отказаться от <img> и выводить изображения через css {background-img} формируя для каждого товара в списке свой айди и после этого генерируя уникальный контейнер с @media стилями под разные разрешения. Либо используя <img>, возвращаемся к lazy и грузим файлы через js, в зависимости от разрешения.

Детектить устройства, нужно. Но не для того чтоб раздавать разный контент. Для этого действительно @media с головой. А вот изменять обработку событий, без детекта именно типа устройства (touch) не получится. А всякие свайпы, дабл тапы могут быть очень полезными в некоторых случаях.

Шо я имею вам сказать. Увапервых. Гугля рекомендует делать адаптивную версию а не подомен. Увавтарых ковыряние двух контейнеров для выдачи контента - сложнее чем одного. Утретих, нынешние браузеры в смартах по полной поддерживают все js приблуды, а 3g 4g коннект, как выше сказал Чучхэ, давно сравняли по толщине мобайл и декстоп. Такшта решение малость из ******* отстоя 80х... Ну и на сладкое Лебедев раз и Лебедев два. Такшта Mobile First - ваше все!

Чтобы особо не напрягаться - есть fix pro пользуйтесь на здоровье.

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

Скайп - kudriana . Очень дорого относительно средней температуры по больнице, но очень круто! Филологическое образование + полное погружение в специфику, а не тупой копипаст.

Вот мне интересно другое "узкоспециализированное якобы агенство, из полутора студентов" задает вопрос в чем проблема в широкой специализации. В школе тему реферата дали "чем фрилансеры отличаются от профильных специалистов" ?

Опыт сын ошибок трудных. Вы же зубы не ходите лечить к терапевту?

Простите, не очень мне интересно с вами дискутировать про мое отношение к людям. А тем более про ваши распальцовки. И еще меньше нуждаюсь в ваших извинениях.

Вы бы читать сначала научились, читали внимательно, и после этого с вами можно будет о чем-то говорить.

У меня есть желание делать магазины. И не задавать глупыец вопросы.

Не слушайте "специалистов" пишите в личку. Все сделаем в лучшкм виде. Более 500 реализоаванных проектов.

Знаете, есть всякие меньшинства, они тоже требуют прав! Стоит задуматься!

Это все мне напоминает анекдот, когда охотник стрелял в берлогу, потом чувствовал лапу медведя на плече и враскоряку уходил без добычи... Так вот собственно вопрос: мужик, тебе магазин надо сделать, или ты охотник? А по факту про конфиг отвечу: 1 - Использовать $_SERVER - это Bad Coding Practice 2 - Все линукс-хостинги, да не все, а еще есть Win-хостинги. А еще есть денверы и всякие другие локалки. 3 - А что делать в ситуации, если у меня целый сервер под проект. И я не хочу в хомяке держать кеши и картинки, а у меня для них отдельный том примаунчен? 4 - Какая к монахам разница универсальный конфиг или не очень, если при чистой установке инсталлятор все делает за вас?

ИМХО БРЕД! 1. Почта может быть любой. Но она должна физически существовать. Так как почтовые сервера при получении письма с адресата, шлют обратную отбивку на проверку, есть ли такой почтовый ящик. 2. SMPT - это зло, так как отправляю почту через SMTP, вы оставляете логин пароль в почту в админке магазина, и злоумышленник получив доступ в магазин получает еще в подарочек доступ к почте. Так что намного правильнее и безопаснее. Настроить сервер и добавить в DNS домена необходимые политики и слать почту через MAIL, а не через SMTP. 3. Кроме DKIM, еще необходимы SPF DMARK и PTR записи. Существуют два варианта оптравки. Либо средствами PHP прямо с сервера, либо через посредника (SMTP) сервер. Почему не стоит использовать второй вариант я написал выше. В любом случае, даже при использовании почты Яндекс для домена, необходимо обязательно добавить SPF политику, в которой вы указываете, что Яндексу разрешено отправлять почту от имени вашего домена. И не отправлять почту с несуществующих адресов. Если же вы отправляете почту средствами mail, то разобраться в проблеме поможет mail-tester.com, достаточно зарегистрировать нового пользователя на временный имейл, которы предоставляет этот сервер, обновить страницу и получить полный отчет по всем проблемам, связанным с достакой почты от присутсвия в спам листах, до специфики восприятия ваших писем встроенными антиспам системами. Но настройка железобетонной почты на VPS - это тема на целую статью, так как есть масса нюансов, которые надо учитывать. Так к примеру, по умолчанию php будет слать письма как [email protected], или [email protected], и если вы создали ящик info@, но не создали webmaster@, с большой вероятностью, вы будете валится в спам. Также не лишним будет регистрация в Post-мастерах основных почтовых сервисов, вот список некоторых из них: Постмастер Mail.ru: postmaster.mail.ru/ Почтовый офис Яндекса: postoffice.yandex.ru/ Постмастер Gmail: postmaster.google.com/

Ну вот видите, не такой я злой и страшный, а иногда даже могу что дельное подсказать. И даже вы оказались на моей темной стороне. :ugeek: Дальше если развивать тему. Почему файловый кеш для атомарных контейнеров медленне, чем запросы в грамотно настроенную базу. 1. Mysql - это хранилище с поддержкой быстрой выборки по ключам. Уже на 3-4-5к файлов в папке будут тормоза с поиском файла, и механизм индексирования к файловой системе не особо применим. 2. Правильно сконфигурированный сервер базы, позволяет держать все таблицы в памяти, обеспечивая все таки более быстрый доступ к данным, чем даже обращение к файлу на SSD диске. 3. Очередь обращения к данным в памяти практически не влияет на скорость доступа, а вот очередь обращения к файлам опять же на том же ssd, никуда не денешь. Если говорить о реализации тяжелого проекта, в котором надо реализовать подобную задачу, и говорить о жестокой реализации. То нужно денормализовать структуру. Создать отдельный справочник (category_id, data_subcategory) обновляемый при любых изменениях в категориях. И использовать его, вместо постоянных запросов с JOIN. Равно как и для getTotalProduct, можно сделать RT-индекс и подвесить все в тот же сфинкс. Вы забыли три страшных слова - шардинг, партицирование и репликация. Но боюсь, что ответ все равно будет из серии "а в моей песочнице, все равно ведерко синее".

Правил тут недавно магазин, в котором стоял модуль оплаты сбером. В модуле есть инструкция по оплате, которая приходит клиенту с отчетом о продаже. Вобщем суть какая. Инстркция эта заполнена в модуле HTML полем. В метод addOrderHistory эти данные приходят как plain-text в переменной $comment, и соответсвенно идут в письмо как листинг HTML,а не как HTML-сущности. Правится легко. В модель order После public function addOrderHistory($order_id, $order_status_id, $comment = '', $notify = false, $override = false) { Добавляем $comment = html_entity_decode($comment); И получаем красивый HTML в письме. Вот собственно вопрос. Может Даниэлю пулл-реквест запулить, или нафиг не надо ?

Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему.

Вы не за меня радуйтесь - а за себя грустите. Потому как тот механизм который предлагаете вы, база отрабатывает быстрее чем кеш! И в нем смысла нет. Еще раз повторяю. Заканчивайте вредные советы!

Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация.

30 Скачать / Купить дополнение СуперТаб http://ocshop.info/supertab.png Добавил Yoda Добавлено 14.11.2016 Категория Прочее Системные требования Метод активации Без активации Ioncube Loader Нет ocStore 1.5.5.1.2 OpenCart.Pro, ocShop OcShop 1.5.6.4.х Обращение к серверу разработчика Нет