Я бы порекомендовал написать отдельные функции и потом, где нужно их вызывать:
function isHighDensity(){
return ((window.matchMedia && (window.matchMedia('only screen and (min-resolution: 124dpi), only screen and (min-resolution: 1.2dppx), only screen and (min-resolution: 48.8dpcm)').matches || window.matchMedia('only screen and (-webkit-min-device-pixel-ratio: 1.1), only screen and (-o-min-device-pixel-ratio: 2.4/2), only screen and (min--moz-device-pixel-ratio: 1.1), only screen and (min-device-pixel-ratio: 1.1)').matches)) || (window.devicePixelRatio && window.devicePixelRatio > 1.1));
}
function isRetina(){
return ((window.matchMedia && (window.matchMedia('only screen and (min-resolution: 192dpi), only screen and (min-resolution: 2dppx), only screen and (min-resolution: 75.6dpcm)').matches || window.matchMedia('only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (-o-min-device-pixel-ratio: 2/1), only screen and (min--moz-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2)').matches)) || (window.devicePixelRatio && window.devicePixelRatio >= 2)) && /(iPad|iPhone|iPod)/g.test(navigator.userAgent);
}
if (isRetina()) {
// Делаем, что надо
}
Лично я делаю так:
1) Для не ключевых картинок, вроде логотипа и т.п. Я вместо src картинки прописываю ссылку на какую-нибудь gif, где анимация загрузки. Далее, прописываю аттрибуты data-original и data-retina-original в которых значениями являются ссылки на картинки в обычном разрешении и в ретиновском (при этом для них для pthumb или др. ресайзеров я указываю, чтобы они на выходе качество процентов на 20-30 ниже давали, чем для обычных).
2) Подключаю JS скрипт LazyLoad, который загружает картинки уже после загрузки самой страницы (но он их берет из data-original и не в курсе про вариант для ретины).
3) Чтобы решить проблему прошлого пункта, пишется простой JS скрипт, который выполняется раньше LazyLoad и анализирует экран посетителя сайта и, если нужно, то тупо в data-original устанавливает значение из data-retina-original.
4) А для картинок, вроде Логотипа и т.п. Я первоначально делаю вдвое-втрое большего разрешения картинки.
Ввод ограничений на написание статей на главной- это правильно, т.к. на главной портала не должно быть нытья о помощи в край обнаглевшего клоуна.
Но все таки моё личное мнение, что нужно сделать помимо главной с текущими ограничениями, параллельную ветку, где могут опубликовывать свои статьи, к примеру, люди, чей аккаунт на ресурсе старше полугода, а рейтинг тупо положительный. я не думаю, что кто-то будет терпеть полгода, чтобы ляпнуть на главной вопрос про какую-нибудь ерунду. Либо сделать это ограничение для главной…
Но вернёмся к тому, как сделано сейчас. А сейчас все опять построено на уже надоевших вопросах о рейтингах. В большинстве своём рейтингом, достаточным для публикации на главной, сейчас обладают кто? Разработчики дополнений, которые в основном публикуют инфу о своих дополнениях, при чем по большей степени платных. Вот тут была поднята тема о вопросах новичков (вообще, а не на главной) и т.д. Вот кому из них реально будет интересна подобная лента? Они скорее будут черпать информацию, хоть и не качественную, но специально для них разжеванную и доступную, из каких-нибудь видео уроков на других сайтах посвящённых вордпрессу. А сюда забегать исключительно за помощью к «гуру» и скидывать халтурки на то, что они сами не смогут доделать на сайте, который они взяли за копейки на фриланс бирже типо fl.ru или т.п. Я возможно преувеличиваю, но все таки мне кажется, что такими методами, ресурс может скоро стать интересным только для очень узкого круга людей в плане публикуемой на нем информации.
Просто невероятно усложняем, написанием 3-5 строчек. И то, необходимых лишь для того, чтобы отправкой header с Location корзины, сбросить переданные данные методом POST, иначе при перезагрузке страницы произойдёт ю повторное добавление в корзину.
Да и ещё, в отличии от варианта с переадресацией через js, у этого способа есть два плюса:
1) Универсальность. Без проблем можно сделать, чтобы одни товары АЯКСом добавлялись без перехода в корзину, а другие наоборот с переходом, даже если оба варианта одновременно будут находиться на одной страничке. Поведение будет зависеть только от наличия класса ms2_form у формы.
2) Накосячить сложнее новичкам будет, чтобы это все не работало. Callback — это очень крутая фишка в JavaScript, но без базы знаний одна ошибка и море вопросов.
Разумеется, что легче не стало, поскольку исходя только из:
минишоповский скрипт default.js самостоятельно подключается после первого клика на кнопку «Добавить в корзину»
Что теоритеская база слабовата. Во-первых, минишоповский скрипт подключается при загрузке страницы. Во-вторых, если загуглите ошибку, то убедитесь в том, что она была вызвана тем, что нельзя необъявленному объекту присвоить метод. То есть, указанный вами скрипт выполняется раньше подключения минишоповского скрипта, в котором, собственно этот объект и задан. В-третьих, имеет смысл разобраться в том, что в вашем коде написано. В нем указано то, что в случае Успешного выполнения АЯКС запроса на добавление в корзину, сразу после НЕГО должен будет происходить редирект на строчку корзины.
А теперь внимание вопрос: почему у вас получается так, как получается? То, что во время загрузки окна редирект не назначился ещё не означает то, что и минишоповский скрипт не повесил на кнопку добавления в корзину выполнение своего АЯКС запроса. При первом нажатии именно добавление АЯКСевское и происходит, но вы просто этого не видите. Другой вопрос, что что-то повторно запускает все то, что было повешено на window.load и в том числе и ваш скрипт, который, уже существующему объекту miniShop2, назначает редирект после успешного добавления в корзину, что собственно и происходит во время второго нажатия и, как следствие, повторного добавления в корзину.
Далее, если у формы убрать класс, то переход должен происходить. Вами не был указан атрибут для страницы перехода actions. Другой вопрос в том, что действительно, если перезагружать страницу в корзину будет расти количество товаров. Это лечится написанием плагина
Ну тут все достаточно просто на самом деле. У вас ошибка выползает, потому что код вашего js скрипта внутри HTML находится перед тем местом, где вызывается минишоповский скрипт default.js. Вторая ошибка в том, в скрипте нужно написать document.location.href
Плюс еще есть одна маленькая хитрость: на смартах вы написали, что должны быть самые широкие превью. И это в первую очередь из-за того, что у их экранов значительно более высокая плотность пикселей. Поэтому чаще всего при генерации превью для них занижают сильно качество у превьюшки, т.к. дефекты на ней будет не разглядеть, но главное это то, что их размер будет значительно меньше.
Данный вариант во-первых не всеми браузерами поддерживается. Тот же Гугл тест видит самую большую, т.к. не знаком с новым тэгом
<picture>
и игнорирует его и загружает
<img>
Во-вторых, помимо адаптивности ключевую роль играет еще и плотность пикселей экрана. На тех же Ретина экранах все будет размыто смотреться. Поэтом для дисплеев с повышенной плотностью пикселей, указавают дополнительные имена файлов в атрибуте srcset.
msOptionsPrice2 лично мне абсолютно не нравится. В плане юзабилити ужас. Мне в 2.3 просто безумно нравилась таблица вариаций (именно таблица) + генератор. Было очень удобно, плюс понятно. Но допиливать очень много надо было.
tradeOffers не пользовался, но раз отдельная таблица, то вопрос в реализации и расширении свойств. Была бы хоть схема таблицы + описание того, как расширяемся, то было бы проще, т.к. уже поэтому можно примерно понять, что к чему и решить нужно оно или нет в плане экономии времени на разработку.
А пока что, все таки побаиваюсь брать подобные дополнения из-за переживаний о проблемах с работой другими дополнениями, вроде того же mSearch2.
Сам же предпочитаю вариации и т.п. делать через добавление кастомных таблиц и добавления процессоров и js для опций категорий + плагин автоматизирующий наследование и их сохранение, т.к. расширение колонок стд msProductData тут имеет мало смысла, а опции первоначально на таблицу msProductOptions нацелены и дело в том, чтобы просто переопределяться им табличку и немного логики.
Мне кажется, что ключевое здесь все-таки «Identifier expected.» Единственно, что в голову приходит — это то, что он падает на правилах, вроде @media (min-width: 991px) {}, т.к. @media — это не селектор вида #header или .col-sm-6
А по поводу шопкипера я все таки отдельно написал бы, что ради функционала интернет-магазина, это дополнение не является самым лучшим. По крайне мере третья версия (вторая вообще древняя). С одной стороны, оно очень интересное из-за коробочной поддержки migxDB, а с другой для серьёзных целей, когда необходимо сделать шаг влево или вправо, то:
1) документации ноль. В том числе и не в последнюю очередь по migxDB.
2) мало дополнений, вроде онлайн оплаты и тп
3) автор, там неплохо пиарит свои дополнения, вроде getProducts и тп, но по факту они в ноль проигрывают pdoResources, когда действительно сложная структура у ИМ и работать нужно с несколькими таблицами.
4) реализация вариативных товаров проще застрелиться + документации ноль.
5) туча разного геммора.
Хотя я тут подумал и по идее, все несколько проще можно сделать.
Если я правильно понял, то речь идёт о товаре и его аналогах. Соответственно, есть два решения:
1) В минишопе существует возможность указывать связи товаров. Соответственно, нужно создать одну связь, вроде аналог или две — оригинал/аналог (на случай, если одна оригинал, а остальные копии более дешёвые от других производителей). Далее ничего сложного нет я думаю.
2) Создать отдельную таблицу/колонку с JSON массивом, куда просто добавлять аналоги оригинальной запчасти, но этот способ подходит только для случаев, когда есть оригинал. и его замены от других произв.
В minifyX есть одна настройка, которая как раз таки inline все убирает из HTML. Но с ней нужно аккуратно, т.к. могут возникнуть проблемы с Яндекс метрикой или т.п. плюс динамичные CSS, которые на отдельные странички. Плюс есть настройка, чтобы автоматом подгоняла, если у картинок указаны параметры width и height, то картинки сжимаются, если у них большие размеры.
Я бы порекомендовал написать отдельные функции и потом, где нужно их вызывать:
1) Для не ключевых картинок, вроде логотипа и т.п. Я вместо src картинки прописываю ссылку на какую-нибудь gif, где анимация загрузки. Далее, прописываю аттрибуты data-original и data-retina-original в которых значениями являются ссылки на картинки в обычном разрешении и в ретиновском (при этом для них для pthumb или др. ресайзеров я указываю, чтобы они на выходе качество процентов на 20-30 ниже давали, чем для обычных).
2) Подключаю JS скрипт LazyLoad, который загружает картинки уже после загрузки самой страницы (но он их берет из data-original и не в курсе про вариант для ретины).
3) Чтобы решить проблему прошлого пункта, пишется простой JS скрипт, который выполняется раньше LazyLoad и анализирует экран посетителя сайта и, если нужно, то тупо в data-original устанавливает значение из data-retina-original.
4) А для картинок, вроде Логотипа и т.п. Я первоначально делаю вдвое-втрое большего разрешения картинки.
Но все таки моё личное мнение, что нужно сделать помимо главной с текущими ограничениями, параллельную ветку, где могут опубликовывать свои статьи, к примеру, люди, чей аккаунт на ресурсе старше полугода, а рейтинг тупо положительный. я не думаю, что кто-то будет терпеть полгода, чтобы ляпнуть на главной вопрос про какую-нибудь ерунду. Либо сделать это ограничение для главной…
Но вернёмся к тому, как сделано сейчас. А сейчас все опять построено на уже надоевших вопросах о рейтингах. В большинстве своём рейтингом, достаточным для публикации на главной, сейчас обладают кто? Разработчики дополнений, которые в основном публикуют инфу о своих дополнениях, при чем по большей степени платных. Вот тут была поднята тема о вопросах новичков (вообще, а не на главной) и т.д. Вот кому из них реально будет интересна подобная лента? Они скорее будут черпать информацию, хоть и не качественную, но специально для них разжеванную и доступную, из каких-нибудь видео уроков на других сайтах посвящённых вордпрессу. А сюда забегать исключительно за помощью к «гуру» и скидывать халтурки на то, что они сами не смогут доделать на сайте, который они взяли за копейки на фриланс бирже типо fl.ru или т.п. Я возможно преувеличиваю, но все таки мне кажется, что такими методами, ресурс может скоро стать интересным только для очень узкого круга людей в плане публикуемой на нем информации.
Да и ещё, в отличии от варианта с переадресацией через js, у этого способа есть два плюса:
1) Универсальность. Без проблем можно сделать, чтобы одни товары АЯКСом добавлялись без перехода в корзину, а другие наоборот с переходом, даже если оба варианта одновременно будут находиться на одной страничке. Поведение будет зависеть только от наличия класса ms2_form у формы.
2) Накосячить сложнее новичкам будет, чтобы это все не работало. Callback — это очень крутая фишка в JavaScript, но без базы знаний одна ошибка и море вопросов.
Что теоритеская база слабовата. Во-первых, минишоповский скрипт подключается при загрузке страницы. Во-вторых, если загуглите ошибку, то убедитесь в том, что она была вызвана тем, что нельзя необъявленному объекту присвоить метод. То есть, указанный вами скрипт выполняется раньше подключения минишоповского скрипта, в котором, собственно этот объект и задан. В-третьих, имеет смысл разобраться в том, что в вашем коде написано. В нем указано то, что в случае Успешного выполнения АЯКС запроса на добавление в корзину, сразу после НЕГО должен будет происходить редирект на строчку корзины.
А теперь внимание вопрос: почему у вас получается так, как получается? То, что во время загрузки окна редирект не назначился ещё не означает то, что и минишоповский скрипт не повесил на кнопку добавления в корзину выполнение своего АЯКС запроса. При первом нажатии именно добавление АЯКСевское и происходит, но вы просто этого не видите. Другой вопрос, что что-то повторно запускает все то, что было повешено на window.load и в том числе и ваш скрипт, который, уже существующему объекту miniShop2, назначает редирект после успешного добавления в корзину, что собственно и происходит во время второго нажатия и, как следствие, повторного добавления в корзину.
Ну и последнее JS для браузеров без поддержки http://scottjehl.github.io/picturefill/
tradeOffers не пользовался, но раз отдельная таблица, то вопрос в реализации и расширении свойств. Была бы хоть схема таблицы + описание того, как расширяемся, то было бы проще, т.к. уже поэтому можно примерно понять, что к чему и решить нужно оно или нет в плане экономии времени на разработку.
А пока что, все таки побаиваюсь брать подобные дополнения из-за переживаний о проблемах с работой другими дополнениями, вроде того же mSearch2.
Сам же предпочитаю вариации и т.п. делать через добавление кастомных таблиц и добавления процессоров и js для опций категорий + плагин автоматизирующий наследование и их сохранение, т.к. расширение колонок стд msProductData тут имеет мало смысла, а опции первоначально на таблицу msProductOptions нацелены и дело в том, чтобы просто переопределяться им табличку и немного логики.
Где-то, наверное, косяк со знаками.
1) документации ноль. В том числе и не в последнюю очередь по migxDB.
2) мало дополнений, вроде онлайн оплаты и тп
3) автор, там неплохо пиарит свои дополнения, вроде getProducts и тп, но по факту они в ноль проигрывают pdoResources, когда действительно сложная структура у ИМ и работать нужно с несколькими таблицами.
4) реализация вариативных товаров проще застрелиться + документации ноль.
5) туча разного геммора.
Если я правильно понял, то речь идёт о товаре и его аналогах. Соответственно, есть два решения:
1) В минишопе существует возможность указывать связи товаров. Соответственно, нужно создать одну связь, вроде аналог или две — оригинал/аналог (на случай, если одна оригинал, а остальные копии более дешёвые от других производителей). Далее ничего сложного нет я думаю.
2) Создать отдельную таблицу/колонку с JSON массивом, куда просто добавлять аналоги оригинальной запчасти, но этот способ подходит только для случаев, когда есть оригинал. и его замены от других произв.