CAO Faktura für Jungunternehmer

Jungunternehmer haben meist nicht viel Geld für Software übrig. Daher sucht man zu meist nach günstiger Software oder preiswerten Alternativen zu teurer Standardsoftware. Ich verwende nun schon seit Jahren CAO Faktura. Es existiert eine kostenlose wie auch eine kostenpflichtige Version.  Die kostenfreie reicht zumeist für den Anfang aus. Die Kostenpflichtige bietet jedoch ein paar Vorteile, die gerade in zusammenarbeit mit einem WebShop interessant sind. Eine Lizenz für die Kauf Version kostet 120€. Also auch für Jungunternehmer erschwinglich. Ich habe CAO bisher in unterschiedlichen Scenarien eingesetzt. Ob es nur für die Rechnungslegung für Dienstleistungen ist oder für einen Einzelhandelsgeschäfft, CAO kam bisher nicht an seine Grenzen. Da CAO mit einer MySQL Datenbank funktioniert, kann es mit mehreren Instanzen im Netzwerk verwendet werden. So kann z.B. im Büro der Warenbestand gemanaged werden, sowie Aufträge, Rechnungen, Lieferscheine oder Angebote geschrieben werden und an der Kasse die Kassenfunktionen von CAO genutzt werden. Alles wird dann über das Netzwerk mit der SQL DB abgeglichen und der Warenbestand ist an jedem Arbeitsplatz gleich.

Leider ist die Installation von CAO nicht ganz so intuitiv wie sie vllt. sein könnte. (Hierzu schreibe ich wahrscheinlich in den nächsten Tagen noch einen Eintrag Hier geht es zu Teil 1 der Installation) Das liegt zum Einen an der DB, die separat installiert werden muss und dazu leider auch nur sehr alte Versionen von MySQL unterstützt werden und zum Anderen an dem mächtigen Formulargenerator, der meine Kunde das eine oder andere Mal überfordert hat. Sind diese Hürden aber übersprungen, ist es eine sehr preiswerte WaWi.

http://www.cao-wawi.de/

 

Typo3 LTS Update 4.5 zu 6.2 Teil 2

So nach dem wir im ersten Teil die nötigen Grundlagen geschaffen haben, kümmern wir uns jetzt um das eigentliche Typo3 LTS Update. Wir deaktivieren Extensions, die definitiv nicht kompatibel sind (dies wird im Updateskript nochmal geprüft und gemeldet).  Ist auf der Seite Templavoila im Einsatz sollte es definitiv deaktiviert werden, das hat bei mir das Updateskript nicht erkannt, und dann kam es im ersten Anlauf zu einem Fehler. Dieser lies sich aber umgehen, in dem man TemplaVoila vor dem Update deaktiviert. Wir setzen nun noch die Webseite im Installtool Offline und löschen alles Caches(hat den Vorteil, dass die DB kleiner wird).

Wir kopieren, wenn nicht schon geschehen, die Typo3 LTS Sourcen der LTS Version 6.2 in unser Sourcen Ordner auf unserem Webspace. Nun melden wir uns wieder via SSH auf dem Server an um die Symlinks umzuziehen.
Wenn alles, wie im Teil 1 erklärt, gemacht wurde, brauchen wir nur einen Symlink ändern –  den für typo3_src. Dies machen wir mit:

ln -sf Typo3Sourcen/typo3_6.2.3 typo3_src 

Der Umnterschied bei dem Befehl zu dem aus Teil 1 ist das „f“. Dieses „f“ besagt, dass der Link erstellt werden soll, auch wenn er schon existiert. Dies bedeutet, der bestehende Link wird so zusagen überschrieben.

Das eigentliche Update

Wir haben nun die neuen Sourcen eingespielt. Nun geht es an das DB Update. Dazu gehen wir ins Installtool.

http://www.meinedomain.de/typo3/install

Nun sollte uns schon die neue Version begrüßen. Wenn es keine roten Kringel gibt, dann ist schon jetzt alles in Ordnung, soll heißen, die Checks die das Installtool durchführt wurden alle bestanden und wir können mit dem Updateskript fortfahren. Haben wir doch rote Kringel bei „System Environment“ oder „Folder Structure“ können wir schauen, ob wir sie lösen können. Es ist vom Installtool beschrieben, was im Einzelfall zu tun ist. Ihr könnt aber auch gerne hier Fragen.
Nun klicken wir auf Upgrade Wizard. Hier werden wir nun Schritt für Schritt durch das Update geführt. Ich hatte das Phänomen, dass es beim Prüfen der Extensions zu Problemen kam.
Die inkompatiblen Extensions konnten nicht entfernt werden. Ich habe diese dann via FTP gelöscht und dann das Updateskript weiter ausgeführt, ich hatte mit dem Weg keine weiteren Probleme.
Das größte System welches ich mit dem Verfahren hochgezogen habe, hatte eine 1GB große DB (nach dem löschen aller Caches vor dem Update).
Der Wizard erklärt jeden Schritt und zeigt auch die vorhanden Probleme an. Ich musste die veralteten Eigenschaften der RTE Config händisch anpassen, dass konnte der RTE nicht für mich erledigen. Glücklicherweise sagt mir aber das Tool welche Anweisungen veraltet sind und welche ich stattdessen nehmen sollte. Es sagt mir sogar, auf welchen Seiten diese verwendet werden. Auch wenn ihr diese noch nicht anpasst funktioniert die Seite weiterhin.
Jetzt löschen wir nochmal den Cache und loggen uns dann im  Backend ein. Es geht nun darum unsere Extensions wieder zu aktivieren. Dazu laden wir die Typo3 LTS 6.2 kompatiblen Extension runter und aktivieren sie. Habt Ihr Templavoila im Einsatz, müsst ihr es unbedingt updaten bevor ihr es reaktiviert, sonst kommt es zu Fehlern.

Typo3 LTS Update 4.5 zu 6.2 Teil 1

Das Typo3 LTS Update wird rückt immer näher. Es rückt immer näher, weil die reguläre Updateversorgung für die Typo3 LTS Version 4.5 im Oktober ausläuft. Bis dahin hat man also noch Zeit sich mit der neuen Version vertraut zu machen. Hat man in der 4.5 eigene Extension in Verwendung, so ist jetzt ein guter Zeitpunkt diese 6.2 fähig zu machen und warum davor nicht schonmal ein Backup vom Livesystem ziehen und in ein Testsystem verwandeln und dieses dann auf die neue Typo3 LTS Version updaten? Genau warum eigentlich nicht.

Das Typo3 LTS Update

Die Vorbereitungen

  1. Testinstanz einrichten
  2. Backup der Liveinstanz in Testinstanz einspielen
  3. Typo3 6.2 Sourcen download

Symlinks der Sourcen

Nun der eine oder andere mag sein System schon mit Symlinks aufgebaut haben, andere aber nicht.  Für die den Vorteil dieser Variante nicht kennen, man kann einfach verdammt schnell zwischen Typo3 Versionen herspringen. Sollte aus einem Grund die Instanz mit den neuen Sourcen nicht mehr funktionieren, so lenkt man einfach den Symlink zurück auf die „alten“ Sourcen.

Um dies aber nutzen zu können, brauchen wir aber entweder einen SSH Zugriff auf dem Server, oder der Server unterstützt SFTP. Ich gehe hier mal von ersterem aus.

Nun mal angenommen wir haben noch keine Symlinks. Wir erstellen uns zuerst einen Ordner für unsere Typo3-Sourcen auf unserem Webspace. Wie wir den nennen ist erstmal egal, nur nicht typo3_src.

Die Entwickler haben im Installtool ein paar Konventionen hinterlegt gegen die das System geprüft wird. Die für die Symlinks sind wie folgt:

  • typo3_src ist ein Symlink auf das aktuelle Typo3 Sourcen Verzeichnis (z.B. auf typo3_4.5.33 für die Version 4.5.33)
  • Der index.php Symlink zeigt auf die index.php innerhalb der Version. Dies erreichen wir, in dem wir den Symlink auf typo3_src/index.php setzen
  • Der typo3 Symlink zeigt auf den Ordner typo3 innerhalb von typo3_4.5.33 also auf typo3_src/typo3
  • Eine Spezialität gibt es bei den 4.x Versionen noch – der Ordner t3lib. Dieser existiert in den 6.x Versionen nicht mehr. Sollte für die alte Version aber auf typo3_src/t3lib zeigen.

Nun wissen wir auch warum wir den zuvor erstellten Ordner nicht typo3_src nennen sollten. Bevor wir die Symlinks nun erstellen, kopieren wir die Sourcen (Die Ordner: typo3 und t3lib sowie die index.php)  in unseren neuen Ordner in ein Versionsunterverzeichnis (z.b. typo3_4.5.33)

Btw. Man sollte eine alte Installtion der Typo3 LTS Version immer vorher auf die aktuelle Version des Branches updaten. Für die Typo3 LTS Version 4.5 ist das zum Zeitpunkt dieses Posts die Version 4.5.33.

Nun aber zum eigentlichen Symlinken. Wir nehmen an das  die Typo3 Versionen im Verzeichnis Typo3Sourcen liegen und wir uns auf der Shell im WebRoot befinden. Also Typo3Sourcen/typo3_4.5.33 und Typo3Sourcen/typo3_6.2.3.

  1. Zuerst den typo3_src Symlink:
    ln -s Typo3Sourcen/typo3_4.5.33 typo3_src
  2. dann der typo3 Ordner:
    ln -s typo3_src/typo3 typo3
  3. und zum Schluss die index.php:
    ln -s typo3_src/index.php index.php
  4. (für die 4.5.x noch nicht ganz der Schluss) die t3lib (nur für den Versionszweig 4)
    ln -s typo3_src/t3lib t3lib

Wenn wir nun unsere Testinstanz aufrufen, sollte alles wie gehabt funktionieren.

Im nächsten Teil geht es dann ans wirkliche Update.

Typo3 Extbase 1.3 Extension zu Extbase 6.2

Immer mehr Webseiten werden nun umgestellt. Es ist die neue Typo3 LTS Version erschienen. Ob es Sinn macht jetzt schon umzustellen muss jeder für sich selber entscheiden. Ich arbeite schon mit der neuen LTS Version und habe meine Projekte einem Update unterzogen. Die alte LTS Version 4.5 wird noch bis zum Oktober mit regulären Updates versorgt. Danach wird es reguläre Updates nur noch für die dann gültigen Versionen geben. Wir haben hier also eine Überschneidung der Versionen von ca. 5 Monaten. (Quelle: Typo3 Roadmap)

Typo3 Extbase Extension Update

So… die ersten Typo3 Extbase Extensions haben ein Update erfahren. Es sind alle samt Extensions gewesen, die für Typo3 4.5 LTS mit Extbase 1.3 entwickelt wurden. Ich möchte hier nun ein kleinen Überblick geben, was ich getan hab, damit die Extensions weiterhin funktionieren. Einen Post (Repository Error) über einen auftretenden Fehler habe ich ja schon veröffentlicht.  Hier nun der Generische zum Update 🙂

Das Repository

Das Repository darf jetzt initialisiert werden. Das heisst man kann seine Konfiguration auf die eigenen Bedürfnisse einfach anpassen. Ich mache dies in allen meinen Repositories, dann sehe ich gleich was in dem Repository Sache ist.

Hier ein Beispiel:

public function initializeObject() {
         /** @var $querySettings \TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings */
         $querySettings = $this->objectManager->get('TYPO3\\CMS\\Extbase\\Persistence\\Generic\\Typo3QuerySettings');
                 
         $querySettings->setRespectStoragePage(FALSE);
         

         $querySettings->setIgnoreEnableFields(TRUE);       
 

         $querySettings->setIncludeDeleted(FALSE);
 

         $querySettings->setRespectSysLanguage(FALSE);
 
         $this->setDefaultQuerySettings($querySettings);
     }

Die Konfig ist eigentlich selbsterklärend, oder?

Formulare und andere Objekte

Sollen in Formulare andere Objekte referenziert werden, so war es bisher möglich in Fluid einfach das Objekt als solches einzutragen. Fluid hat daraus dann das _identity – Feld gerendert und beim Absenden daraus wieder das Objekt generiert. Ich hatte nun das Problem, dass dieses _identity-Feld nicht validiert werden konnte, vermutlich, weil es ein sollches nicht im Objekt gab.  Es hat aber da schon gereicht, explizit die uid des objektes rendern zu lassen und nicht das komplette Objekt.

//Aus 
<f:form.hidden property="meinAnderesObjekt" value="{meinAnderesObjekt}" />

//wurde
<f:form.hidden property="meinAnderesObjekt" value="{meinAnderesObjekt.uid}" />

danach war die Validierung kein Problem mehr.

Reihenfolge der Parameter

Das war wirklich eine nervige Sachen. Ich hatte bei einer Action plötzlich Validierungsprobleme, die sich mit einer Exception äußerten. Konkret konnte ein String nicht zu dem geforderten Objekt konvertiert werden. Das Problem war, dass die Exception dazu nicht ganz so aussagekräftig war.  Aber ich hab es ja gefunden.

Es ist extrem wichtig, dass die Reihenfolge der Parameter in der Annotation die Selbe ist wie bei den Methodenparametern.

//Falsch:

/**
* @param string $arg1
* @param \Argument $arg2
*/
public function showAction(\Argument $arg2, arg1){
....
}


//RICHTIG:

/**
* @param string $arg1
* @param \Argument $arg2
*/
public function showAction(arg1, \Argument $arg2){
....
}

So das ist mir nun nachträglich wieder eingefallen. Leider hab ich mir nicht alles notiert. Ihr könnte aber gerne eure Probleme in die Kommentare posten.