- Fehler
Quelle (in Englisch): developper.joomla.org
Übersetzung: Joomla! Schweiz
Aufbauen von Joomla! Websites mit SVN
Von Andrew Eddie
Wenn Sie anfangen als Website-Gestalter oder -Entwickler Ihre Seite von Ihrer lokalen Arbeitstation aus zu betreuen, ist das noch nicht so schwierig. Aber sowie die Arbeitsbelastung immer grösser wird, andere Berater und Betreuer dazu kommen, so wird es auch komplizierter. Wie kann jeder gleichzeitig an derselben Inszenierung mitwirken? Wie kann ich meine Arbeit wiederherstellen welche jemand überschrieben hat? Was können Sie machen wenn ein Klient 18 Monate nach der Projektübergabe nach einer Kopie der Site fragt, weil sie versehentlich gelöscht wurde, und man selber alles irgendwo verlegt hat? Eine Möglichkeit zur Lösung dieser Fragen ist die Speicherung Ihrer Projekte in einer Quellcode-Vorratskammer. Es gibt verschiedene Arten von Endlager-(Repository)Konzepten, aber in dieser Anleitung wird der Schwerpunkt auf den Einsatz von Subversion (SVN) gesetzt, und wie das Minimum an Informationen im Endlager so wenig wie möglich Speicherplatz beansprucht. („Speicherplatz ist Geld“).
Diese Anleitung richtet sich an fortgeschrittene Joomla!-Webdesigner und -Entwickler, welche sich mit Mehrfach-Klienten beschäftigen (Kommerziell oder sonst wie) um sie in der eigenen Arbeit zu unterstützen oder in Projekten wo sie einer vom Team sind, welche an verschiedenen Aspekten einer Website arbeitet.
Finden einer Subversion-Repository
Wenn Sie schon wissen, wie man ein Subversion-Repository auf der eigenen Arbeitsstation einrichtet, können sie diesen Abschnitt überspringen. Wenn sie aber jemand sind der gesehen hat wie Arbeitkollegen sich die Haare ausgerissen haben wegen Webdav (offener Standard zur Bereitstellung von Dateien im Internet) und anderem Zeugs, dann gibt es Sites welche Subversions-Dienste anbieten.
Die Joomla!Code-Site bietet Subversion-Repository an für Entwickler-Projekte. Bitte beachten Sie: was in dieser Anleitung gezeigt wird, ist in Joomla!Code nicht erlaubt. Benutzen Sie nicht Joomla!Code für private oder kommerzielle Website-Projekte (Erweiterungen Ja, ganze Websites Nein).
Da wir dies nun geklärt haben schlage ich vor, dass wir uns zuerst mal den Australischen Service Provider CVSDude anschauen. Das schöne an CVSDude ist, dass es einen gratis Einstiegslevel anbietet mit genügend Speicherplatz um auf den Geschmack zu kommen. Wenn Sie den Einstiegsplan erschöpft haben gibt es einige Angebotspläne mit sehr vernünftigen Preisen gemäss Ihren Bedürfnissen.
Für grössere Website-Projekte, mit mehreren Entwicklern (wie mich für Erweiterungen-Entwicklung) sowie ein oder mehrere Designer (für Template-Arbeiten), empfehle ich oft ein eigenes CVSDude-Konto einzurichten für das Beraterteam zur gemeinsamen Entwicklung, während das Projekt wächst. Danach haben Sie die Option das Konto weiter zu behalten als sozusagen Wiederherstellungs-Backup oder geben es auf. Ein Drei-Monate-Projekt kann unter $20 kosten um einen Speicherort zur gemeinsamen Entwicklung zu haben. Einige Pläne kommen auch mit „Trac wiki“ und „Bugzilla“ Support.
Wenn Sie sich für ein CVSDude-Konto anmelden, müssen Sie als erstes ein Modul einrichten. Eigentlich nur ein „Kübel“ in welchem die Entwicklung statt finden kann. Der Modulname kann etwas mit Bezug zum Projekt sein, ich brauche meist nur ein einfaches „sites“.

Abhängig vom gewählten Konto können Sie eventuell mehrere Module einrichten. Für die meisten Projekte oder auch einzelne Klienten, genügt ein Modul. Falls Sie mehrere Websites für den gleichen Klienten machen können Sie zum Einzelmodul einfach Unterverzeichnisse anlegen.
Ihr CSVDude-Plan kann Ihnen mehr oder weniger Flexibilität anbieten in Bezug auf zusätzliche Nutzer. Für die höheren Pläne können Sie möglicherweise einen Zugang einrichten; für jeden reellen Benutzer vom Team. Für die tieferen Pläne mache ich gewöhnlich einen generellen Benutzer. Zum Beispiel für den "Startup"-Plan gibt es zwei Benutzer, also mache ich einen Klienten_Name_Entwickler und einen Klienten_Name_Designer um wenigstens unterscheiden zu können zwischen den "Coders" und "Templaters". Es ist offensichtlich besser wenn man die einzelnen Eingaben (commits) der Benutzer verfolgen kann, man muss dies jedoch mit den extra Kosten vergleichen. Es bleibt ihnen überlassen wieviel sie Ausgeben wollen.
Zu diesem Thema gibt es nicht mehr viel zu sagen. Wenn Sie Ihr Modul und die Benutzer angelegt haben, können Sie sich durch HTTP mit einer URL zur Subversion zu Ihrem aktuellen Klienten verbindend; etwa so: http://ein_name-svn.cvsdude.com/sites. Weitere Informationen zu "desktop clients“ kann in meiner Source-Code-Seite gefunden werden (http://developer.joomla.org/tutorials/207-setting-up-joomla-sites-with-svn.html). Die meisten Linux-basierenden Server sollten mindestens die SVN Command-Zeilen-Applikation installiert haben, wenn sie ihren eigenen Hosting Server betreiben ("shared hosting"-Lösungen vermutlich nicht).
Einrichten und Importieren zum SVN Repository
So, Sie haben Ihr "Subversion Repository“ einigermassen eingerichtet. Was nun?
Was wir nun einrichten müssen ist eine Verzeichnis-Struktur um in das Repository zu importieren. Wir installieren nicht die Joomla!-Site als erstes Set – das kommt später.
Importieren des Basis-Verzeichnisses (Base Directory)
Nehmen wir an, Sie betreiben Ihre Site in einem Verzeichnis mit dem Namen /htdocs/projects/mightymeats/ (wobei „mightymeats“ mit einem bedeutungsvollerem Namen ersetzt werden kann (Mighty Meats ist der Name der Metzgerei meines Vaters, falls es jemanden interessieren sollte). Nun, die nächsten Schritte sind etwas bizzar, doch es funktioniert, also bleiben sie dran. Wir müssen:
- Das mightymeat-Verzeichnis in das Repository importieren
- Das mightymeat-Verzeichnis lokal löschen
- Auschecken vom mightymeat-Verzeichnis vom Repository nach unserem lokalen Datei-System.
Beim Benutzen einer Linux style Kommandozeile, würden sie es so machen:
$ mkdir mightymeats
$ svn import -m "Initial import" mightymeats http://some_name-svn.cvsdude.com/sites/mightymeats
Committed revision 1.
$ rmdir mightymeats
$ svn checkout http://some_name-svn.cvsdude.com/sites/mightymeats mightymeats
Checked out revision 1.
$ ls -al mightymeats total 0
drwxr-xr-x 3 admin admin 102 Jul 22 10:34 .
drwxr-xr-x 7 admin admin 238 Jul 22 10:34 ..
drwxr-xr-x 9 admin admin 306 Jul 22 10:34 .svn
Sie sehen also, wir haben das Verzeichnis kreiert und es gibt auch verborgene .svn-Verzeichnisse darin. Das bedeutet, dass das Verzeichnis nun unter "source control" ist.
Unter Windows würden Sie wahrscheinlich etwas wie TortoiseSVN benutzen. Die Schritte mit TortoiseSVN sind etwa so:
- Neues Verzeichnis kreieren
- Rechts-Klick auf das neue Verzeichnis
- Importoptionen auswählen
- URL eingeben was man oben in der Befehlszeile sieht und Import starten
- Das neue Verzeichnis löschen
- Rechts-Klick in das "parent"-Verzeichnis
- Checkout anwählen
- URL eingeben welche man oben in der Befehlszeile sieht und Checkout starten
Wenn Sie Eclipse benutzen (ich selber benutze das EasyEclipse), dann würden Sie das Verzeichnis erstellen, auf diesem Verzeichnis ein Projekt kreieren, und dem Team -> Sharing Wizard folgen.
Das Haupt Joomla! Verzeichnis kreieren
Mit dem obersten Verzeichnis unter "source control" haben wir die beste Grundlage um nun unsere Site zu bauen. Für typische Projekte möchten Sie nun das gesamte Joomla!-Verzeichnis-System im Repository einordnen. Würde man dies für jedes Projekt machen, wäre schnell die ganze verfügbare Speicherkapazität aufgebraucht. Besser, wir errichten eine Verzeichnisstruktur mit identischen Kennzeichen von der Joomla!-Verzeichnisstruktur in die Struktur wo wir die einzelnen Projekt Verzeichnisse haben.
Die Hauptregel, welche man in Erinnerung behalten muss ist, dass wir ja im Repository etwas hinterlegen wollen. Darum müssen alle übergeordneten Ordner auch im Repository sein. Das beste Beispiel dazu ist das Template welches wir für die Site benutzen. Sagen wir mal, wir wollen das Joomla!-Template "Content entry javanya" für die Site. Um das "javanya Template" zu übergeben, muss das Verzeichnis /template/ ebenfalls unter "source control" sein. Auf die gleiche Art wie wenn wir ein massgefertigtes Modul in die Site aufnehmen wollen, würden wir auch das Verzeichnis /modules/ in die "source"-Struktur aufnehmen. Mit all dem in Betracht, hier nun die Basis-Verzeichnis-Struktur welche ich dem Repository übergebe.
Für Linux, oder ähnlich, wenn im Verzeichnis /mightymeats/ :
mkdir -p administrator/modules
mkdir -p administrator/language/en-GB
mkdir -p components
mkdir -p images/banners
mkdir -p images/stories
mkdir -p language/en-GB
mkdir -p libraries
mkdir -p modules
mkdir -p plugins/content
mkdir -p plugins/search
mkdir -p plugins/authentication
mkdir -p plugins/system
mkdir -p plugins/user
mkdir -p templates
Für Windows wenn im Verzeichnis /mightymeats/ :
mkdir administrator/modules
mkdir administrator/language/en-GB
mkdir components
mkdir images/banners
mkdir images/stories
mkdir language/en-GB
mkdir libraries
mkdir modules
mkdir plugins/content
mkdir plugins/search
mkdir plugins/authentication
mkdir plugins/system
mkdir plugins/user
mkdir templates
Je nach Ihren kundenspezifischen Bedürfnissen benötigen Sie möglicherweise weitere Verzeichnisse (zum Beispiel das Administrator /template/ Verzeichnis wenn Sie eine eigene Version vom Administrator-Template wünschen), jedoch die Liste wie oben dargestellt beinhaltet die meisten typischen Fälle.
Übergeben der Haupt Joomla! Verzeichnisse
Unser nächste Schritt ist die Übergabe der Verzeichnisse an das Repository. Ich zeige nur die „Kommando-Zeilen-Version“ da es ziemlich einfach ist diesen Vorgang zu übersetzten für GUI basierende Werkzeuge (Tortoise oder Eclipse).
Zuerst fügen sie die Verzeichnisse in das Repository ein. Dann im /mightymeat/ Verzeichnis folgende Befehle ausführen:
A administrator
A administrator/components
A administrator/language
A administrator/language/en-GB
A administrator/modules
A components
A images
A images/banners
A images/stories
A language
A language/en-GB
A libraries
A modules
A plugins
A plugins/authentication
A plugins/content
A plugins/search
A plugins/system
A plugins/user
A templates
Das sollte ein sehr kurzer Vorgang gewesen sein. Er markiert nur lokal, dass Sie alle Verzeichnisse im Repository haben wollen, aber sichert sie nicht wirklich. Um das zu erreichen, müssen wir die Verzeichnisse dem Repository übergeben, etwa so:
Adding administrator
Adding administrator/components
Adding administrator/language
Adding administrator/language/en-GB
Adding administrator/modules
Adding components
Adding images
Adding images/banners
Adding images/stories
Adding language
Adding language/en-GB
Adding libraries
Adding modules
Adding plugins
Adding plugins/authentication
Adding plugins/content
Adding plugins/search
Adding plugins/system
Adding plugins/user
Adding templates
Verpflichtete Überprüfung 2.
Dies benötigte wohl etwas mehr Zeit (verglichen mit vorher), weil nun die Verzeichnis Informationen selber in das Repository versandt wurden. Die finale Anzeige der Revisionsnummer ist immer ein gutes Zeichen das die Operation gut verlaufen ist.
Joomla! auffahren
Nun sind wir bereit um die Joomla! Site aufzufahren und da gibt es verschiedene Wege das zu tun.
Der erste Weg ist die neuste Version von Joomla!Code herunterzuladen (oder Verwendung einer vorhandenen) und wie gewohnt Auspacken (durch die Befehlszeile oder eines Extraktions-Werzeug wie 7-Zip)
Der zweite Weg führt durch den Export direkt vom Joomla! Source code Repository. Der Befehlzeilenweg das zu tun ist via:
A .
A index2.php
A media
A media/system
A media/system/swf
A media/system/swf/uploader.swf
A media/system/images
A media/system/images/closebox.png
... und so weiter
A libraries/openid/README
A CHANGELOG.php
Exportierte Revision 10576
Stellen Sie sicher, dass Sie im entsprechenden Verzeichnis wie /mightymeats/ sind und beachten Sie den "Punkt" am Ende (welcher zum Export als "hier" übersetzt). Wenn Sie diesen "Punkt" verpassen, geht der Export in Unterverzeichnisse. Wir benutzen die "force option" um zu sicherzustellen, dass der Subversionsexport durch die Hauptverzeichnisse führt. Diese Operation benötigt eine gewisse Zeit.
Ich empfehle die direkte Export-Methode nur, wenn Sie eine aktuellste Joomla!-Version benötigen (vermutlich weil ein paar Fixes dabei sind). Für produktive Sites empfehle ich generell nur die letzten stabilen Dateien.
Zum Joomla! Updaten mit neuer Version, einfach die Schritte von oben wiederholen. Bitte nicht vergessen: weil Sie einen Export machen, jegliche Ordner welche von der offiziellen Distribution entfernt wurden sind nicht von Ihrer lokalen Site entfernt.
Tipp: Übertragen Sie nie "configuration.php" zum Repository, es wird Fehler geben zu den lokalen Installationen anderer Ihres Teams und in der produktiven Site. Es ist eine gute Idee, das „configuration.php“ mit „ignore“ Zeichen zu markieren damit es nicht versehentlich übertragen wird.
Installieren und Übertragen von Erweiterungen
Der Bedarf und Umfang Ihres Projekts ist entscheidend, ob Ihre Erweiterungen zum Repository übertragen werden oder nicht.
Wenn Sie nur Template-Designer sind, und alles was Sie zum Projekt beitragen ist das Template, dann brauchen Sie möglicherweise keine andere Erweiterungen zum Repository zu übertragen. Alles was Sie wohl brauchen sind nur die Daten zur Templatearbeit von Ihnen und ein paar eigene Module, etc.
Wenn jedoch eines der Ziele ist für mehrere Leute die Wiederherstellung vom Datensystem für die Site sicherzustellen, dann ist es eine gute Idee andere Erweiterungen in das Repository zu übertragen.
Um das zu tun, würden Sie die Erweiterungen einfach normal installieren. Wir haben bereits alle Installationspunkte im Repository eingefügt (/components/, /modules/, etc), nun, nach der Installation, müssen Sie nur die Erweiterung beifügen und dann übertragen.
Zum Beispiel möchten Sie die "Fireboard extension" installieren. Sie würden die "com_fireboard"-Verzeichnisse (Frontend und Backend) zum Repository hinzufügen (die meisten Tools erzeugen die Unterverzeichnisse selber), und dann würden Sie diese Verzeichnisse übertragen. Machen Sie das gleiche für jegliches Module oder Sprachdatei.
Nun, hier müssen Sie vorsichtig sein! Ausser Sie haben einen speziellen Grund, wollen Sie nie den Joomla! Source Code in das Repository übertragen. Es ist sehr leicht möglich es irrtümlich zu tun, also Vorsicht! Wenn Sie die Befehlszeile benutzen, machen Sie auf sicher das korrekte Verzeichnis beizufügen und zu übertragen. Wenn sie GUI-Werkzeuge benutzen, nur Rechts-Klick (oder ähnlich) auf das Verzeichnis das Sie wirklich beifügen und übertragen wollen.
Erneuern und Entfernen von Erweiterungen
OK, hier ist ein zweites Gebiet wo sie Vorsichtig sein müssen. Einige Joomla! 1.5 Entwickler benutzen die Methode ="upgrade" flag in deren Paketen, welches ihnen erlaubt die neue Version wieder zu Installieren ohne die Alte Erweiterung vorher zu löschen (wie man es im 1.0 machen musste). Das hat mindestens eine Auswirkung auf ihre lokale Kopie. Es bedeutet meistens, dass sie einige zusätzliche Ordner beifügen müssen und andere übertragen die gewechselt haben. Wiederum, müssen sie mit Ordnern welche entfernt wurden vorsichtig sein.
Wenn Sie eine Erweiterung komplett entfernen wollen, oder erneuern durch entfernen der alten Kopie, müssen Sie auch die Verzeichnisse im Repository löschen. Auch wenn Sie die Erweiterung vom lokalen Rechner mit dem Joomla! uninstall Prozess entfernen, beim nächsten updaten vom Repository sind sie wieder da.
Die Site an einen neuen Ort verlegen
Es ist eine Sache die Site lokal am funktionieren zu haben, und alle Ordner sorgfältig zum Repository übertragen. Aber wie verlegt man diese Site an einen anderen Ort?
Grundsätzlich folgen sie den meisten Schritten welche sie gebraucht haben um die Site zu kreieren.
- Bei Ihrem externen Server einloggen
- Das Repository in der Web root (oder entsprechendem Ort) von ihrer Web Site aus-checken.
- Joomla! herunterladen und entpacken oder direkt vom Joomla!Code SVN exportieren.
- Manuell die configuration.php-Datei schreiben.
- Exportieren der lokalen Datenbank (mit „phpMyAdmin“ oder ähnlichem)
- Ihre externe Datenbank einrichten und importieren von ihrem lokalen Export.
Beim Benutzen von Linux style Befehlen (und dem benutzen von Beispieldateien), würden sie Befehle eingeben ähnlich wie die Folgenden:
$ svn checkout http://some_name-svn.cvsdude.com/sites/mightymeats .
A administrator
A administrator/language
A administrator/language/en-GB
A administrator/components
A administrator/modules
A plugins
A plugins/authentication
A plugins/system
A plugins/search
A plugins/content
A plugins/user
A language
A language/en-GB
A components
A images
A images/banners
A images/stories
A modules
A libraries
A templates
Ausgecheckte Revision 2.
Wahrscheinlich werden Sie nach einem Passwort gefragt, wenn Sie das Erste Check-out versuchen, wie zum Beispiel:
Password for 'foobar':
Normalerweise "foobar" ist als was sie im Server eingeloggt sind, und das unterscheidet sich zum Benutzernamen mit welchem Sie zum Repository verbinden. Einfach "Eingabe" drücken, dann erscheint die Anfrage für Benutzer und Passwort. Nachdem Sie dies das erste Mal gemacht haben, sollten Ihre Verbindungsangaben im Cache vom Server sein.
Tipp: Wenn Sie sich auf einem Kundenserver befinden, wollen Sie nicht riskieren dass Ihre Zugangsdaten zum privaten Subversion-Server im Cache landen, deshalb benutzen ie die --no-auth-cache option mit jeglicher Subversionsoperation. Der Nachteil ist, dass Sie jedesmal Benutzername und Passwort eingeben müssen, aber das ist der Preis der Sicherheit.
Als nächstes holen wird das Joomla! Paket mit einer vorher erwähnten Methode. Diesmal holen wir das Paket direkt bei Joomla!Code mit „wget“ und packen es aus.
. . . mit grossem Durchlauf über den Draht
11:47:07 (586 KB/s) - `Joomla_1.5.4-Stable-Full_Package.tar.gz' saved [4162842/4162842]
$ tar -xzf Joomla_1.5.4-Stable-Full_Package.tar.gz$
Endlich, - kopieren Sie die Datenbank und machen sie die „configuration.php“.
An diesem Punkt ist es wichtig für Sie einen "Punkt der Wahrheit" für Ihre Daten festzulegen. Ist es Ihre lokale Site, oder die externe Site? Das ist eine Frage, welche Sie mit sich selber und Ihrem Team klarstellen müssen.
Wenn Sie eine Änderung lokal machen und Sie wollen die Reflexion auf dem externen Server sehen, einfach beim Server einloggen und zum „web root“ Verzeichnis navigieren. Dann werden Sie ein update Kommando auslösen, wie folgt:
$ svn update
A modules/mod_signup
A modules/mod_signup/view.php
A modules/mod_signup/mod_signup.xml
A modules/mod_signup/index.html
A modules/mod_signup/mod_signup.php
A modules/mod_signup/tmpl
A modules/mod_signup/tmpl/default.php
A modules/mod_signup/tmpl/index.html
Update zu Revision 3.
Wenn keine Veränderungen seit dem letzten Update gemacht wurden, sehen Sie nur die aktuelle Version Nummer vom Repository, ansonsten sehen Sie eine Liste der Daten welche verändert, beigefügt oder gelöscht wurden. Wenn Sie sicher sind Änderungen gemacht zu haben, dann überprüfen Sie ob sie vergessen haben die geänderten Daten zu übertragen
Schlussfolgerung
Diese Anleitung versucht die Methode zu umschreiben wie ich sie die letzten Jahre für kleinere und grössere Joomla! Projekte angewendet habe. Hoffentlich hilft es ihnen ihre Produktivität zu erhöhen und die Verlässlichkeit wie sie Web Sites ausführen. Doch glücklicherweise ist das nicht das Ende der Geschichte weil es immer noch weitere Tips und Tricks gibt um oben erwähnten Prozesse zu Automatisieren – insbesondere im Updaten ihrer Web Site mit vielen Komponenten durch benutzen von „Phing“. Aber bis ich dazukomme die nächste Anleitung zu schreiben, hoffe ich sie haben Spass ihre Projekte in die Subversion zu übertragen.



0 Kommentare