Administrar bloques en un tema receptivo

15

Estoy comenzando un tema receptivo basado en Omega, concentrándome en el diseño móvil al principio.

Hay ciertos bloques que probablemente se considerarán demasiado "pesados" para incluir en el diseño móvil, y otros bloques que deberán introducirse específicamente para ese diseño (menús diluidos, barra de usuario atenuada, etc.).

Podría ocultar fácilmente los bloques no deseados en el diseño móvil con CSS, e incluir los bloques específicos para dispositivos móviles en el diseño predeterminado y ocultarlos (por lo que solo se muestran para dispositivos móviles), pero eso parece una forma bastante retrasada de pensar eso. Si no se muestran los bloques, la sobrecarga adicional en la que incurrirían sería realmente inaceptable (especialmente teniendo en cuenta la cantidad de consultas de db adicionales que agregaría el contenido en bloques ocultos).

Estoy pensando que debe haber una manera limpia y agradable de interceptar el proceso de toma de decisiones de bloque al principio de la construcción de la página, y excluir / incluir bloques basados en alguna detección de sistema operativo, pero estoy dejando en blanco cómo podría ser eso posible.

También voy a agregar el hecho de que Varnish se está ejecutando frente a este sitio, lo que debería hacer las cosas más divertidas :)

¿Existen módulos / estrategias conocidas que puedan ayudar con esto?

Debo agregar que usar el módulo Context no es una opción, ya que el sitio ya está desarrollado, y moverlo a Context sería una tarea enorme en este momento.

blocks theming

— Clive
fuente

44

Sin lugar a dudas, habría usado paneles y un complemento de acceso de agente de usuario relevante. El contexto probablemente podría hacer lo mismo, pero como ya dijiste, esa no es una opción. Por supuesto, existe la horrible posibilidad de evaluar la visibilidad del bloque, pero ... Por otro lado, con Varnish al frente, las consultas de db adicionales que realiza este bloque, ¿podrían no ser un gran problema?

— Letharion

@Letharion Sí, ese es el pensamiento, deja que Varnish elimine la tensión. Sin embargo, el sitio tiene unos cientos de miles de usuarios activos, y Varnish solo se involucra para el tráfico anónimo. Pronto jugaremos con ESI, pero aun así puedo pensar en problemas ... desde el punto de vista de SEO, el marcado / menús adicionales serían pesados y potencialmente confusos, sin mencionar el peso adicional (innecesario) en las páginas para usuarios móviles. ¡Es una pregunta difícil!

— Clive

1

¿Quizás agregar un controlador de bloque más inteligente (Paneles / Contexto / otro) a las páginas más pesadas, para que pueda obtener alguna ganancia sin necesidad de rehacer todo el sitio?

— Letharion

1

No estoy de acuerdo con que la pregunta sea estúpida o que cambie totalmente el juego. El barniz se puede configurar para manejar el problema de manera agradable, simplemente no sabrá cómo hacerlo con una configuración lista para usar.

— Letharion

2

@Clive: hay un viejo dicho: "No existe una pregunta estúpida, ¡solo una respuesta estúpida!" ;-)

— AjitS

4

interceptar el proceso de toma de decisiones de bloque al principio de la construcción de la página y excluir / incluir bloques basados en alguna detección de os

Varnish se está ejecutando frente a este sitio

Como ya se señaló en los comentarios, esto requiere que configure el barniz para que no se almacene en caché solo en la URL de solicitud, sino que también varíe en el agente de usuario. Hay un ejemplo relevante en el wiki de barniz, VCLExampleNormalizeUserAgent .

Una vez que la solicitud realmente llega al sitio, debe determinar qué bloques mostrar y no mostrar. Consideraría que no es menos que un desastre hacer esto con eval , por lo que las opciones más comunes que quedan son Context y Panels .

Con el sitio ya construido. Rehacer todas las páginas / colocación de bloques con cualquiera de los módulos probablemente no sea una opción, pero con un generador de perfiles, y aplicando 80-20 , podría ser posible obtener ganancias significativas de rendimiento al rehacer solo páginas específicas.

— Letharion
fuente

Eso es realmente muy interesante, gracias. El sitio en cuestión es el Panteón, así que no creo que configura barniz es una opción, pero esto se ha convertido en una forma más general '¿cómo se hacer esto teóricamente' pregunta por lo que este tipo de ahora es muy útil

— Clive

Pantheon le permite configurar cookies STYXKEY (hacia el final de helpdesk.getpantheon.com/customer/portal/articles/425726 ), y le permiten segmentar lo que Varnish almacena en caché / sirve para los usuarios anon.

— Jimajamma

Totalmente espaciado con esta recompensa, me gustaría haberla dividido entre ambas respuestas, pero la vida no es de ese tipo. El sistema eligió Chapabu's para dar la recompensa, por lo que la pequeña marca verde va a tu amigo :)

— Clive

10

No puedo entrar en muchos detalles, ya que no he usado ninguno de los módulos durante años (construyo todos mis sitios con Context desde el principio y no he respondido a algo que no he construido para un mientras que no he tenido este problema antes), pero creo que deberías poder armar algo con Mobile Tools and Spaces.

Espacios

Spaces es un módulo API destinado a hacer que las opciones de configuración generalmente estén disponibles solo a nivel de todo el sitio para ser configurables y anuladas por "espacios" individuales en un sitio de Drupal. Se ha descrito como:

Una forma de hacer que un sitio de Drupal actúe como varios sitios

Una forma de proporcionar grupos orgánicos o páginas de usuario mucho más configurables y con funciones completas

Una API generalizada para la configuración contextual.

Herramientas móviles

El módulo Mobile Tools proporciona a los desarrolladores de Drupal algunas herramientas para ayudarlo a realizar ajustes en su sitio en función del dispositivo del visitante.

Sin embargo, la página del proyecto para MT dice que no está lista para la producción, lo que podría ser un problema, depende de cuándo se actualizó por última vez, ya que la última confirmación fue este mes.

*EDITAR

¡OLVIDÉ COMPLETAMENTE DE ESTOS!

Browscap

Browscap proporciona una versión mejorada de la función get_browser () de PHP.

Bloque Browscap

Browscap Block agrega opciones de visibilidad para bloquear los ajustes de configuración para permitirle ocultar o mostrar bloques en dispositivos móviles.

Browscap depende de la configuración de su servidor, pero si puede usarlo, entonces el segundo módulo le brinda configuraciones de visibilidad adicionales para cada bloque en la página de edición de bloques.

ingrese la descripción de la imagen aquí

— Chapabu
fuente

Browscap Block parece realmente prometedor gracias, lo comprobaré en los próximos días y te lo haré saber

— Clive

¡Uy, esto se me escapó por completo, perdón por la media recompensa!

— Clive

0

puede usar un soporte de jQuery cross browser para obtener la resolución de pantalla:

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

Agregue un script PHP simple para mostrar la configuración del bloque relacionado.

— monymirza
fuente

Gracias, pero ¿eso no significaría convertir todo el sitio para usar AJAX para bloques? Estoy buscando hacer este lado del servidor si es posible

— Clive

0

Podría usar Mobile Detect Block, pero actualmente estoy buscando una solución que funcione con el ancho de la ventana y AdaptiveThemelas consultas de medios del módulo Breakpoints para no duplicar ese código y pesar la descarga del usuario final más de lo que es. También tuve resultados mixtos con Mobile Detect que no se detectó en un dispositivo con el que lo probé, lo que lo hace bastante inútil como Browscap si no puede proporcionar resultados confiables.

Algunas discusiones tienen a algunas personas que desean alejarse de Browscap por una razón u otra, de ahí el cambio a Mobile Detect .

— decaimiento
fuente