Gestire i blocchi in un tema reattivo


15

Sto solo iniziando un tema reattivo basato su Omega, concentrandomi inizialmente sul layout mobile.

Ci sono alcuni blocchi che probabilmente saranno considerati troppo "pesanti" per essere inclusi nel layout mobile, e altri blocchi che dovranno essere introdotti specificamente per quel layout (menu annacquati, barra degli utenti attenuata, ecc.).

Potrei facilmente nascondere i blocchi indesiderati sul layout mobile con CSS, e includere i blocchi specifici per dispositivi mobili sul layout predefinito e nasconderli (quindi sono mostrati solo per dispositivi mobili), ma sembra un modo piuttosto retroattivo di pensare esso. Se i blocchi non vengono visualizzati, l'overhead aggiuntivo che incorre sarebbe davvero inaccettabile (soprattutto considerando il numero di query db extra che il contenuto nei blocchi nascosti aggiungerebbe).

Sto pensando che ci debba essere un modo semplice e pulito per intercettare il processo decisionale dei blocchi nelle prime fasi della creazione della pagina ed escludere / includere i blocchi in base al rilevamento di alcuni sistemi operativi, ma sto disegnando un vuoto su come potrebbe essere possibile.

Ho anche intenzione di aggiungere che Varnish è in esecuzione di fronte a questo sito, il che dovrebbe rendere le cose più divertenti :)

Ci sono moduli / strategie conosciute là fuori che possono aiutare in questo?

Vorrei aggiungere che l'utilizzo del modulo Context non è un'opzione in quanto il sito è già completo, e spostarlo in Context sarebbe un'impresa enorme a questo punto.


4
Senza dubbio avrei usato i pannelli e un plug-in di accesso user-agent rilevante. Il contesto potrebbe probabilmente fare lo stesso, ma come hai già detto, non è un'opzione. Ovviamente c'è la terribile possibilità di eval: ing la visibilità del blocco, ma ... D'altra parte, con Varnish in primo piano, le query db extra che questi blocchi eseguono, potrebbero non essere un grosso problema?
Letharion,

@Letharion Sì, questo è il pensiero, lascia che Varnish rimuova la tensione. Il sito ha alcune centinaia di migliaia di utenti attivi e Varnish viene coinvolto solo per il traffico anonimo. Giocheremo con ESI abbastanza presto ma anche allora posso pensare a problemi ... dal punto di vista SEO il markup / menu extra sarebbe pesante e potenzialmente confuso, per non parlare del peso extra (non necessario) sulle pagine per utenti mobili. È difficile!
Clive

1
Forse aggiungi un gestore di blocchi più intelligente (pannelli / contesto / altro) alle pagine più pesanti, in modo da poter ottenere qualche guadagno da esso senza la necessità di ripetere l'intero sito?
Letharion,

1
Non sono d'accordo sul fatto che renda la domanda stupida, o un cambio di gioco totale. Varnish può essere configurato per gestire bene il problema, semplicemente non saprà come con una configurazione pronta all'uso.
Letharion,

2
@Clive: c'è un vecchio detto: "Non esiste una domanda stupida, solo una risposta stupida!" ;-)
AjitS,

Risposte:


4

intercettare il processo decisionale dei blocchi nelle fasi iniziali della creazione della pagina ed escludere / includere blocchi in base al rilevamento del sistema operativo

Varnish è in esecuzione di fronte a questo sito

Come già notato nei commenti, questo richiede di configurare la vernice in modo da non memorizzare nella cache solo l'URL della richiesta, ma anche variare in base all'utente-agente. C'è un esempio rilevante nel wiki di vernice, VCLExampleNormalizeUserAgent .

Una volta che la richiesta in realtà non ha colpito il sito, è necessario determinare quali blocchi da mostrare e non mostrare. Considererei non meno di un disastro farlo con eval , quindi le opzioni più comuni rimaste sono Contesto e Pannelli .

Con il sito già costruito. ripetere tutte le pagine / posizionare i blocchi con entrambi i moduli non è probabilmente un'opzione, ma con un profiler e applicando 80-20 , potrebbe essere possibile ottenere significativi miglioramenti delle prestazioni rifacendo solo pagine specifiche.


Questo è davvero molto interessante grazie. Il sito in questione si trova sul Pantheon, quindi non penso che configurare Varnish sia un'opzione, ma questo si è trasformato in una domanda più generale di tipo "come si farebbe teoricamente" ora, quindi è molto utile
Clive

Pantheon ti consente di impostare i cookie STYXKEY (verso la fine di helpdesk.getpantheon.com/customer/portal/articles/425726 ) e ti consente di segmentare quali cache / servizi di Varnish servono per gli utenti.
Jimajamma,

Completamente spaziato su questa generosità, vorrei averlo diviso tra entrambe le risposte, ma la vita non è quel tipo. Il sistema ha scelto Chapabu per dare la generosità, quindi il piccolo segno di spunta verde va a te amico :)
Clive

10

Non posso entrare in molti dettagli, dal momento che non ho usato nessuno dei due moduli per anni (ho costruito tutti i miei siti con il contesto fin dall'inizio e non ho acquisito risposta su qualcosa che non ho costruito per un mentre, quindi non ho avuto questo problema prima), ma penso che dovresti essere in grado di mettere insieme qualcosa con Mobile Tools and Spaces.

spazi

Spaces è un modulo API destinato a rendere le opzioni di configurazione generalmente disponibili solo a livello di sito per essere configurabili e sovrascritte da singoli "spazi" su un sito Drupal. È stato descritto come:

  • Un modo per far agire un sito Drupal come diversi siti
  • Un modo per fornire gruppi organici o home page utente molto più configurabili e con funzionalità complete
  • Un'API generalizzata per la configurazione contestuale

Strumenti mobili

Il modulo Mobile Tools fornisce agli sviluppatori di Drupal alcuni strumenti per aiutarti ad apportare modifiche al tuo sito in base al dispositivo del visitatore.

La pagina del progetto per MT afferma che non è pronta per la produzione, il che potrebbe essere un problema - dipende dall'ultimo aggiornamento, poiché l'ultimo commit è stato questo mese.

*MODIFICARE

Ho completamente dimenticato di questi!

BrowsCap

Browscap fornisce una versione migliorata della funzione get_browser () di PHP.

Blocco Browscap

Browscap Block aggiunge opzioni di visibilità per bloccare le impostazioni di configurazione per consentire di nascondere o mostrare blocchi nei dispositivi mobili.

Browscap dipende dalla configurazione del server, ma se è possibile utilizzarlo, il secondo modulo offre impostazioni di visibilità extra per ciascun blocco nella pagina di modifica dei blocchi.

inserisci qui la descrizione dell'immagine


Browscap Block sembra davvero promettente grazie, lo controllerò nei prossimi due giorni e ti farò sapere
Clive

Oops, questo mi ha completamente allontanato, scusate per la mezza grazia!
Clive

0

è possibile utilizzare un supporto cross-browser jQuery per ottenere la risoluzione dello schermo:

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

Aggiungi un semplice script PHP per visualizzare le impostazioni del blocco correlato.


Grazie, ma ciò non significherebbe convertire l'intero sito in AJAX per i blocchi? Sto cercando di fare questo lato server se possibile
Clive

0

È possibile utilizzare Mobile Detect Block ma attualmente sto cercando una soluzione che AdaptiveThemefunzioni con la larghezza della finestra e le query multimediali del modulo Breakpoint o per non duplicare quel codice e appesantire il download dell'utente finale più di quanto non sia. Ho anche ottenuto risultati contrastanti con Mobile Detect non rilevabile su un dispositivo con cui l'ho provato, il che lo rende piuttosto inutile come Browscap se non è in grado di fornire risultati affidabili.

Alcune discussioni hanno alcune persone che vogliono allontanarsi da Browscap per un motivo o per l'altro, quindi il passaggio a Mobile Detect .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.