Mi chiedo se esiste una soluzione per archiviare i moduli web nel codice. In questo modo puoi duplicarli facilmente su altri siti e raggrupparli con i tuoi moduli. Sto esaminando qualcosa di simile come l'API delle visualizzazioni.

Se non è disponibile quante persone sono interessate a tale funzionalità? Potrei sviluppare un modulo in grado di gestire la memorizzazione di moduli web in Code. E hai qualche preoccupazione nella creazione di un tale modulo?

Grazie Jaap

webforms

— Jaap Jansma
fonte

Intendi i moduli creati con il modulo Webform?

— Mołot,

Sì, intendo le forme create con il modulo webform

— Jaap Jansma,

In realtà è molto semplice, basta dare un'occhiata a come lo fa la condivisione Webform . ( webform_share_export()e webform_share_node_insert()sono le funzioni di denaro). Non posso dire che approvo l'uso di eval(), ma potresti semplicemente convertirlo per usare invece un oggetto JSON / una stringa serializzata. L'unica (piccola) difficoltà che devi superare è come / quando il tuo modulo web viene applicato a un nuovo nodo, ovviamente un nodo è richiesto per collegare il modulo web.

— Clive

Non proprio, e non ce n'è bisogno

Se hai bisogno di un modulo disponibile dal codice, i moduli API del modulo non sono così difficili da scrivere da zero. Contrariamente a quanto visto, puoi solo creare temi Webform con il loro ID nodo, e questo cambierebbe da sito a sito, quindi i moduli Webform in bundle con il modulo non saranno convenienti.
Se desideri raggruppare i moduli con i tuoi moduli e, per qualsiasi motivo, non puoi utilizzare l'API per i moduli, l' integrazione delle funzionalità UUID e la condivisione Webform forniscono modi per farlo. Non sarà un codice in senso puro, ma dovrebbe funzionare.
È relativamente facile da usare hook_form_alterper ottenere la rappresentazione API del modulo di un particolare modulo web. Certo, non sarai in grado di cambiarlo facilmente in futuro, ma di nuovo, contrariamente alle opinioni, è buono. Il modulo non è danneggiato se alcuni dati non vengono visualizzati. I dati non forniti, o forniti in un modo che il modulo non prevede, potrebbero rompere le cose. Quindi, se il modulo ha bisogno di un modulo, non dovrebbe essere facile da modificare . Le modifiche al modulo richiederebbero comunque modifiche al codice del modulo, quindi il codice API del modulo rende le cose più facili, non più difficili a lungo termine, in tali situazioni.

— Molot
fonte

Sebbene questa sia una buona risposta per l'alternativa, penso che voler mantenere i moduli web nel codice sia una richiesta abbastanza ragionevole (non sono d'accordo sul fatto che non ce n'è bisogno o che non sia davvero possibile). Ad esempio, se si desidera fornire un modulo di contatto di base con un modulo che può quindi essere esteso dagli utenti tramite l'interfaccia utente, un modulo Web sarebbe l'ideale. Costruire quell'interfaccia utente da solo sarebbe un vero dolore. Poiché l' webformoggetto (o l'array?) Si trova comunque sull'oggetto nodo, può essere serializzato e riapplicato molto facilmente

— Clive

@Clive Ma per un contatto di base, perché qualcuno dovrebbe richiedere un codice reale? Perché il nodo esportato (con l'integrazione delle funzionalità UUID è possibile esportare il nodo nel modulo) non sarebbe sufficiente?

— Mołot,

Quel modulo sincronizza anche l'oggetto Webform?

— Clive

@Clive Per quanto mi ricordo, con alcuni problemi ma sì. Oh, e se il codice personalizzato avesse bisogno di dati da un modulo, renderlo webform non sarebbe pericoloso? Non conosco alcun modo per rendere i campi resistenti all'eliminazione in Webform (ma ammetto di non aver guardato così duramente).

— Mołot,

In effetti, c'è persino una patch per il webform per far funzionare l'integrazione. Lo riprendo :)

— Clive

Memorizza i moduli Web Drupal 7 nel codice

Non proprio, e non ce n'è bisogno