Gérer les blocs dans un thème réactif

15

Je commence juste un thème réactif basé sur Omega, en me concentrant sur la mise en page mobile au début.

Il y a certains blocs qui seront probablement jugés trop `` lourds '' pour être inclus dans la disposition mobile, et d'autres blocs devront être introduits spécifiquement pour cette disposition (menus édulcorés, barre utilisateur atténuée, etc.).

Je pourrais facilement masquer les blocs indésirables sur la mise en page mobile avec CSS, et inclure les blocs spécifiques aux mobiles sur la mise en page par défaut et masquer ceux-ci (ils ne sont donc affichés que pour les mobiles), mais cela semble être une façon de penser à l'envers il. Si les blocs ne sont pas affichés, la surcharge supplémentaire qu'ils encourent serait vraiment inacceptable (surtout compte tenu du nombre de requêtes de base de données supplémentaires que le contenu des blocs masqués ajouterait).

Je pense qu'il doit y avoir un bon moyen propre d'intercepter le processus de prise de décision de bloc au début de la création de la page, et d'exclure / inclure des blocs basés sur une certaine détection d'OS, mais je dessine un blanc sur la façon dont cela pourrait être possible.

Je vais aussi ajouter le fait que Varnish tourne devant ce site, ce qui devrait rendre les choses plus amusantes :)

Existe-t-il des modules / stratégies connues qui peuvent vous aider?

Je dois ajouter que l'utilisation du module Context n'est pas une option car le site est déjà à part entière, et le déplacer dans Context serait une entreprise énorme à ce stade.

Clive
la source
4
J'aurais sans aucun doute utilisé des panneaux et un plugin d'accès utilisateur-agent approprié. Le contexte pourrait probablement faire de même, mais comme vous l'avez déjà dit, ce n'est pas une option. Il y a bien sûr l'horrible possibilité d'évaluation: la visibilité du bloc, mais ... D'un autre côté, avec Varnish à l'avant, les requêtes db supplémentaires que ce bloc effectue, pourraient ne pas être un gros problème?
Letharion
@Letharion Oui, c'est la pensée, laissez Varnish supprimer la tension. Le site compte cependant quelques centaines de milliers d'utilisateurs actifs, et Varnish ne s'implique que pour le trafic anonyme. Nous jouerons avec ESI assez bientôt, mais même dans ce cas, je peux penser à des problèmes ... d'un point de vue SEO, le balisage / menus supplémentaires serait lourd et potentiellement déroutant, sans parler du poids supplémentaire (inutile) sur les pages de utilisateurs mobiles. C'est difficile!
Clive
1
Peut-être ajouter un gestionnaire de blocs plus intelligent (Panneaux / Contexte / autre) aux pages les plus lourdes, afin que vous puissiez en tirer profit sans avoir à refaire tout le site?
Letharion
1
Je ne suis pas d'accord que cela rend la question stupide, ou un changeur de jeu total. Le vernis peut être configuré pour bien gérer le problème, il ne saura tout simplement pas comment avec une configuration prête à l'emploi.
Letharion
2
@Clive: il y a un vieux dicton: "Il n'y a pas de question stupide, seulement une réponse stupide!" ;-)
AjitS

Réponses:

4

intercepter le processus de prise de décision de bloc au début de la création de la page, et exclure / inclure des blocs basés sur une certaine détection d'OS

Le vernis passe devant ce site

Comme indiqué dans les commentaires déjà, cela vous oblige à configurer le vernis pour ne pas mettre en cache uniquement sur l'URL de la demande, mais aussi varier sur l'agent utilisateur. Il existe un exemple pertinent dans le wiki de vernis, VCLExampleNormalizeUserAgent .

Une fois que la demande fait n'atteint le site, vous devez déterminer quels blocs pour montrer et ne pas montrer. Je ne considérerais pas moins comme un désastre de le faire avec eval , donc les options les plus courantes qui restent alors sont le contexte et les panneaux .

Avec le site déjà construit. refaire toutes les pages / placement de bloc avec l'un ou l'autre module n'est probablement pas une option, mais avec un profileur, et en appliquant 80-20 , il pourrait être possible de réaliser des gains de performances significatifs en refaisant des pages spécifiques uniquement.

Létharion
la source
C'est vraiment très intéressant, merci. Le site en question est sur Panthéon, donc je ne pense pas que la configuration de Varnish soit une option, mais cela s'est transformé en une question de type plus générale "comment faire théoriquement" maintenant donc c'est très utile
Clive
Pantheon vous permet de configurer des cookies STYXKEY (vers la fin du helpdesk.getpantheon.com/customer/portal/articles/425726 ), et ils vous permettent de segmenter ce que Varnish met en cache / sert pour les utilisateurs anon.
Jimajamma
Totalement espacé sur cette prime, j'aurais aimé le partager entre les deux réponses mais la vie n'est pas ce genre. Le système a choisi Chapabu pour donner la prime, donc la petite coche verte va à votre pote :)
Clive
10

Je ne peux pas entrer dans beaucoup de détails, car je n'ai utilisé aucun des modules depuis des lustres (je crée tous mes sites avec Context dès le départ et je n'ai pas pris en compte quelque chose que je n'ai pas construit pour un alors, je n'ai pas eu ce problème auparavant), mais je pense que vous devriez être capable de mettre quelque chose ensemble avec Mobile Tools and Spaces.

Les espaces

Spaces est un module API destiné à rendre les options de configuration généralement disponibles uniquement au niveau du site pour être configurables et remplacées par des "espaces" individuels sur un site Drupal. Il a été décrit comme:

  • Un moyen de faire agir un site Drupal comme plusieurs sites
  • Un moyen de fournir des groupes organiques ou des pages d'accueil d'utilisateurs bien plus configurables et complètes
  • Une API généralisée pour la configuration contextuelle

Outils mobiles

Le module Mobile Tools fournit aux développeurs Drupal des outils pour aider à faire des ajustements à votre site en fonction de l'appareil du visiteur.

La page du projet pour MT indique cependant qu'il n'est pas prêt pour la production, ce qui pourrait être un problème - cela dépend de la dernière mise à jour, car le dernier commit était ce mois-ci.

*ÉDITER

J'AI OUBLIÉ COMPLÈTEMENT CELLES-CI!

Browscap

Browscap fournit une version améliorée de la fonction get_browser () de PHP.

Bloc Browscap

Browscap Block ajoute des options de visibilité pour bloquer les paramètres de configuration pour vous permettre de masquer ou d'afficher les blocs dans les appareils mobiles.

Browscap dépend de la configuration de votre serveur, mais si vous pouvez l'utiliser, le deuxième module vous donne des paramètres de visibilité supplémentaires pour chaque bloc sur la page d'édition de bloc.

entrez la description de l'image ici

Chapabu
la source
Browscap Block a l'air très prometteur merci, je vais le vérifier dans les prochains jours et je vous le ferai savoir
Clive
Oups, cela m'a totalement échappé, désolé pour la demi-prime!
Clive
0

vous pouvez utiliser un support de navigateur croisé jQuery pour obtenir la résolution d'écran:

var browserWidth  = $(window).width();
var browserHeight = $(window).height();

Ajoutez un script PHP simple pour afficher les paramètres du bloc associé.

monymirza
la source
Merci, mais cela ne signifierait-il pas convertir tout le site pour utiliser AJAX pour les blocs? Je cherche à faire cela côté serveur si possible
Clive
0

Vous pouvez utiliser Mobile Detect Block, mais je suis actuellement à la recherche d'une solution qui fonctionne avec la largeur de la fenêtre et AdaptiveThemeles requêtes média du module Breakpoints afin de ne pas dupliquer ce code et alourdir le téléchargement de l'utilisateur final plus qu'il ne l'est. J'ai également eu des résultats mitigés avec Mobile Detect ne détectant pas sur un appareil avec lequel je l'ai testé, ce qui le rend plutôt inutile comme Browscap s'il ne peut pas fournir des résultats fiables.

Certaines discussions ont amené certaines personnes à vouloir s'éloigner de Browscap pour une raison ou une autre, d'où le passage à Mobile Detect .

deanflory
la source