it-swarm.it

Quali moduli forniti vengono spostati in Drupal 8 core?

C'era un numero significativo di moduli D6 (o versioni di) che venivano inseriti nel core D7. Mi chiedo se ce ne sono per D8?

20
user842

La risposta breve è che Drupal è sviluppato dalla community, quindi dipende da cosa TU (chiunque legga questa risposta) aggiungi a Drupal 8.

Uso sempre il problema Aggiungi elementi dell'interfaccia utente jQuery al core come esempio di come funziona questo processo. Alcune persone hanno avuto un'idea, hanno pubblicato del codice, è stato rivisto e discusso, quindi aggiunto a Drupal 7 core.

I contributi di base non sono affatto esclusivi, quindi sii audace! Inizia a contribuire.

10
Chris Pliakas

Moduli portati nel nocciolo

Interamente:

  • Punto di rottura
  • CacheTags
  • Traduzione di contenuti
  • Email (campo semplice, solo validazione HTML5)
  • API Entity
  • Riferimento entità
  • Modalità di visualizzazione delle entità
  • Entità del file
  • Link (campo semplice, solo convalida HTML5)
  • Telefono (campo semplice, solo convalida HTML5)
  • Immagine
  • Modifica rapida
  • Traslitterazione
  • UUID
  • Visualizzazioni
  • RESTWS (rinominato in REST)

Parzialmente:

  • Admin Views (rielaborato)
  • CKEditor
  • CTools
  • Data (tutte tranne le date ricorrenti)
  • Display Suite (modalità di visualizzazione)
  • Internazionalizzazione
  • Migrare
  • Views Bulk Operations (rielaborato)

Rimosso

  • Blog (spostato in contrib)
  • Dashboard (spostato per contribuire come Homebox)
  • ID aperto
  • Overlay (sostanzialmente rielaborato per non fornire un "overlay")
  • Filtro PHP (spostato in contrib)
  • Sondaggio (spostato in contrib)
  • Profilo (usa Profile2 ora)
  • Traduzione (sostituita da Entity Translation)
  • Trigger (usa ora le regole)
  • Firma (funzionalità fornita dall'utente spostata in contrib)
  • XML-RPC (spostato in contrib)

I moduli sono sostanzialmente cambiati di Drupal 8:

Obsoleto (non ti serviranno più)

  • Admin
  • Lingua di amministrazione
  • Fagiolo
  • Scatole
  • Filtro didascalia
  • Campo calcolato
  • Ctools esportabili
  • Negoziazione della lingua di fallback
  • Campo nascosto
  • Pannelli Fieldable
  • Filtro a galleggiante
  • Widget campo nascosto
  • Storia
  • IMCE
  • Aggiornamento di localizzazione
  • Localized Drupal Distribution
  • Blocco menu
  • Percorsi menu
  • Filtro del modulo
  • Riferimento nodo
  • Segnaposto
  • Profile2
  • Autorizzazioni RSS
  • Servizi
  • Sostituzione delle stringhe
  • Braccio forte
  • Gettone
  • Traslitterazione
  • Campo immagine utente
  • Riferimento per l'utente
  • Schede verticali
  • Wysiwyg * (il modulo e tutto ciò che lo riguarda)

Ridotto (questi avranno meno lavoro da fare)

  • Backup e migrazione
  • Contesto
  • Pangrattato personalizzato
  • Caratteristiche
  • Feed
  • Menu Pangrattato
  • Collegamenti di servizio
  • Regole
  • Viste * (ogni modulo relativo alle viste)
45
tim.plunkett

Non sono i moduli che vengono inseriti nel nucleo, è la funzionalità. Funzionalità che potrebbe essere stata fornita dai moduli contribuiti (e il codice che è stato aggiunto al core potrebbe essere stato influenzato da quei moduli ma non necessariamente che il codice effettivo viene riutilizzato. Ad esempio i campi, che sono stati ispirati da CCK ma erano una completa riscrittura da zero ). E quindi questi moduli contrib non devono essere portati alla prossima versione core.

Detto questo, non esiste una tabella di marcia in Drupal core development. Quindi è impossibile a questo punto rispondere alla tua domanda reale.

L'unica cosa che esiste ora è una serie di cosiddetti iniziative di base . Questa è un'area in cui le persone lavorano insieme sotto il "comando" del proprietario dell'iniziativa per migliorare Drupal in un'area specifica. Uno di questi è HTML5 (il che potrebbe significare che un certo numero di HTML5 correlati i moduli potrebbero non essere necessari in D8) un altro è Web Services and Context (il che significa che per esempio il modulo Context non sarà necessario e forse parti di pannelli). Ma tutto ciò è solo una speculazione a questo punto. Perché anche se esistono queste iniziative, non è scolpito nella pietra che tutto ciò a cui stanno lavorando verrà commesso.

Questo è fondamentalmente i due compiti principali che Dries Buytaert (e in una certa misura co-manutentori, proprietari di iniziative, ...) stanno svolgendo. Stanno parlando di come potrebbe evolvere Drupal e cosa si potrebbe fare. E alla fine Dries decide se una patch è commesso o meno.

Nel mezzo, tutto dipende se ci sono persone che sono interessate a qualcosa e vogliono implementare/migliorare/correggere una parte di Drupal core.

6
Berdir