Bonnes pratiques ez publish

Présentation au sujet: "Bonnes pratiques ez publish"— Transcription de la présentation:

1 Bonnes pratiques ez publish

2 Sommaire ENVIRONNEMENT Installation Configuration Front END Api AUTREs
templates Back end Api AUTREs

3 Bonnes pratiques ENVIRONNEMENT ORGANISATION
Utilisation de même IDE pour les développeurs. Installer les plugins (smile ezpublish, 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)

4 Bonnes pratiques ENVIRONNEMENT

5 Bonnes pratiques ENVIRONNEMENT

6 Bonnes pratiques INSTALLATION
Il y a trois manière d’installer ez publish : 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 ».

7 Bonnes pratiques INSTALLATION
Ez publish 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 ….

8 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

9 Bonnes pratiques CONFIGURATION

10 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.

11 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

12 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

13 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.

14 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.

15 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

16 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 »

17 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

18 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)