Pourquoi y a-t-il / base / default / layout et une / default / default layout?

Pourquoi y a-t-il / base / default / layout et une / default / default layout? Cela semble déroutant et redondant.

En bref, l' default/defaulthéritage de <1.4CE où il était le package de base d'origine. Les thèmes principaux de Magento sont toujours livrés dans le package par défaut - il n'est donc pas nécessairement obsolète autant qu'il est hérité.

Comme default / default peut être écrasé pendant les mises à niveau de CE, il n'est pas conseillé de placer des fichiers ici - mais les plugins essayant d'être rétrocompatibles avec <1.3 peuvent intentionnellement placer des fichiers ici au lieu de base / default.

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

J'ai trouvé une réponse encore meilleure sur le wiki officiel de Magento . (C'est à partir de 2012, donc je ne suis pas sûr si l'une des informations est obsolète - mais elle semble être applicable à 1.8.1 d'après ce que je peux dire.) Bien que je vous recommande fortement de le lire en entier (cliquez sur le gras lien), permettez-moi de le résumer ci-dessous.

De quoi s'agit- /baseil?

/base/defaulta été introduit dans CE 1.4 et EE 1.8 pour consolider toutes les fonctionnalités frontales de type logique d'application dans une base de code unique que vous ne devriez jamais modifier. Il a la même structure de répertoires qu'un package de conception avec un thème par défaut , mais il manque certains fichiers CSS clés, de sorte qu'ils ne vous recommandent pas de l'avoir comme unique package et thème de conception.

Une grande analogie serait de dire que /basec'est à /design/frontendce qui /coreest à /code. Vous n'êtes pas censé modifier les fichiers à l'intérieur /base. Au lieu de cela, vous êtes censé étendre ses fonctionnalités dans votre propre package de conception personnalisé , que Magento examinera d'abord avant de retomber /base/default- d'abord, il regardera /design/frontend/{custompackagename}/{customthemename}, puis il retombera /design/frontend/{custompackagename}/default/, et enfin il se repliera /design/frontend/base/default.

Vraiment, cela devrait être considéré comme /base- le /defaultsous-répertoire n'est là que parce que le système de secours de Magento termine son voyage à travers chaque package de conception dans son /default thème . Pour être clair, un package de conception est un sous-répertoire à l'intérieur /design/frontendet le thème est un sous-répertoire à l'intérieur d'un package de conception. Lorsque Magento examine un package de conception, que ce soit /baseou non /{custompackagename}, le /defaultthème sera toujours le dernier endroit où Magento se penchera.

Par conséquent, puisque le but principal de /baseest de servir de point final dans le système de secours, selon ce but, il n'aura jamais d'autre thème que /base/default.

Pourquoi y a-t-il /defaultalors?

Alors pourquoi y en a- /design/frontend/default/defaultt- il encore ? Et pourquoi n'y en a- /design/adminhtml/base/defaultt- il pas ? Pour être honnête, je ne connais pas la réponse à la deuxième question. Mais permettez-moi d'essayer de répondre à la première.

Oubliant la compatibilité héritée, etc., je pense qu'il serait beaucoup plus facile de comprendre si elle était appelée à la /generic/defaultplace de /default/default. Donc, aux fins de cette discussion, je ferai référence /app/design/frontend/default/et /app/skin/frontend/default/collectivement au "paquet de conception générique". Je ferai référence à tout ce qui se trouve dans ces répertoires comme s'ils étaient appelés /app/design/frontend/genericet /app/skin/frontend/generic. Puisque (du moins dans le cas du frontend) le système de secours de Magento ne retombe plus /app/design/frontend/default/, je pense que continuer à l'appeler "par défaut" est source de confusion car ce mot implique que quelque chose fait partie de la chaîne de secours , mais le package de conception générique n'est plus une partie de la chaîne de secours dès l'introduction de/base. Par conséquent, l'appeler le "package de conception générique" au lieu du "package de conception par défaut" atténue cette confusion en nous disant que oui, c'est juste l'ensemble des thèmes génériques fournis gratuitement avec Magento, sans impliquer qu'il fait partie de la chaîne de secours. :RÉ

Poursuivant ensuite: le package de conception générique a un thème par défaut et plusieurs thèmes à l' intérieur non par défaut: /blank, /iphoneet /modern. Si un thème non par défaut est actif, ses fichiers remplaceront tout ce qui se trouve dans le thème par défaut, mais quel que soit le thème non par défaut actif, toutes les parties du thème par défaut du package générique qui n'ont pas été remplacées par le thème non par défaut toujours exécuté, et en outre, ils remplaceront tout /base/default. Enfin, toutes les parties non remplacées de /base/defaultget run.

Cependant, de manière critique, aucune partie du package de conception générique ne sera jamais exécutée si vous utilisez un package de conception personnalisé. Le système de secours passe directement de {customdesignpackage}/{customthemename}à {customdesignpackage}/defaultà base/default. (À moins que je ne comprenne pas cela correctement; veuillez me corriger si je me trompe.)

Cela étant dit, il ne serait pas judicieux de supprimer le package de conception générique sans avoir de package de conception personnalisé en place, car le package de conception générique comporte certains éléments d'habillage qui sont toujours nécessaires.