Urdu Français
English English Deutsch Deutsch Español Español Français Français Italiano Italiano Nederlands Nederlands Português Português Русский Русский Ελληνικά Ελληνικά
Login



 

Copie de travail Joomla! extension

Démo
Téléchargements
Joomla! 1.5
Version 1.0.1
Télécharger
Forum
Tutoriel
Googlecode

Abstrait

C'est une sorte de Subversion pour Joomla! vivre le site. Idées de projets GSoC 2009: Copie de travail de Joomla en direct du site

Idée & Benefits

Les administrateurs travaillent généralement sur leur site en direct directement et parfois ils le font des erreurs comme tous les gens font. En conséquence, le site en direct se sali après l'extension d'installation / désinstallation processus et re-configuration. L'idée est d'avoir une copie de travail du site en direct et apporter des modifications à ce sujet, puis, si tout va bien après quelques tests, vous pouvez approuver les changements et l'outil sera de les appliquer à votre site en direct.

Je voudrais également mettre en œuvre certaines caractéristiques de base de Subversion dans ce projet, par exemple s'engager / d'approuver, mettre à jour / synchronisation, revenir en arrière, de fusionner, de créer des patch, appliquez le patch (SVN opérations par la suite).

Grâce à cet outil, les gens vont faire moins d'erreurs sur le site en direct et obtenir moins nerveux!

Jalons

Création d'une API et une interface sera nécessaire pour achever ce projet. Ils ont tous deux seront développés simultanément pour faciliter les tests en mesure de l'interface. Je vais garder les idées principales de codage et les normes de Joomla! Cadre en espérant qu'il y aura une partie de Joomla! 1.6 à l'avenir.

Pendant le processus de développement, je suppose que le site en direct (maître ou d'un parent après) et la copie de travail (après l'enfant) sont en cours d'exécution sur les mêmes versions et configurations de système d'exploitation / Apache / MySQL / PHP, et la configuration du serveur restera intact ( cet outil ne peut être qu'un environnement de test pour SERVEUR RE-CONFIGURATION).

Maintenant, je vais décrire en général ce que ce sera et comment il sera facile de travailler avec. Voici quelques étapes que les administrateurs peuvent faire:

  1. Créez autant de childs du maître à travailler sur eux (l'administrateur peut créer même un grand enfant)
  2. Modifier l'enfant (re-configurer, ajouter / modifier du contenu, installer / désinstaller / mettre à jour les extensions) et test (on peut avoir un "bot espion" si nécessaire sur l'enfant afin de déterminer les modifications apportées facilement)
  3. Approuver les modifications apportées au site en direct avec un de ces options:
    1. Créer un patch de l'enfant
    2. Appliquer le patch pour le maître
    3. Directement approuver les modifications au maître (en réalité il peut le faire 3.1 puis 3.2, juste en une seule étape)
  4. Voir les modifications apportées sur l'enfant
  5. Synchroniser l'enfant avec le parent (lorsque l'enfant n'est pas à jour)
  6. Revenir à l'enfant de la mère-patrie
  7. Fusionner les sites 2 (maître-enfant ou l'enfant-enfant) avec intégrité référentielle

Il ya des possibilités d'apporter des modifications 2 sur le Joomla! site web, ce qui est de changer la base de données et / ou système de fichiers. Il y aura donc des types de 2 fonctions de l'API, ce qui apportera des modifications à la base de données et le système de fichiers.

Travailler avec le système de fichiers est la partie la plus facile, parce que chaque fichier possède date de dernière modification, ce qui rend facile de déterminer quel fichier est plus récent.

Travailler avec la base de données est beaucoup plus compliqué, car il peut être de différents scénarios avec les relations.

Mon but est de faire une API, qui mettra en œuvre les opérations SVN non seulement aux tables de base, mais aussi à 3rd tables de fête, qui ne peut venir avec des extensions des partis 3rd.

Les améliorations futures

Il est également possible d'avoir une table d'historique (#tablename_history) pour chaque table de db, qui gardera les versions de lignes de table en elle. Il permettra aux versions de la base de données entière. Non seulement le contenu, mais aussi des paramètres, des emplacements de modules, etc seraient versionné. L'autre chose, qui peut être fait, c'est d'avoir des tables de langue et de conserver les traductions lignes d'un tableau en eux.

Chronologie

Avril 20 - mai 17: Temps de parler avec LE MENTOR
Semaine 1 mai 18 - 22: Interface et fonctions de l'API pour faire un enfant à partir du maître. (1)
Semaine 2 mai 25 - 29: Fonctions de l'interface et de l'API pour afficher les modifications effectuées sur l'enfant. (4)
Semaine 3 Juin 1 - 5: Interface et fonctions de l'API afin de repasser l'enfant. (6)
Semaine 4 Juin 8 - 12: Interface et fonctions de l'API pour synchroniser l'enfant. (5)
Semaine 5 Juin 15 - 19: Interface et fonctions de l'API pour créer un patch. (3.1)
Semaine 6 Juin 22 - 26: Fonctions de l'interface API et d'appliquer le patch. (3.2, 3.3)
Semaine 7 Juin 29 - Juillet 3: SE PRÉPARER À L'ÉVALUATION À MI-PARCOURS
Semaine 8 Juillet 6 - 10: PRÉSENTATION DE L'ÉVALUATION À MI-PARCOURS
Semaine 9 Juillet 13 - 17: Interface et fonctions de l'API de fusionner les sites 2. (7)
Semaine 10 Juillet 20 - 24: Temps réservé
Semaine 11 Juillet 27 - 31: Temps réservé
Semaine 12 Août 3 - 7: PREPARATION POUR L'évaluation finale, de tout mettre en LEURS PLACES
Semaine 13 Août 10 - 14: CRAYONS EN BAISSE, LES RESULTATS RECAPITULATIF, la documentation en
Semaine 14 Août 17 - 21: PRÉSENTATION DE L'ÉVALUATION FINALE
Août 22 - 25: LE TEMPS DES décisions de dernière minute

Webinar

Cliquez pour écouter le texte en surbrillance!