a13x
-
Публикаций
336 -
Зарегистрирован
-
Посещение
Весь контент a13x
-
Как был форумным петухом так им и остался! Видимо и помрёшь таким. Тебе 2 человека сказали в чём отличия, но ты самый умный, никогда не признаешь своих ошибок.
-
Форум процветал, если бы тебя тут небыло!
-
Этот форумный петух видимо друг администрации т.к. я месяца 2-3 на этом форуме, он постоянно общается как быдлан и админы просто ему всё спускают на тормозах удаляя посты.
-
Я с вами полностью согласен, но я например не хочу подключать в систему VQMOD т.к. он полюбому будет тормозить систему. Я уверен вы не замеряли скорость работы с ним и без него. Я на опенкарте с ним намучился и ставить его врагу не пожелаю. P.s. если бы ваш плагин работал без VQMOD, бесспорно это было бы лучшее решение!
-
если учесть что, к примеру, главная страница демо симплы генерируется за 0.04 то 0.03 только для css это очень критично думаю у вас какой нить кривой запрос из базы что-то типа FIND_IN_SET будет дольше обрабатываться, чем чтение локального файла и я уже молчу про доп. запросы к css или js, которые по времени также обрабатываются. а в чем тогда плюсы по сравнению с моим методом? Для меня? В простоте, в скорости (не по сравнению с вашим т.к. тут одинаково будет), в удобстве. Для вас не знаю Вы написали свой автомобиль, он вам нравится, я написал свой велосипед и он мне нравится. Я лишь сказ
-
с точки зрения кода там все нормально. посмотрите скорость загрузки вашего файла при живой генерации и отдачу того же файла статично, ну почему то я уверен что разница будет глобальной Время генерации файла: 0.034197092056274 Берем что время отдачи статики = 0, то получаем что разница 0.03 сек. Среднее значение от 0.033 до 0.035 при обновлении по CTRL+F5 (сброс кэша)
-
так вот тут import просто будет ошибкой, а не импортируемыми стилями. Потому что он будет работать только если окажется перед содержимым general.css. И это вполне критично! нельзя импортировать не гугл фонтс не другие css. Тут можно только опять править исходный css путем перемещения кода по файлам или прописями их в php. Да, согласен. Я просто в 99.9% не использую import в ксс поэтому не знал про тонкость что его надо подключать только в начале объявления таблицы стилей.
-
все, вижу, вы вообще не сохраняете результат в файл - все стили собираются в одном запросе. ну это ведь жесть)) Жесть с точки зрения читаемости кода, с точки зрения построения сайта вполне хорошо. Все стили в своих файлах. Можно заморочиться с хэшем, но я не вижу смысла, это совсем мало что изменит. если я правильно понял смысл вашего велосипеда, чисто теоретически, есть вероятность что два пользователя с минимальной задержкой зашли на сайт и один из них получит не целый файл? Не думаю, каждый получит полноценный файл.
-
Почему? у вас этот ксс файл лежит там же откуда и идёт импортирование, имя файла есть, так почему ему не подключиться? Мой скрипт не вмешивается в работу css файла, он только расширяет возможности ксс добавляя переменные. видимо я с чем то перепутал, может с GULPом.
-
потому что это дополнительные запросы на сервер, чем их больше, тем ниже скорость загрузки.
-
1) не вижу ничего спорного, кто как привык работать. 2) "или же он просто не обработается", но подключится. 3) дело не во времени, а в том, что это нужно только когда уже сайт полностью сделан, в моём случае это неважно. время обработки будет одно и тоже. 5) "ну я всегда прописывал стили и js в index.tpl с различными условиями на $module и тд" тут видимо кто как привык работать. я стараюсь в шаблоны не засовывать ничего кроме хтмл, все js и css в отдельные файлы. условия не подгрузку разных скриптов и ксс - от этого отказался сразу т.к. для ускорения работы сайта нужно минимум запросов к серве
-
то есть верстальщику надо лезть в php что бы подключить css? а если на каждой странице подключены свои css и javascript файлы или надо вставить блок стилей или скриптов? Самый дибильный подход к созданию страниц, когда у вас куча css\js файлов и каждый подключается на разных страницах. Учитесь объединять всё это и тогда проблем не будет, это как минимум увеличит скорость загрузки страниц. Какая разница где и что править? Верстальщик что безрукий и не может поправить скрипт? Ну вынеси ему эти файлы в массив в начало файла, а если он совсем обезьяна и это не понимает то не подпускай его в пхп во
-
<?php require_once('api/Settings.php'); //минимизация вывода кода function sanitize_output($buffer) { $buffer = str_replace(array("\r\n", "\r", "\n", "\t", ' ', ' '), '', $buffer); $buffer = str_replace(' ', ' ', $buffer); return $buffer; } $settings = new Settings(); // Ширина $sheme["main_width"] = $settings->main_width; // Основной цвет $sheme["primary_color"] = $settings->primary_color; // Второй цвет $sheme["secondary_color"] = $settings->secondary_color; // Цвет фона $sheme["bg_color"] = $settings->bg_color; //директория для изображений $sheme["images"]
-
Опять же все всё усложняют. Gulp, webpack,... 2 простых пхп скрипта всё решают в разы быстрее чем подключать большие библиотеки и разбираться в них, но видимо многие привыкли усложнять себе жизнь, чем наоборот искать простые пути для решения проблем.
-
На самом деле это всё может сделать несложный скрипт, который на лету прочитает необходимые файлы, заменит переменные если надо и приведет весь код к одной строке убрав комменты. Не знаю, может вебпак и лучше, но там какой то геморой с настройкой и установкой этого вебпака.
-
Иди скрипт напиши автору, чтобы все фотки выводил, реши вопрос через жопу, как ты обычно это делаешь Ой, уже написал? Ну кукарекай тогда дальше. -
Петушок, ты опять закукарекал? Иди в курятник и там кукарекай, 30 летний олень. Значит вы не очистили кэш поэтому ничего не дало. У меня почему то всё работает, хоть я и поменял всего эту переменную, и больше ничего.
-
Он сжимает фотки ровно также как и симпла - меняет кач-во jpg Изображения.
-
Просто ужас. Один не может настроить правильное сжатие изменив 1 цифру, другой советует какую то дичь из страницы с фотками. Вы стоите друг друга
-
А новые товары тоже будете обрабатывать этим скриптом?
-
Самособой А по другому сделать и не получится. Варианта нет в базе, в файле есть только артикул и наименование. Данный артикул может быть использован у разных товаров, значит точную выборку вы не получите никогда => идентификатор товара неизвестен. А для добавление варианта он нужен обязательно. НО, если sku привязано только к одному товару и не может быть кроме как у одного товара, то доп. запрос всё решает. Как в симпле сделано я не в курсе, не проверял и желания копаться нет.
-
Добавил в sql запрос доп условие на проверку имени варианта, проблему решило. Для создания новых вариантов (при отсутствии оного) придётся тащить идентификатор товара в файле импорта.
-
а вы не думали что pagespeed просто нестандартный какой-то сервис? Есть стандарты сжатия изображения для формата jpeg, если pagespeed сделал свой говностандарт и хочет чтобы все ему следовали то это проблема pagespeed. Есть куча нормальных сервисов которые показывают скорость работы сайта, например https://gtmetrix.com/ На pagespped свет клином не сошёлся. Если у вас и там вылезает проблема что изображения можно пережать и сделать лучше, значит вы не следовали моему совету.
-
какой ужас, а в чём проблема сделать сжатие не 100 как это установлено в симпле по дефолту, а своё, например 75? Насколько знаю именно такой коэффициент сжатия понимается под "стандартным", чтобы гугл не выдавал уведомления о том что можно ещё больше сжать изображение. Делается это в классе api/Image
-
Жаль что вы вчера не ответили, методом проб и ошибок тоже пришёл к этому варианту решения