Tag: drupal

Pubblicato il

Testare Drupal 10 in locale

Risolvere il problema del 404 not found che si verifica quando si tenta di effettuare il CRUD di un campo su un’entità di Drupal 10.

Quasi sicuramente se sei arrivato qui significa che all’aggiunta di un campo su un tipo di contenuto di Drupal 10, hai ricevuto un errore 404 e lo stesso ti sarà successo in modifica o delete del campo di un entità.

Se sei fortunato, come descritto da Halt nell’issue #2743633 su drupal.org il problema potrebbe essere generato dal comando php che ti consente di lanciare il webserver in ascolto su una certa porta.

Normalmente il comando che si lancia è:

php -S localhost:8000

Che ti consente, navigando con il browser su quell’host, di vedere la tua installazione Drupal 10. Tuttavia tale comando risulta insufficiente, in quanto bisogna dargli in pasto un file che è incluso nell’installazione Drupal, ovvero “.ht.router.php“.

TODO immagine boyscout che giura

Utilizzando il comando il problema non si verifica più, parola di boy scout.

php -S localhost:8888 .ht.router.php

Aprendo il file .ht.router.php scopriamo subito il suo proposito leggendo il commento in testa:

/**
 * @file
 * Router script for the built-in PHP web server.
 *
 * The built-in web server should only be used for development and testing as it
 * has a number of limitations that makes running Drupal on it highly insecure
 * and somewhat limited.
 *
 * Note that:
 * - The server is single-threaded, any requests made during the execution of
 *   the main request will hang until the main request has been completed.
 * - The web server does not enforce any of the settings in .htaccess in
 *   particular a remote user will be able to download files that normally would
 *   be protected from direct access such as .module files.
 *
 * The router script is needed to work around a bug in PHP, see
 * https://bugs.php.net/bug.php?id=61286.
 *
 * Usage:
 * php -S localhost:8888 .ht.router.php
 *
 * @see http://php.net/manual/en/features.commandline.webserver.php
 */

Cosa che significa sostanzialmente:

  • che questo file andrebbe lanciato solo per finalità di testing e sviluppo
  • che non è sicuro
  • che è limitato, ad esempio dal fatto che è single thread

Buon Drupal 10 🙂

Pubblicato il

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:

$form['subject_other'] = array(
  '#states' => array(
    // Show the subject_other if subject value is other.
    'visible' => array(
      ':input[name="subject"]' => array('value' => 'other'),
    ),
    'required' => array(
      ':input[name="subject"]' => array('value' => 'other'),
    ),
  ),
);

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.

Proudly powered by WordPress