Comment créer une disposition de module à afficher sur tous les thèmes

13

Voici la situation: j'ai plusieurs modules self made, tous testés et fonctionnant en utilisant le thème par défaut. Ensuite, nous avons acheté et installé un nouveau thème. Passé au nouveau thème et les modules ne sont pas affichés. Après plusieurs tests d'essai / d'échec, j'ai constaté que je devais copier la mise en page et les fichiers de modèle correspondants dans les dossiers correspondants du thème récemment installé.

Donc, ma question est: que dois-je faire pour que tous mes modules fonctionnent avec n'importe quel thème installé après la configuration du module?

configuration layout

— Iaroslav
source

1

Si vous placez vos fichiers de mise en page dans design / frontend / base / default / ... ils seront affichés quel que soit le thème

— Sander Mangel

17

Mettez tout sur les base/defaultchemins.

Exemple:

app/design/frontend/base/default

skin/frontend/base/default

— Mark Shust
source

Aie! n'y ai pas pensé, vous avez raison, va tester dès votre arrivée au bureau.

— Yaroslav

+1 - Il y a trop de modules étiquetés comme "communauté" qui ne suivent pas cette pratique et ils devraient.

— pspahn

Le modèle de base a été introduit dans Magento 1.4. pour résoudre exactement ce problème. Sur les versions antérieures, la copie des fichiers de modèles, si vous n'utilisiez pas le package par défaut, était le moyen de le faire.

— Kristof au Fooman

5

La dure vérité est que vous ne pouvez pas vraiment garantir qu'ils le seront. Le fait de placer vos fichiers base/default(ou default/defaults'ils remplacent les modèles de base - car vous ne voulez pas écraser les fichiers de base avec une installation de module, bien que cela vous oblige à conserver les doublons pour l'édition entreprise) garantira qu'ils deviendront les solutions de rechange, mais les fichiers de thème toujours être la priorité la plus élevée.

La plupart des modules sont livrés avec un guide d'installation, qui comprend la mention de copier les fichiers de modèle dans le thème de l'utilisateur s'ils en ont un personnalisé. C'est à peu près le mieux que vous puissiez faire.

— Andrew Quackenbos
source

4

Une chose que nous avons utilisée à quelques reprises est le module [Custom Fallback] [2] de [Fabrizio Branca] [1]. C'est un module très utile pour spécifier votre propre hiérarchie de repli de thème personnalisé. Une chose que vous pouvez faire est de spécifier:

custom/theme

base/default

default/default

Ensuite, tous les modules qui mettent leurs propres modèles dans le default/defaultthème. Ne fonctionnera pas s'ils essaient de remplacer les base/defaultpackages.

Vous pouvez spécifier n'importe quel nombre de packages / thèmes dans la hiérarchie de secours personnalisée.

[1]: http://www.fabrizio-branca.de/ [2]: http://www.fabrizio-branca.de/custom-design-fallbacks-in-magento.html

— Luke Mills
source

2

Tout modèle et fichier de mise en page base/defaultsera chargé, sauf s'il est remplacé quelque part le long du chemin. Cependant, si votre module personnalisé est un widget quelconque, vous devez vous assurer qu'il est répété là où vous en avez besoin. Si, par exemple, vous apportez des modifications qui sont affichées sur la page du produit via getChildHtml, ces appels doivent également être dans le thème correspondant. Si toutefois vos modèles de modules sont des pages par eux-mêmes et à partir desquels ils ne sont pas chargés base/default, quelque chose bloque la configuration de la disposition et vous devriez trouver quoi.

— Petar Dzhambazov
source

Très intéressant le commentaire sur le getChild, j'ai en effet quelques appels de ce genre.

— Yaroslav

1

Il n'y a pas de réponse simple à cela. Cela dépend des modules que vous avez. Par exemple, certaines sociétés de modules, remplaçant les fichiers principaux. Par conséquent, vous devez d' abord vérifier quels fichiers sont disponibles dans les app/etc/moduleset app/code/local/Mage, app/code/community/Magedossiers. Comme vous le savez peut-être, le premier dossier est un dossier d'initialisation de module que vous pouvez désactiver ou activer les modules liés par les fichiers xml. Les deux derniers dossiers (s'ils sont disponibles) sont des dossiers remplaçant le code principal.

Ensuite, ouvrez l'un des fichiers xml de ce etc/modulesrépertoire disponible . Vous verrez quelque chose comme ci-dessous:

<?xml version="1.0"?>
<config>
<modules>
    <Company_Namespace>
        <active>true</active>
        <codePool>local</codePool>
    </Company_Namespace>
</modules>

Voici les parties importantes sont Companyet Namespace. Lorsque vous visitez le app/code/localou les app/code/communitydossiers, vous verrez un dossier nommé Companyet suivi d'un sous-dossier nommé Namespace.

Lorsque vous recherchez, Namespacevous verrez un sous-dossier nommé /etc. Ce dossier conserve le fichier de configuration lié au module config.xml. Ce fichier contient des lignes de configuration liées au module que vous pouvez consulter les fichiers liés à ce module.

Comme je l'ai dit dans ma première ligne, c'est difficile à gérer.

— Oğuz Çelikdemir
source

Je pense que vous avez manqué le point de la question. Il posait des questions sur les mises à jour de la mise en page. La meilleure pratique consiste à utiliser un chemin de base / par défaut / votre module.

— Mark Shust