Structure de dossier appropriée pour le composant personnalisé
J'essaie d'utiliser les outils joomlatools (joomla-console dans un nouveau projet. Cependant, je ne peux pas utiliser la fonctionnalité symlink à cause de la structure de mon répertoire.
Dans le passé, j'ai toujours construit des composants avec un simple
administrator/
controllers
models
views
etc
site
controllers
models
views
etc
structure, et cela fonctionne bien lorsque vous zippez/installez-le.
Joomlatools dit que vous devriez utiliser
administrator/
components/
mycomponent/
controllers
models
views
etc
site/
components/
mycomponent/
controllers
models
views
etc
structure.
Qu'est-ce que vous utilisez et qui est "correct"?
Il n'y a pas de bonne ou de mauvaise façon de structurer votre code, mais il y a certainement de meilleures façons.
Pourquoi
La structure que nous utilisons chez Joomlatools découle de la nécessité de disposer d’une structure standardisée adaptée aux développeurs. Nous n'aimons pas réinventer la roue, le choix le plus logique est donc d'utiliser la structure de Joomla.
Le lien symbolique est conçu pour les développeurs qui souhaitent créer un lien symbolique depuis un dépôt Git vers une installation Joomla. Nous l'utilisons pour tous nos développements de composants Joomla, cela maintient notre code synchronisé, nous permet de changer de branche, tandis que nous travaillons directement dans le référentiel Git.
Le problème avec rsync est que pour garder le code synchronisé, vous devez le resynchroniser manuellement chaque fois qu'une modification est effectuée, car rsync doit copier les modifications. Ceci est moins utile lors du développement.
Avantages
L'utilisation de cette structure vous offre les avantages suivants:
Vous pouvez utiliser le lien symbolique qui fait partie de notre Joomla Console pour lier facilement votre code depuis un dépôt Git local vers une installation Joomla, ce qui vous permet de garder les éléments synchronisés automatiquement.
Vous pouvez travailler avec des paquets complexes. Nos extensions Joomlatools comprennent non seulement un composant, mais également des modules, des plugins, des bibliothèques, etc., qui doivent toutes faire partie d'un même package pour empêcher nos utilisateurs de devoir tout installer séparément.
administrateur / composants / com_foo/ contrôleurs modèles vues modules / mod_bar site / composants / com_foo/ contrôleurs modèles vues modules/ mod_bar plugins / foo / bar /
Un excellent exemple de cette structure que vous pouvez trouver dans notre composant Joomlatools Todo . Il suit la structure de Joomla et, comme vous pouvez le voir, comprend des modules, des plugins, etc.
Créer votre propre lien symbolique
Enfin, si vous souhaitez utiliser rsync à l'aide de la console Joomla ou si vous souhaitez créer votre propre solution symlinker qui suit votre structure préférée, vous pouvez envisager de créer un plug-in de console.
Avec la version 1.3 de la console vous pouvez maintenant créer vos propres plugins, les distribuer à l’aide de Packagist et les installer à l’aide de $ joomla plugin:install.
Bonne codage!
Aucune structure n'est fausse, la bonne chose à propos de Joomla est que cela ne vous oblige pas. Votre premier en ce qui concerne sa structure dans une archive installable, je dirais, est le plus proche de la norme. Certains développeurs préfèrent tout dans un répertoire, d'autres préfèrent 2 ou 3 dossiers bien divisés. Certains peuvent même avoir un dossier pour chaque fichier, rien n’est inexact à la fin car tout "fonctionne". Bien que personnellement, je n'ai aucune expérience de joomlatools, si cette structure est destinée à l'archive d'installation, elle semble plutôt "excessive", pas de vraie raison pour 2 des niveaux de dossier.
Cette partie suivante n'est pas directement liée à la question
Aussi pour symlink je ne pense pas que cela puisse vraiment fonctionner, si un fichier fait référence à un autre fichier, il le recherchera en se basant sur le "vrai" fichier (donc si vous avez root/installable/file.php, allez à root/joomla /file.php suppose que vous êtes en root/installable). Il y a peut-être un moyen de contourner cela, mais j'ai trouvé une meilleure alternative, qui n'a pas autant de problèmes potentiels, rsync. Bien sûr, vous avez besoin de la ligne de commande, mais je travaille sur un hôte partagé, même avec un accès ssh limité.
#!/bin/bash
# sync
rsync -r /home/joomla/components/com_component/administrator/* /home/joomla/public_html/administrator/components/com_component/
rsync -r /home/joomla/components/com_component/site/* /home/joomla/public_html/components/com_component/
rsync -r /home/joomla/components/com_component/administrator/language/* /home/joomla/public_html/administrator/language/
Il y a un peu de difficulté, mais vous pouvez voir que, quelle que soit la structure de dossier, vous pouvez mapper les fichiers dans le dossier approprié. Vous pouvez aussi peut-être simplement utiliser CP, mais cela a fonctionné pour moi et je n’avais donc aucune raison de changer (et même de travailler sur plusieurs serveurs).
Bien que cela doive être exécuté chaque fois que vous faites une mise à jour, mais pas trop difficile une fois que vous avez compris le principe. Vous pouvez également le faire en sens inverse et simplement éditer directement sur votre site dev pour le composant (là encore, il peut y avoir un moyen de contourner cela, simplement ne pas l'avoir encore travaillé).
Tout dépend vraiment de vos préférences personnelles et de ce que vous spécifiez dans votre fichier manifeste.
Voir Fichiers manifestes (où vous indiquez à Joomla votre structure de fichier dans le zip) https://docs.joomla.org/Manifest_files
Si vous configurez votre projet avec un fichier de construction Phing spécifique à une extension, vous ne le ferez plus jamais, puisque le fichier Zip est créé automatiquement. https://github.com/akeeba/buildfiles/blob/master/phing/README.md