WhatsInside bei der GründerGarage

WhatsInside Werbebanner

WhatsInside ist im StartUP Wettbewerb der GründerGarage für das öffentliche Voting zugelassen worden.

Was ist WhatsInside?

WhatsInside ist eine Lebensmittelsuchmaschine, die Verbrauchern ihre Verträglichkeit unterschiedlicher Lebensmittel anzeigt. Dazu geben Verbraucher auf der Webseite einfach ihre Präferenzen ein und erhalten beim Scannen eines Barcodes mit der App die Anzeige, ob ihnen das Produkt bekommt oder eben nicht.

WhatsInside soll also die Vielfallt in der Ernährung wieder herstellen, in dem die Verbraucher nicht jede Zutatenliste lesen müssen.

Bitte voted für WhatsInside bei der GründerGarage:

https://www.gruender-garage.de/ideenwettbewerb/2/654/

Service für Gastronomen

Am 13. Dezember tritt eine neue Lebensmittelkennzeichnungs Verordnung in Kraft. Ab dem Zeitpunkt müssen Gastwirte ihre Speisen in den Speisenkarten nach Allergenen kennzeichnen. WhatsInside wird für die Gastronomen den Service bieten, ihre Rezepte auf die zu Kennzeichnenden Stoffe zu überprüfen und auszuweisen.
Das hat für Gastronomen auch noch einen anderen Vorteil, sie bieten dadurch ihren Gästen eine transparente Karte. Ein Verbraucher, der die Platform verwendet, kann sich dann die Gerichte filtern, die ihm bekommen bzw. teile von den anderen Gerichten abbestellen.

 

Typo3 Flow XDebug

Typo3 Flow ist ein mächtiges Framework und ich muss sagen, es macht echt Spaß damit zu arbeiten. Allerdings ist das Debuggen etwas umständlich. Entweder, man debuggt die Proxy Klassen, dafür muss man aber immer vom POI (Point of Interest) weg oder man erstellt ein Mapping.

Sebastian Kurfürst von Sandstorm Media hat einen Pfadmapper umgeschrieben, der das Mapping für Flow übernimmt. Dazu gibt es auch ein Tutorial von ihm. Dabei werden die Debug Kommandos die die IDE und XDebug austauschen auf die Pfade angepasst. Dass heisst ihr könnt in euren Klassen Haltepunkte setzen und diese werden dann auch angesprungen.

Wenn ihr alle Daten auf eurem System habt und auch der Webserver lokal läuft ist das alles kein Problem, es funktioniert wunderbar.

Typo3 Flow xDebug auf einem Remoteserver

Problematisch wird es erst, wenn die Daten und dem Webserver extern sind. Der PathmappingProxy wird lokal ausgeführt und dieser verbindet sich dann mit xDebug auf dem Server. Man wird aber feststellen, dass das Mapping so nicht funktioniert. Da im Pathmapper von der Server Flow Uri ausgegangen wird, die aber nicht zwangsläufig mit der Datenbasis URI in der IDE übereinstimmt. Der Pathmapper schaut aber nach, ob er auf die Datei zugreifen kann. Kann er das nicht, kommt kein Mapping zustande. Wir müssen also dem Pathmapper noch die lokale Pfadangabe übergeben, damit er prüfen kann, ob die Datei existiert.

Dazu habe ich in dem Debugproxy von Sebastian einen weiteren Parameter eingefügt. Mit dem Parameter kann man nun den Lokalen Pfad mit übergeben. Wichtig ist dabei, dass dies momentan nur im LAN funktioniert, da ich nach wie vor einen Filezugriff auf die Daten benötige. Ich prüfe jetzt nur noch zusätzlich, ob die Proxydatei unter der übergebenen BaseURI + Pfad existiert. Diese können nur auf dem Server selber existieren, da sie zur Laufzeit geändert werden.

Mein Aufbau ist also wie folgt:

Dedizierter Entwicklungsserver im LAN mit Dateifreigabe
Netbeans IDE am Entwicklerrechner (Netbeans arbeitet mit der Datei freigabe)
Debugproxy.php auf dem Entwicklerrechner mit „lokaler“ Pfad übergabe (z.B. als Netzlaufwerk) -b Argument

Ich starte also die Debugproxy.php lokal mit

php pfad/zum/proxy/debugproxy.php -f -c Development -b V:/Flow

V:/Flow steht für mein Netzlaufwerk mit meinem Projekt zum Debug.
Sollte aus irgendeinem Grund die Möglichkeit der Dateifreigabe versagt sein, kann man auch FTP verwenden. Das Argument ist -r gefolgt von den FTP Daten zusätzlich gibt man mit dem -b Argument den ServerPfad zum Projekt an:

php debugproxy.php -f -d -c Development -b /var/www/flow -r flow.intern;user;pass

Ich hoffe dies hilft dem einen oder anderen weiter 🙂

Und hier der gepatchte DebuggerProxy:

git clone https://github.com/mrwhy-orig/debugproxy.git

 

CAO Faktura Installation – Teil 2 CAO Faktura

Im ersten Teil habe ich erklärt, wie der MySQL Server zu installieren ist. Wenn dies wie beschrieben befolgt wurde, sollte es nun keine Probleme geben. Das häufigste auftretende Problem ist, dass das Passwort nicht passt. Das soll heißen, dass in der DB das Passwort für den Datenbank Benutzer nicht mit der „OLD_PASSWORD“ Funktion gesetzt wurde. Wie das geht lest ihr im vorherigen Post.

CAO Faktura installieren

Wir entpacken das ZIP auf unserem Rechner. Zur Erinnerung das Zip haben wir im Teil 1 von folgender Stelle heruntergeladen:

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

Wir starten nun das Setup Programm und hangeln uns durch die Dialoge. Der erste Dialog begrüst uns, hier einfach auf „Weiter“ klicken. Beim erscheinenden Dialog lesen wir die Lizenzvereinbarung und akzeptieren diese. Es folgt die Frage, wo wir CAO Faktura installieren möchten. Wir wählen einen Pfad und klicken auf „Weiter“. Auch die Verknüpfungsfrage bestätigen wir mit Weiter. Im Folgenden Dialog können wir wählen, wo überall Verknüpfungen angelegt werden sollen. Klicken wir auf Weiter, erhalten wir eine Zusammenfassung unserer Auswahl. Mit dem Klick auf Installieren werden die Programme installiert.

Nun kann es mit CAO Faktura losgehen

Wir haben CAO Faktura jetzt installiert, aber was nun? Wir müssen als erstes einen Mandanten anlegen. Unsere Datenbank ist noch völlig leer. Dazu starten wir das Programm CAO Admin.

Wir können hier direkt einen neuen Mandanten anlegen, dazu klicken wir auf „Neu“. Damit öffnet sich ein neues Dialogfenster.

neuerMandant

Dem Mandanten geben wir nun einen Namen im Feld Mandant.
Bei Server tragen wir die IP Adresse unseres MySQL Servers ein. Ist es der gleiche Rechner können wir auch „localhost“ oder „127.0.0.1“ eingeben. Den Port lassen wir auf 3306 es sei denn er wurde während der MySQL Serverinstallation geändert.
Bei Datenbank geben wir den Namen unserer Datenbank ein „cao“.
Bei Benutzer den angelegten Datenbankbenutzer „caouser“.
Bei Paßwort das Benutzerpasswort „caouserpass“.
Mit klick auf Einstellungen testen, sollte nun eine Erfolgsmeldung kommen. Nun können wir Speichern.

Kriegen wir jedoch diese Meldung:

ServerError

Haben wir die OLD_PASSWORD Funktion bei der Einrichtung des MySQL users nicht verwendet. Wie es geht steht im Teil 1 ganz unten.

Unsere „Erfolgsmeldung“ sieht so aus:

DB Erfolg

Nach dem Speichern werden wir informiert, dass die DB leer ist und gefragt, ob die Tabellenstruktur angelegt werden soll. Dies bestätigen wir mit „Ja“. Nun legt CAO Faktura die Tabellen an, die es benötigt. Wir können nun im CAO Admin unseren Mandanten öffnen. Nun fragt CAO ob es die Standardformulare installieren soll. Auch hier sagen wir „Ja“.

STFormulare

Nun folgt noch die Information, dass alles angelegt wurde, und das zum ersten Login der Benutzer „Administrator“ mit dem Passwort „sysdba“ verwendet werden soll. Mit „Ok“ bestätigt erscheind das Login Fenster.

CAOLogin

Mit dem Benutzer Administrator und dem Passwort sysdba beim angelegten Mandanten anmelden. CAO installiert nun in die DB Tabellen Postleitzahlen und Bankinformationen.

Wir sind drin… aber was nun?

CAO Faktura ist installiert. Wir könnten uns nun schon im Hauptprogramm oder an der Kasse anmelden. Doch macht es erstmal mehr Sinn den Rest zu konfigurieren, wie z.B. Benutzer.

Wir klicken also nun auf der linken Seite im CAO Admin Fenster auf Benutzer. Dort sehen wir, dass momentan nur einer eingetragen ist, der Administrator.

Cao Admin Benutzer

Im unteren Bereich sehen wir unteranderem ein + Zeichen. Mit diesem Zeichen können wir einen neuen Benutzer anlegen. UID und GID können wir weglassen, das wird automatisch ausgefüllt. Bei Gruppe wählen wir „Administratoren“.
CAO Faktura bietet schon vorkonfiguriert ein paar Gruppen, die wir hier aber erstmal vernachlässigen.
Bei Login-Name geben wir unseren Wunschbenutzernamen ein. (CAO hat die Eigenart den Nutzernamen des angemeldeten Windowsnutzers voreingestellt beim Login Fenster einzutragen, daher wäre dies eine gute Wahl :))
Der Anzeige-Name wird innerhalb CAO als Benutzer angezeigt und ausgegeben. Vor- und Nachname zur identifizierung des Mitarbeiters ;). Und nun noch das Passwort.
Ich empfehle zumindest noch das Passwort des Default Administrators zu ändern.

Die lieben Einstellungen…

… sind ein Thema für Teil 3 dieser Reihe 😉

 

CAO Faktura Installation Teil 1 – MySQL Installieren

In einem vorherigen Post habe ich ja bereits angekündigt noch etwas zur Installation von CAO Faktura zu sagen.

Hier also eine schnelle Schritt für Schritt Anleitung für die CAO Faktura Installation. Dazu ist zu sagen, dass dies nur der Anfang ist und erstmal nur CAO zum Laufen bringt. Es wird dann später erklärt, wie Ihr eure eigenen Formulare einrichten könnt. Wir gehen jetzt erstmal von der „freien“ Version aus, diese Laden wir uns nun von der CAO Faktura Webseite:

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

Ihr könnt natürlich auch erst die Versionsunterschiede vergleichen, und entscheiden, ob ihr nicht vllt. doch schon eine Lizenz für die Proversion erwerbt. Hier die Gegenüberstellung:

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

Nun haben wir also CAO heruntergeladen. Wir benötigen aber jetzt noch eine MySQL Server Instanz und da nicht irgendeine sonder eine Version 4.x. Diese ist auf den MySQL Seiten schwer zu finden, deshalb bietet auch hier die CAO Seite einen Download an. Ich persönlich empfehle die Version 4.1.22:

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

Den MySQL Server installieren

Als erstes installieren wir den MySQL Server. Das Installationspaket ist für Windows gedacht. Ich setze einfach voraus, das die jenigen die einen Linux Server administrieren wissen, wie man a) an das Installationspaket kommt und b) wie es zu installieren ist.

Wir entpacken die Zip Datei und und starten die setup.exe dabei wird dann folgender Screen gezeigt:

MySQL Welcome
MySQL Welcome

Wir klicken auf Next ->

MySQL Setupwahl

Hier wählen wir nun Custom. Dann wird uns ein paar mal mehr die Wahl gelassen 😉 Es folgt:

MySQL Installationpfad

Hier können wir nun unseren Installationspfad ändern wenn gewünscht. Ansonsten auf Next > beim der dann erscheinenden Installationszusammenfassung auf Install. Glückwunsch MySQL ist dann schon installiert. Es muss nun noch Konfiguriert werden.

Den MySQL Server konfigurieren

Nach der Installation ist folgender Dialog aufgegangen wir wählen hier Skip Sign-Up und klicken Next.mysqlKonfigAccount

Es folgt und wir klicken auf Finish.

mysqlKonfig

Es öffnet sich also wieder ein Fenster auch dieses quitieren wir mit der Next Schaltfläche. Beim darauffolgenden Fenster wählen wir „Detailed Configuration“ und klicken Next.

Detail Konfiguration

Nun werden wir vor die Wahl gestellt, ob es ein Server ist, auf dem wir geraden Installieren oder eine Entwicklermaschine. Ich schlage vor, hier Developer Machine zu verwenden, da unsere Installation sich hier erstmal auf eine kleine Arbeitsgruppe beschränkt, bzw. sie erstmal nur zum Testen verwendet wird.

MySQL Installationstyp

Nun wählen wir Multifunctional Database und klicken auf Next.MySQL DB Typ

Jetzt will das Konfigurationsprogramm noch von uns wissen, wo die Daten gespeichert werden soll. Die Default Einstellung ist der Installationspfad von MySQL. Das ist Ok also weiter.

MySQL DB Speicherort

Beim nächsten Dialog werden wir gefragt, wie viele gleichzeitige Zugriffe auf die MySQL Instanz erlaubt werden sollen. Der Standard liegt bei 20. Was meiner Meinung nach völlig ausreichend ist. Also weiter 🙂

Gleichzeitige Benutzerverbindungen

Im folgenden Dialog wird nach dem Port gefragt, auf dem die MySQL Instanz horchen soll. Standard ist 3306. Und weiter…MySQL Port

Auch den nächsten Dialog einfach mit Next quitieren. Wir kommen nun zur Frage, ob wir MySQL als Dienst installieren möchten. Hier würde ich „Ja“ sagen. Es hat einfach den Vorteil, dass ich nur noch CAO öffnen muss und MySQL lauscht bereits im Hintergrund als Dienst. Es ist im Netzwerk auch viel Sinnvoller, sonst muss ggf. am Server MySQL gestartet werden bevor ein Client CAO nutzen kann. Wir machen zusätzlich noch den Hacken bei „Include Bin Dir….“ dies hat zur Folge, dass wir auf der Kommandozeile die MySQL Befehle direkt nutzen können, ohne vorher in das Verzeichnis gesprungen zu sein.

Service

Jetzt wird ein Root User für MySQL angelegt, dem wir ein Passwort geben. Dieser Nutzer hat alle Rechte auf dem MySQL Server.

MySQL Root User

Nach dem wir ein Passwort eingegeben haben und auf Next geklickt, kann der Konfigurationsprozess loslegen. Dazu im Fenster auf „Execute“ klicken und anschließend auf „Finish“. Herzlichen Glückwunsch!!! Ein großer Teil ist geschafft.

Eine MySQL Datenbank für CAO Faktura

Nun legen wir noch schnell einen CAO Benutzer in der DB an. Dazu wechseln wir in die Eingabeaufforderung bzw. zum gerade installierten MySQL Command Line Client.

Bei ersterem müsst ihr einfach „mysql -u root -p“ eintippen  und dann Enter und bei letzterm einfach das gerade vergebene Root Passwort und Enter. Anschließend können wir mit:

CREATE DATABASE cao;

dem MySQL Server sagen, dass wir gerne eine neue Datenbank namens cao hätten.

Ein MySQL User für CAO Faktura

GRANT ALL PRIVILEGES ON cao.* TO 'caouser'@'%' IDENTIFIED BY 'caouserpass' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Mit dem obige Befehl sagen wir dem MySQL Server er soll einen User „caouser“ mit dem Passwort „caouserpass“ anlegen. Der User darf von jedem Ort auf die DB Zugreifen (%) und hat alle Rechte an der DB cao.
CAO Faktura kommt aber leider nicht mit der „neuen“ Passwortfunktion von MySQL klar, daher müssen wir noch folgendes ausführen:

UPDATE mysql.user SET Password = OLD_PASSWORD('caouserpass') WHERE User = 'caouser';
FLUSH PRIVILEGES;

Das sagt dem MySQL Server er soll das Passwort mit der alten Methode speichern.

Das war nun die Installation des MySQL Servers zur Nutzung von CAO. Im nächsten Teil installieren wir endlich CAO Faktura 😉

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.

Typo3 Update von Extbase 1.3 Extension für Extbase 6.2: Repository Fehler

Aus aktuellem Anlass (wird derzeit oft gefragt) wollte ich hier kurz einen relativ häufig auftretetenden Fehler

#1: PHP Catchable Fatal Error: Argument 1 passed to TYPO3\CMS\Extbase\Persistence\Repository::__construct() must implement interface TYPO3\CMS\Extbase\Object\ObjectManagerInterface, none given, called in ...

besprechen, der häufig dann Auftritt, wenn man beispielsweise seine Repositories mit der statischen t3lib_div::makeInstance Methode instanziert hat.

Meistens wird diese Methode in ‚initializeActions‘ verwendet.

z.B.:

/**
*
*@var Tx_Mein_Extension_DatenRepository
*/
$protected $datenRepository;

public function initializeAction(){
$this->datenRepository = t3lib_div::makeInstance('Tx_Mein_Extension_DatenRepository');
}

Mit Typo3 6.2 kann man in dem oberen Fall die initializeAction weg lassen es reicht dann folgendes:

/**
*
*@var Tx_Mein_Extension_DatenRepository
*@inject
*/
$protected $datenRepository;

Die @inject Anotation sagt Extbase, dass hier die angegebene Klasse per DependencyInjection eingeladen werden soll.

Es gibt noch ein paar andere Wege dies zu machen, aber ich finde diesen Ansatz am Einfachsten.

Contao Module Update 2.x -> 3.x

Ich möchte heute den Weg zeigen, der notwendig ist, um alte Contao Module für Version 3.x anzupassen.

Die wesentlichen Änderungen sind:

  • Namespaces
  • Autoloader

In der Version 3.x von Contao wurden php Namensräume verwendet. Dies erlaubt vereinfacht gesagt, gleiche Methodennamen in unterschiedlichen Namensräumen. Das soll hier aber jetzt nicht weiter thematisiert werden. Ihr solltet euch definitiv damit beschäftigen, da es in fast jedem aktuellen Projekt zum Tragen kommt.

Der Autoloader kümmert sich darum, dass die Namensräume, die Klassendateien und die Templates geladen werden. Die notwendigen Dateien kann uns Contao in der Version > 3.1 erstellen. Dazu gibt es ein Backendmodul.

Kommen wir nun zu den eigentlichen Änderungen im Modul.

Fangen wir mit den Namespaces an. In jeder unserer PHP Dateien fügen wir unseren Namespace ein. Da wir das hier nur Beispielhaft durchgehen, reicht uns ein Namespace. Er sollte nicht von einem anderen Modul schon verwendet werden. Es hat sich eigentlich bewährt mit einem Autorenpräfix anzufangen. Für meine Entwicklungen verwende ich „bh_“. Anschließend kommt die Bezeichnung des Moduls. Haben wir nun also eine fixe Erweiterung „Votes“, so würde der Namensraum hier

namespace bh_votes;

heißen. Diese Anweisung muss die Erste in einer Datei sein. Erlaubt ist also folgendes:

Nicht erlaubt ist hingegen:

oder

Nun nachdem wir unseren Namensraum gewählt haben, tragen wir diesen in jede PHP Datei ein. Das erspart uns bei Methoden aufrufen in unseren Klassen den Namensraum erneut angeben zu müssen, da alle Klassen bei unserem kleinen Modul im gleichen Namensraum zu finden sind.

In der Regel erweitern zumindest ein Teil unserer Klassen die Contao Klassen, z.B. die Klasse Modul bei einem Frontendmodul.

Hatten wir in Contao 2.x dies noch wie folgt getan, ist hier nun die Angabe des Namensraums wichtig.

Vorher:

class Votes extends Module{ 
...

Neu:

class Votes extends \Module{
...

Ja aber wo ist denn nun der Namensraum?
Ganz einfach, da der Contaonamespace „\Contao“ ja ehh unser Namensraum-„root“ ist können wir uns das \Contao vor \Module sparen.

Wir verweisen also nun mit dem Backslash in unseren Klassen auf den jeweiligen Namensraum.

Weitere Änderungen können im Code von nöten sein. So z.B. wenn auf Contaoeigene Methoden zugegriffen werden soll.
Z.B. wenn wir ein neues FE-Template Objekt erstellen wollen:
vorher:

new FrontendTemplate()

jetzt:

new \FrontendTemplate()

oder wenn wir auf GET-Parameter zugreifen wollen:
vorher:

$this->Input->get("vote");

nachher:

\Environment::get('ip');

Wir sehen also, es hat sich unter der Haube auch noch ein wenig anderes verändert. Alle Änderungen hier auf zu zählen würde aber den Artikel sprengen. Dafür gibt es auf der Contao Webseite eine gute Dokumentation.
Wenn diese Anpassungen gemacht worden sind, sollte das Modul wieder lauffähig sein.