22 июня 2020 в 11:43
Наконец-то созрел сделать для сайта мобильную версию с раскладкой, отличающейся от десктопной. Вроде придумал как оно должно выглядеть, осталась сущая ерунда - реализовать.
Нужно спрятать пяток блоков если ширина вьюпорта меньше определенного порога и наоборот показать пару блоков, спрятанных в десктопной версии. Также нужно слегка менять главный шаблон страницы в зависимости от брейкпойнта.
Прочел вдумчиво документацию к ядерному модулю Breakpoint, которая называется "Working with breakpoints in Drupal", содержит многа букф про то как нарисовать красивый файл breakpoints.yml и ни одной буквы про то, как и где потом с этими брейкпойнтами собственно работать.
В условиях видимости блоков я никакой возможности сослаться на брейкпойнты не вижу.
Что я делаю не так?
Комментарии
Советую глянуть, как сделано в других темах, например adaptivetheme.
Я, конечно, гляну если никаких других вариантов не останется, но неужели действительно нет никакой внятной документации?
Идея не прижилась. В 7ке был context_breakpoint. Работал, нормально без включенного кеширования. Вообще многое в context работает плохо.
Сейчас брейкпойнты добавляются в теме. https://www.youtube.com/watch?v=eW9Pks3sxaA
С блоки можно попытаться работать модулем block_breakpoint.
У меня не получилось. Ошибками при установке сыпет с моей экосистемой.
Да, я уже понял, что на уровне блоков это не работает нормально, наверное нужно на уровне регионов, то есть определить специальные регионы для мобильной версии, и где-то в коде темы подставлять тот или иной шаблон с разными наборами регионов в зависимости от брейкпойнта. Осталось только понять как поймать этот самый брейкпойнт в php-коде темы.
Видео посмотрел - очередное 100500-е видео о том, как составить красивый файл breakpoints.yml, и ни слова о том как же этими брейкпойнтами воспользоваться в теме...
а модуль заработал?
Который? Я пока никакой и не пробовал, ибо не ясно какой мне нужен
https://www.drupal.org/project/block_breakpoint только бекапить систему обязательно перед использованием.
Я глянул - модуль выпущен неделю назад, один пользователь, принцип действия: рендерятся все блоки, а потом ненужные вырезаются джаваскриптом на клиенте. Это не совсем то (а скорее совсем не то) о чем мечталось. И верный указатель что я хочу чего-то не того. Ещё бы кто-нибудь объяснил чего я должен хотеть. Неужели ни у кого нет необходимости вывести совершенно разные хедеры для десктопной и мобильной версии?
Необходимость есть. Решается через @media... display: none;
Другие способы то с кешированием не дружат, то с ресайзом (поворот мобилы).
Всё, что через модуль breakpoint, будет работать в конечном счете на клиенте. Breakpoint это только API чтобы передать информацию о брейкпоинтах допустим из темы в модули. А что потом делать с этим - уже задача других модулей. Например, встроенный модуль responsive_image формирует для картинок вместо![]()
тэг с набором изображений под эти брейкпоинты. В любом случае, breakpoint завязан на
@mediaи решения на его базе будут работать в конечном счете на клиенте. Потому как на бэке информации о размерах экрана нет. В вашем случае, если вы хотите формировать разный ответ для мобил и для десктопа, нужно копать в сторону "mobile detect" модулей, которые по заголовкам User-agent пытаются распознать с какого устройства пришел запрос. Но как по мне, то адаптив лучше, чем разные версии для моб. и десктопа.А есть что-то подобное, что работает на беке? Мне кажется context_breakpoint работает именно на беке.
Там же все равно размеры экрана считываются дажаваскриптом и сохраняются в куки. А потом уже да, на бэке работает контекст. Но это такое решение, компромиссное, я бы его не назвал элегантным. При первом заходе получается кук еще нет, надо грузить страницу, а потом сразу релоадить. И, допустим, при повороте устройства, если будет переход через брейкпоинт, тоже либо игнорировать это, либо перезагружать (в модуле есть такая опция). Но это как-то не юзер-френдли.
А модули, которые работают на распознавании user-agent есть, ищутся например по "mobile detect"
Всем спасибо, вроде улеглось в голове. Видимо придется всё гнать на клиента, а там ненужное прятать. Модули типа mobile detect (их не так мало) посмотрел - они либо вовсе не перенесены на восьмерку, либо используются на восьмерке мизерным количеством сайтов, что опять же говорит что я хочу чего-то не того
Может быть, те блоки, которые можно не показывать на мобильной версии, можно и вовсе не показывать, и разгрузить таким образом интерфейс?
И просто обойтись адаптивной вёрсткой?
рекомендация делать один сайт для всех устройств всё ещё в силе
Ох. На это в двух словах и не ответишь
Во-первых, сайт интенсивно использует большие фото и Гугл-карты, поэтому удобно и в полном объеме его возможностями можно воспользоваться только на большом экране. Работоспособная мобильная версия нужна а) для случаев, когда большого экрана нет под рукой и б), что более важно, для работы с сайтом непосредственно на местности, чтобы легко видеть где находится интересующий объект(ы) относительно пользователя. На десктопной версии на каждой странице отображается "карточка объекта" с текстовой информацией о нем и рядом с ней ЛИБО карта ЛИБО фотогалерея (переключается одним кликом). На мобильном экране нет места для всего этого, поэтому будет отображаться ЛИБО карточка ЛИБО карта ЛИБО фотогалерея (то есть уже три переключаемых "вью мода" а не два).
Далее, хедер десктопного сайта содержит 5 (прописью: пять) стандартных ядерных друпаловских блоков в полном соответствии с друпал-веем: большой логотип, переключатель языков, ссылки для логина/логаута/регистрации, постоянно видное главное меню и поле для поиска. На мобильном экране места для этого нет, поэтому будет узенькая "строка навигации" с маленьким лого, кнопками переключения "вью модов" карточка-карта-галерея и возможно полем для поиска, а все остальное, включая ещё и футер, будет убрано в выскакивающее меню под "тремя черточками".
Мне кажется в моем случае "один сайт для всех устройств" будет означать сайт, которым будет одинаково неудобно пользоваться на любом устройстве. Я вижу, что многие пошли по этому пути, но мне туда не хочется. Хотя очень может быть, что я чего-то не понимаю.
А в чём проблема спрятать хэдер под три чёрточки? Там нужен только кусок js, который будет на мобиле переключать класс открыто/закрыто, а остальное стилями рулится.
Для картинок есть responsive image. С картой нужно что-то делать, но самое очевидное решение - такое же, как с шапкой. Сделать ссылку "подробнее", видимую только на мобиле и по клику на неё переключать класс, который будет показывать/скрывать на мобиле часть полей.
Кроме того, можно подгружать всякие второстепенные блоки асинхронно через ajax. Но тут надо не забывать догружать их ещё и при ресайзе окна.
Спрятать не проблема, но он в своём десктопном виде на мобиле смотрится как седло на корове.
Да с картинками как таковыми нет проблем вообще.
Рендерить и отсылать на клиент, но не показывать гугл-карту - это кидать в печку ассигнации (мои кровные). Карта у меня выводится (и на десктопе в т.ч.) только по явному запросу юзера.
Сделать ВСЮ навигацию по сайту через AJAX у меня в планах, но не получается пока. А "второстепенных" блоков у меня на сайте нет - они все первостепенные, но на разных экранах должны либо выглядеть по-разному (хедер) либо выводиться в разной разметке и с разным алгоритмом переключения между ними (карточка/карта/галерея).
Я думал, по карте проблема только в том, что в маркерах много контента, который не вмещается на мобилу. Скрывать карту целиком я не предлагал.
А навигация через аякс нормально делается только на всяких реактах и вуях.
Нет, с картой проблемы две:
1. Бесплатный порог у гугла стал очень низок, поэтому выходит очень дорого карту показывать всем подряд. Статистика показывает, что карта вообще мало кому нужна, большинство заходят картинки посмотреть. Но это собственно не имеет прямого отношения к мобильной теме, это только к тому, что вывести карту, но не показывать ее стоит очень дорого.
2. На мобильном экране просто не поместится мало-мальски юзабельная карта и что бы то ни было еще кроме строчки навигации. На десктопе/планшете легко выводится вполне юзабельная карта и еще информация об объекте сбоку. Сами по себе маркеры маленькие, и вообще без balloons/infowindows.
Для тотальной навигации через AJAX существует модуль Ajaxify Drupal, который даже почти работает, но возникает проблема с едиными на страницу settings'ами, которые надо как-то ювелирно менять при каждой замене каждого блока, чем данный модуль вообще не озабачивается, а самому мне это пока тяжело. Большим плюсом перевода всей навигации на ajax стала бы возможность инициализировать гугло-карту один раз на сессию, а потом просто динамически всё в ней менять хоть тыщу раз в процесе навигации - это у гугла (в отличие от "дешевых" альтернатив) бесплатно.
Реакты и вуи это круто, но я сейчас не готов взять и всё полностью переписать на них
Весьма спорное утверждение, посмотри, как это сделано на яндекс-картах.
Ну конечно же я смотрел и яндекс-карты и гугл-карты.
Там центром всей парадигмы UI является именно карта. Которая либо занимает весь экран, либо можно выдвинуть снизу на половину экрана "карточку" текущего объекта, при этом от карты остается уже малоюзабельный огрызок, а карточка видна всё равно не вся, либо вытащить карточку на весь экран, тогда ей можно пользоваться, а карта уже не видна. Из карточки (и только из нее) можно посмотреть фото объекта.
У меня в первоначальной версии сайта, когда деревья еще были большими, а гугл-карты де-факто бесплатными, тоже была карта на каждой странице, а сбоку (всегда) небольшая карточка с информацией и одним тамбнейлом фото, кликнув на который можно было открыть лайтбокс и там листать фото, галереи как таковой не было.
Но сейчас всё не так - карту с каждой страницы пришлось убрать, заменив ее по умолчанию на фотогалерею, "карточка" осталась где была.
Ну не лезут на мобильный экран и полная карточка объекта и что бы то ни было еще. Сделать одну бесконечную скроллируемую страницу в модной ныне стилистике рулона туалетной бумаги тоже не получится, ибо и карта, и фотогалерея требуют скроллинга сами по себе. А когда на некоторых сайтах мне предлагают скроллировать карту двумя пальцами, мне хочется предложить предлагающему засунуть свои два пальца себе же в [censored]
карту выгоднее делать скриншотом с активацией по клику
со всех сторон выгоднее
и не исчерпаете вызовы апи и пользователям легче, когда подгрузка условная, а не каждый раз
Порнография вообще выгодное дело, но я так делать не буду
Порнографию тоже можно скриншотом вставлять
Учту для будущих проектов!
На самом деле тоже теперь так делаю. Нет смысла дергать api карт для каждого посетителя, если картой будет пользоваться каждый двадцатый. А еще google pagespeed доволен)
Ох. Есть разница между страничкой "Эбаут ас" с маленькой картой фиксированного размера и пятнадцатью тысячами объектов с картами (помножить на два языка), где карта занимает всю оставшуюся от "карточки объекта" площадь экрана (какого размера должен быть скриншот?). Если моим юзерам нужна карта, они на нее не кликают (это неинтуитивно и бессмысленно), а сразу ее зумают или двигают. И я даже начинать не буду про легальную сторону размещения на своем сайте скриншотов гуглокарт.
И я не дергаю. Я написал чуть выше как сделал я: у каждой страницы есть два "вьюмода" - фотогалерея и карта. По умолчанию всегда показывается галерея, карта показывается только если ткнуть в таб "карта". Текущий вьюмод запоминается в куке, и в URL'е нарочно никак не отражается, чтобы технически невозможно было дать прямой линк на карту.