Perché c'è un layout / base / default / e un layout / default / default?

Perché c'è un layout / base / default / e un layout / default / default? Questo sembra confuso e ridondante.

In breve default/defaultè legacy da <1.4CE dove era il pacchetto base originale. I temi di base di Magento vengono ancora forniti nel pacchetto predefinito, quindi non è necessariamente deprecato tanto quanto è legacy.

Poiché default / default possono essere sovrascritti durante gli aggiornamenti di CE, non è consigliabile posizionare qui i file - ma i plugin che tentano di essere retrocompatibili con <1.3 possono posizionare intenzionalmente i file qui invece di base / default.

_{Fonte: http://www.magentocommerce.com/knowledge-base/entry/magentos-theme-hierarchy#3.2}

Ho trovato una risposta ancora migliore sulla wiki ufficiale di Magento . (È del 2012, quindi non sono sicuro che alcune delle informazioni non siano aggiornate, ma sembra applicabile a 1.8.1 da quello che posso dire.) Mentre consiglio vivamente di leggerle per intero (fare clic in grassetto link), vorrei riassumerlo di seguito.

Di cosa si /basetratta?

/base/defaultè stato introdotto in CE 1.4 ed EE 1.8 per consolidare tutte le funzionalità front-end di tipo app-logic in un unico codebase che non si dovrebbe mai modificare. Ha la stessa struttura di directory di un pacchetto di progettazione con un tema predefinito , ma mancano alcuni file CSS chiave, quindi non ti raccomandano di averlo come unico pacchetto di progettazione e tema.

Una grande analogia sarebbe quella di dire che /baseè a /design/frontendciò che /coreè di /code. Non dovresti modificare i file all'interno /base. Invece dovresti estendere la sua funzionalità nel tuo pacchetto di design personalizzato , di cui Magento guarderà dentro prima di ricadere su /base/default- prima guarderà dentro /design/frontend/{custompackagename}/{customthemename}, poi ricadrà /design/frontend/{custompackagename}/default/e infine ricadrà /design/frontend/base/default.

Davvero, dovrebbe essere pensato come /base: la /defaultsottodirectory è presente solo perché il sistema di fallback Magento completa il suo viaggio attraverso ogni pacchetto di progettazione nel suo /default tema . Per essere chiari, un pacchetto di progettazione è una sottodirectory all'interno /design/frontende il tema è una sottodirectory all'interno di un pacchetto di progettazione. Quando Magento guarda attraverso un pacchetto di design, sia esso /baseo /{custompackagename}, il /defaulttema sarà sempre l'ultimo posto in cui Magento cercherà.

Pertanto, poiché lo scopo principale di /baseè quello di fungere da punto finale nel sistema di fallback, secondo tale scopo non avrà mai un tema diverso da quello /base/default.

Perché c'è un /defaultallora?

Allora perché c'è ancora un /design/frontend/default/default? E perché non c'è un /design/adminhtml/base/default? Ad essere sincero, non conosco la risposta alla seconda domanda. Ma lasciami provare a rispondere al primo.

Dimenticando la compatibilità legacy, ecc., Penso che potrebbe essere molto più facile capire se fosse chiamato /generic/defaultinvece di /default/default. Quindi, ai fini di questa discussione, mi riferirò /app/design/frontend/default/e /app/skin/frontend/default/collettivamente al "pacchetto di design generico". Mi riferirò a tutto ciò che è dentro quelle directory come se fossero chiamate /app/design/frontend/generice /app/skin/frontend/generic. Poiché (almeno nel caso del frontend) il sistema di fallback di Magento non ricade più /app/design/frontend/default/, ritengo che continuare a chiamarlo "predefinito" sia confuso poiché quella parola implica che qualcosa fa parte della catena di fallback , ma il pacchetto di progettazione generico non è più parte della catena di fallback dall'introduzione di/base. Pertanto, chiamandolo "pacchetto di progettazione generico" anziché "pacchetto di progettazione predefinito" allevia questa confusione dicendoci che sì, è solo l'insieme di temi generici che viene fornito gratuitamente con Magento, senza implicare che faccia parte della catena di fallback. : D

Proseguendo poi: il pacchetto generico design ha un tema di default e diversi temi non predefiniti all'interno: /blank, /iphone, e /modern. Se è attivo un tema non predefinito, i suoi file sovrascriveranno qualsiasi cosa nel tema predefinito, ma indipendentemente dal tema non predefinito attivo, tutte le parti del tema predefinito del pacchetto generico che non sono state sostituite dal tema non predefinito continuano a correre, e inoltre avranno la precedenza su qualsiasi cosa /base/default. Infine, /base/defaultvengono eseguite tutte le parti non ignorate .

Tuttavia, in modo critico, nessuna parte del pacchetto di progettazione generico verrà mai eseguita se si utilizza un pacchetto di progettazione personalizzato. Il sistema di fallback va direttamente da {customdesignpackage}/{customthemename}a {customdesignpackage}/defaulta base/default. (A meno che non lo capisca correttamente; per favore correggimi se sbaglio.)

Detto questo, eliminare del tutto il pacchetto di progettazione generico senza disporre di un pacchetto di progettazione personalizzato non sarebbe saggio poiché il pacchetto di progettazione generico presenta alcuni elementi skin ancora necessari.