180 likes | 339 Views
Bonnes pratiques ez publish. Sommaire. ENVIRO NNE MENT Installation Configuration Front END templates Back end Api AUTREs. Bonnes pratiques. ENVIRONNEMENT ORGANISATION Utilisation de même IDE pour les développeurs. Installer les plugins ( smile ezpublish , subversion, FileSync …).
E N D
Sommaire • ENVIRONNEMENT • Installation • Configuration • Front END • templates • Back end • Api • AUTREs
Bonnes pratiques • ENVIRONNEMENT • ORGANISATION • Utilisation de même IDE pour les développeurs. • Installer les plugins (smileezpublish, subversion, FileSync …). • XDEBUG est une extension pour php apportant des fonctions de débogage. • Base de données (il est préférable que l’équipe partagent la même base de données). • Mise en place un cluster en Base de données (utile pour la livraison)
Bonnes pratiques • ENVIRONNEMENT
Bonnes pratiques • ENVIRONNEMENT
Bonnes pratiques • INSTALLATION Il y a trois manière d’installer ezpublish : • Normal installation • Manuel installation • Automatiques installation La méthode d’installation normale est la façon la plus courante et la recommandée La base de données doit être créer avant le lancement de l’assistant de configuration. Ensuite télécharger ezpublish , le décompresser et enfin lancer « the setup wizard ».
Bonnes pratiques • INSTALLATION Ezpublish est livré avec des extensions , de plus il y a des extensions à mettre en place pour ne pas réinventer la roue comme: • Swark • Noveniniupdate • ….
Bonnes pratiques • CONFIGURATION Ce que l’on peut voir : • Des designs dans le répertoire racine /design • Des modifications directes sur les fichiers de configuration .ini • Duplication de configuration pour un accès au BDD (2 sites partagent la même BDD par exemple). Ce qu’il faudrait voir : • Le code d’une application développée avec ezpublish doit toujours se situer dans une extension ( design, settings, code PHP) • Une seule configuration sur les fichiers settings/override/*.ini.append.php
Bonnes pratiques • CONFIGURATION
Bonnes pratiques • CONFIGURATION Ce que l’on peut voir : • Des extensions avec pleines d’opérateurs, alors qu’on utilise qu’un seul. • url avec des /index.php Ce qu’il faudrait voir : • Collection des opérateurs dans une seule extension.
Bonnes pratiques • FRONT-END Ce que l’on peut voir : • Empilement de toutes les inclusions js/CSS sur toutes les pages. Ce qu’il faudrait voir : • Un seul fichier js/ ,un seul fichier CSS « mergé » et compressé (ezjscore/pm compress
Bonnes pratiques • FRONT-END Ce que l’on peut voir : • Anonymous possède tous les droits de lectures et plus. • Ne pas surcharger des vues, alors avec une petite recherche on se trouve avec : Ce qu’il faudrait voir : • Accès refusé , affichage désactivé… • Faire des redirections
Bonnes pratiques • TEMPLATES Ce que l’on peut voir : • (node_id, contentclass_id,) en dur, dans les templates • Textes non traduisibles • Des parties complexes du code dans les templates Ce qu’il faudrait voir : • (node_id, …) en fichiers des configurations • Texte traduisibles • Des templates avec un algorithme simple, si cela devient complexe, pensez à un opérateur de template ou fonction fetch.
Bonnes pratiques • TEMPLATES Ce que l’on peut voir : • Pour afficher des informations sur des nœuds enfants ou petits enfants, utiliser des fetches Ce qu’il faudrait voir : • Utiliser les variables $node.children et $node.children.0.children.
Bonnes pratiques • TEMPLATES Ce que l’on peut voir : • Des fecths avec trop de filtres. • Refaire des requêtes dans la pagelayout (colonne de droite, titre de page, ….) Ce qu’il faudrait voir : • Utilisation de l’extension ezfind dès que vous recherchez des nœuds avec des filtres trop complexes (permet de rechercher parmi plusieurs milliers d’objets en quelques ms) • Utilise l’opérateur Ezpagedata de l’extension ezwebin pour sortir les données du nœud vers la pagelayout
Bonnes pratiques • BACK OFFICE Ce que l’on peut voir : • Un compte admin partagé par tout le monde : développeur, webmaster, …. • Des webmaster autonomes dans le vidage de cache / configuration des classes / ajouter des droits, rôles • Une seule classe pour l’ensemble des fonctionnalités de site • Pas d’icones pour les classes de contenu. Ce qu’il faudrait voir : • Séparation des rôles / Configuration des droits • Créer des différentes classes même si elles ont une structures similaires • Créer des icones pour les classes. • Bloc text / bloc XML, il vaux mieux créer des datatypes bloc XML une fois il y a ce « réflexe »
Bonnes pratiques • API Ce que l’on peut voir : • Sql en dur dans les scripts • Modifier directement sur le KERNEL/Extensions (pour des problèmes contournables) Ce qu’il faudrait voir : • Utilisation de l’API • Pensez à persistent Object pour les tables sql custom • Faire des mise à jour aux extensions utilisés
Bonnes pratiques • AUTRES Ce qu’il faudrait voir : • Exécuter les scripts flatten.php et cleanup.php • Cache block (clé par groupe et non par user) • Profiter des EZpEvent pour savoir quel URL qui a générer le vidage complet de cache. • Éviter les directives all pour le fichier view-cache • Mode de debug • Changement d’environnement (l’extension : NovenINIUpdate)