Dlaczego istnieje układ / base / default / layout i / default / default?

Dlaczego istnieje układ / base / default / layout i / default / default? Wydaje się to mylące i zbędne.

Krótko mówiąc, default/defaultspuścizna <1.4CE, gdzie był to oryginalny pakiet podstawowy. Główne tematy Magento są nadal dostarczane w domyślnym pakiecie - więc niekoniecznie są one przestarzałe , ale są starsze.

Ponieważ domyślne / domyślne można zastąpić podczas aktualizacji CE, nie jest zalecane umieszczanie tutaj plików - ale wtyczki próbujące być kompatybilne wstecz z <1.3 mogą celowo umieszczać tutaj pliki zamiast podstawowego / domyślnego.

_{Źródło: http://www.magentocommerce.com/knowledge-base/entry/magentos-theme-hierarchy#3.2}

Znalazłem jeszcze lepszą odpowiedź na oficjalnej wiki Magento . (Pochodzi z 2012 r., Więc nie jestem pewien, czy którakolwiek informacja jest nieaktualna - ale wydaje mi się, że ma ona zastosowanie do 1.8.1 z tego, co mogę powiedzieć). Chociaż zdecydowanie zalecam przeczytanie jej w całości (kliknij pogrubienie link), pozwól mi podsumować to poniżej.

O co w /basetym chodzi?

/base/defaultzostał wprowadzony w CE 1.4 i EE 1.8, aby skonsolidować całą funkcjonalność frontonu typu logiki aplikacji w jedną bazę kodową, której nigdy nie powinieneś edytować. Ma taką samą strukturę katalogów jak pakiet projektu z domyślnym motywem , ale brakuje niektórych kluczowych plików CSS, więc nie zaleca się, aby był to jedyny pakiet i motyw projektu.

Wielki analogia byłoby powiedzieć, że /baseto /design/frontend, co /corejest /code. Nie należy modyfikować plików w środku /base. Zamiast tego powinieneś rozszerzyć jego funkcjonalność o własny pakiet niestandardowego projektu , w którym Magento najpierw zajrzy do wnętrza, zanim zacznie ponownie działać /base/default- najpierw zajrzy /design/frontend/{custompackagename}/{customthemename}, potem spadnie /design/frontend/{custompackagename}/default/, a na końcu znowu /design/frontend/base/default.

Naprawdę, należy o tym myśleć /base- /defaultpodkatalog jest tam tylko dlatego, że system rezerwowy Magento kończy swoją podróż przez każdy pakiet projektowy w swoim /default temacie . Dla jasności, pakiet projektu jest podkatalogiem wewnątrz /design/frontend, a motyw jest podkatalogiem w pakiecie projektu. Kiedy Magento przegląda pakietu projektowego, czy to /baselub /{custompackagename}The /defaulttematem będzie zawsze ostatnie miejsce Magento będzie wyglądać.

Dlatego, ponieważ głównym celem /basejest służyć jako ostatni punkt w systemie rezerwowym, zgodnie z tym celem nigdy nie będzie miał innego tematu niż /base/default.

Dlaczego więc jest /default?

Więc dlaczego wciąż istnieje /design/frontend/default/default? A dlaczego nie ma /design/adminhtml/base/default? Szczerze mówiąc, nie znam odpowiedzi na drugie pytanie. Ale pozwól mi spróbować odpowiedzieć na pierwsze.

Zapominając kompatybilność starszych itd., Czuję to może być znacznie łatwiejsze do zrozumienia, jeżeli zostali wezwani /generic/defaultzamiast /default/default. Więc dla celów tej dyskusji odniosę się /app/design/frontend/default/i /app/skin/frontend/default/zbiorowo jako „rodzajowe pakietu projektowania”. Będę odnosić się do wszystkiego w tych katalogach, jakby były nazywane /app/design/frontend/generici /app/skin/frontend/generic. Ponieważ (przynajmniej w przypadku frontendu) system awaryjny Magento już nie wraca /app/design/frontend/default/, czuję, że ciągłe nazywanie go „domyślnym” jest mylące, ponieważ to słowo sugeruje, że coś jest częścią łańcucha zastępczego , ale ogólny pakiet projektowy nie jest już część łańcucha rezerwowego od momentu wprowadzenia/base. Dlatego nazwanie go „ogólnym pakietem projektowym” zamiast „domyślnym pakietem projektowym” łagodzi to zamieszanie, mówiąc nam, że tak, to tylko zestaw ogólnych motywów dostarczanych z Magento za darmo, bez sugerowania, że ​​jest to część awaryjnego łańcucha. :RE

Prowadzenie następnie: the generic pakiet projekt ma domyślny motyw i kilku innych niż domyślne tematy wewnątrz: /blank, /iphone, i /modern. Jeśli aktywny jest motyw inny niż domyślny, jego pliki zastąpią wszystko w motywie domyślnym, ale bez względu na to, który motyw domyślny jest aktywny, wszelkie części domyślnego motywu pakietu ogólnego, które nie zostały zastąpione motywem innym niż domyślny wciąż uciekają, a ponadto zastąpią wszystko w /base/default. Wreszcie wszelkie nieprzepisane części /base/defaulturuchomienia.

Jednak, co krytyczne, żadna część ogólnego pakietu projektowego nigdy nie zostanie uruchomiona, jeśli używasz niestandardowego pakietu projektowego. System rezerwowy przechodzi bezpośrednio od {customdesignpackage}/{customthemename}do {customdesignpackage}/defaultdo base/default. (Chyba że nie rozumiem tego poprawnie; popraw mnie, jeśli się mylę).

To powiedziawszy, całkowite usunięcie ogólnego pakietu projektowego bez posiadania niestandardowego pakietu projektowego byłoby nierozsądne, ponieważ ogólny pakiet projektowy zawiera pewne elementy skórki, które są nadal potrzebne.