Drupal 8 views ajax manual refreshing does not work properly

Interviewer: Drupal 8 is amazing … isn’t it? 

Angry me: No, it’s not!

One of the problems we have spent lot’s of energies on is related to Drupal 8 views.
As you probably know the contrib module views has been integrated as a core module in this version 8 of Drupal.

Eventough there’s a nice page with documentation on D8 views, as a Drupal developers we know we can not fully rely on it to get rid of problems.

The problem

When a view is printed into a webpage as block or in a shape different of “page” display type, you can not have ajax features working properly on it, furthermore you are also not able to manually (via javascript) refresh it (triggering “RefreshView”).

If you watch what happen in a standard views with page as display type, and then start to playing “find the difference” with the other display types, you will (soon or later) notice that lot’s Javascript files views-ajax related, are not even included into the DOM!

But, what is happening?

For some reason, after hours, we have understand that even if you flag the checkbox to “use ajax” you are not able to get 

in browser console and neither, of course, the ajax views behavior.

The solution

When you are invoking the view do not forget to invoke “preview” method too, because it is responsible to prepare the view as desired.

We found no documentation on the web, so we assume this article will be useful for some Drupal information thirsty developer.

Thanks to Luca Rossi that achieved the solution.

jQuery Once: Drupal 8 vs Drupal 7

Chi ha avuto modo di cimentarsi nella stesura di qualche riga di codice JS in Drupal 8 si sarà sicuramente imbattuto in un problema, quello di jQuery once che non funziona a dovere, o almeno così pare.

Cosa è successo?

In primis c’è da capire qual è la versione di jQuery utilizzata.

Drupal 7

In tal senso con il modulo contrib jQuery update di Drupal 7 era possibile passare dalla versione 1.4 di jQuery ad una versione superiore a scelta (oggi arrivata alla 1.10) e che il modulo non è più disponibile in Drupal 8.

In Drupal 7 avremmo fatto una cosa del genere:

Drupal 8

In Drupal 8 la versione di jQuery è la 3.2.1 (questo al 24/07/2018 quando è appena uscita l’alpha di Drupal 8.6.0-alpha1; vedi immagine).

Quindi molto più avanzata rispetto a quella di Drupal 7.

Questo ha fatto sì che il modo di invocare determinate funzioni (come il once) sia cambiato.

Come rilevato nel ticket aperto dalla community di Drupal c’è un problema di funzionamento con jQuery once che deve essere invocato in un altro modo, dopo che esso è stato aggiornato alla versione 2.0.

Ebbene tutto ciò è stato realizzato discusso, analizzato e risolto in un ticket sulla community, questo: https://www.drupal.org/node/2457769.

Per comodità riporto di seguito l’esempio ivi riportato:

Come è possibile vedere adesso il once si ottiene in maniera sequenziale, senza gli innesti che erano necessari qualche versione fa.

Drupal 7 campi condizionali nei form con gli states

Oggi voglio presentarvi gli states degli elementi di un form Drupal.

Il problema

Vogliamo per un motivo o per un altro nascondere selettivamente dei campi in determinate condizioni, senza scrivere dei JS da aggiungere al form, massimizzando la manutenibilità del codice.

Tutto questo è consentito dagli states degli elementi del form di Drupal che consentono di inserire una logica con stati e condizioni in grado ad esempio di nascondere un campo se una checkbox è flaggata oppure mostrare un campo e renderlo obbligatorio.

Esempio:

Poniamoci nel caso in cui abbiamo un modulo di inserimento (un form insomma) di richieste di supporto in cui abbiamo un campo di tipo select chiamato “Oggetto” con varie opzioni selezionabili. Una di queste opzioni è “Altro”, se “Altro” è selezionato allora bisogna mostrare un campo (normalmente nascosto) chiamato “oggetto altro”.

Un codice di questo tipo risolve assolve al compito:

Interessante analizzare la funzione drupal_process_states poiché essa mostra tutti gli stati e le condizioni possibili, che per comodità riporto qui sotto:

I possibili stati di un elemento (del form) sono:

  • enabled
  • disabled
  • required
  • optional
  • visible
  • invisible
  • checked
  • unchecked
  • expanded
  • collapsed

Le possibili condizioni (che su drupal.org chiama remote conditions) sono:

  • empty
  • filled
  • checked
  • unchecked
  • expanded
  • collapsed
  • value

Gli stati che seguono possono essere utilizzati sia come stati di un elemento (primo gruppo) sia come condizioni remote (secondo gruppo):

  • relevant
  • irrelevant
  • valid
  • invalid
  • touched
  • untouched
  • readwrite
  • readonly

Tuttavia il funzionamento di quest’ultimo gruppo di stati non è garantito in ogni scenario, poiché le funzionalità che ne derivano sono molto dipendenti dal browser dal quale vengono eseguite.

Dalla versione 7.14 di Drupal è anche possibile usare OR e XOR.

Spero di essere stato utile.

NOTA: Un discorso del tutto analogo può essere fatto per Drupal 8 che, sebbene abbia stravolto la maggior parte delle funzionalità di Drupal 7, implementa questa degli states degli elementi del form in maniera similare.

Drupal 8 creare link html da file id (fid)

Per i nostalgici di Drupal 7 che hanno provato disperatamente a districarsi tra le varie classi introdotte in Drupal 8, ebbene sappiate che:

  1. per quello che può servire, godete della mia solidarietà
  2. dopo varie peripezie sono riuscito ad ottenere un codice utile a generare il famigerato html

Ecco il codice di esempio testato su Drupal 8.5.x

spero che questo codice vi sia di aiuto.

Fatemi sapere, nei commenti, se questa cosa vi risolve il problema.

Email security check. Email violata? Controlla e provvedi subito!

Vi ricordate quando abbiamo parlato di come creare una password che vi garantisca un buon livello di sicurezza?
Ecco il link all’articolo http://www.unmoscerinonelweb.com/blog/password-sicura-sei-sicuro/ nel caso ve lo foste perso.

Rimane sempre una buona idea avere una password diversa per ogni account, perché? Semplice se qualche cracker (un hacker con cattive intenzioni) riuscisse a violare un sito dove siete registrati ed ottenere la vostra password allora avrebbe le porte della vostra privacy e della vostra sicurezza spalancate, con tanto di tappeto rosso.

Su questo sito potete scoprire se il vostro account email risulta essere stato violato assieme agli altri presenti su un sito dove siete registrati e quali sono i dati in pericolo.

Visitate haveibeenpwned.com scrivete il vostro indirizzo email e incrociate le dita.

Se ci sono problemi di sicurezza vi sarà mostrato un report di questo tipo:

Andate portale per portale e cambiate la password, inserendone una diversa per ogni sito/portale.

Buona fortuna.

PSSSS

Volete un modo per conservare le password indipendente e offline? Date un’occhiata a keepass.info.