PlanetFLOW3

Die Version 1.1 Beta 1 von dem FLOW3 Framework wurde veröffentlicht. Ziel der Beta ist es die Stabilität und Kompatibilität weiter zu prüfen und zu finalisieren. Neue Features wie u.a. HTTP, L18N, Content Security und mehr Performance sind schon im Paket enthalten. Weitere Informationen gibt es im unglaublich langen Changelog oder in den News. Bei einem Update sollten die Update Instruktionen beachtet werden.

Ein Resultat der neuen FLOW3 Version ist u.a. der gut durchdachte FormBuilder bzw. die Form API (Sneak Preview), welchen Sebastian in einem Video erläutert:

[Im Feed kann dieses Video nicht angezeigt werden.Klicke zum Blogeintrag um das Video anzusehen.]

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Upgrading from FLOW3 1.0

FLOW3 1.1 contains various new features and - we knew you would like that - big speed improvements. We also took the opportunity to adjust some important APIs, such as the Model View Controller mechanism. Thus the upcoming FLOW3 version is not 100% backwards compatible and this is what we anticipated. But we found a nice way to ease everyone’s upgrade pain: a brand new code migration tool automatically adjusts your code to fit the most important API changes. And for the few parts it can't refactor you just follow the detailed upgrade instructions.

Beta and Stable Releases

We plan to release two beta versions in total, followed by the stable release of FLOW3 1.1. If necessary, we'd also release additional betas or adjust the timeline in order to meet our quality standards. Both beta releases have a specific goal: FLOW3 1.1 beta 1 contains all improvements we want to see in the final version. The goal for this release is to get feedback on the compatibility and stability: does your project still work fine after following our upgrade instructions? What did we miss? Although the first beta contains most of the code of the new major features (HTTP, I18N, content security, more speed ...), those features are not fully documented yet. Which brings us to the goal for the second beta release: FLOW3 1.1 beta 2 will contain all features, including the big new ones. The objective for this release is to also get feedback on the HTTP foundation, the localization and translation framework and all the other gems we put into 1.1. We will provide documentation for all of the new features so you know how to test and use them in your own projects. Once we are confident that 1.1 works equally fine for you like it does for us, we are ready for a stable 1.1 release.

Share Your Insights

At this point we’d like to invite you to upgrade existing projects or start new ones based on 1.1. Don’t use it in production yet, but please do share your insights and possible problems you might face. Please refer to the upgrading instructions and add your own findings to the related discussion page. The prospective release date for FLOW3 1.1 beta 2 is May 29th. We hope you enjoy it.

Upgrading from FLOW3 1.0

FLOW3 1.1 contains various new features and - we knew you would like that - big speed improvements. We also took the opportunity to adjust some important APIs, such as the Model View Controller mechanism. Thus the upcoming FLOW3 version is not 100% backwards compatible and this is what we anticipated. But we found a nice way to ease everyone’s upgrade pain: a brand new code migration tool automatically adjusts your code to fit the most important API changes. And for the few parts it can't refactor you just follow the detailed upgrade instructions.

Beta and Stable Releases

We plan to release two beta versions in total, followed by the stable release of FLOW3 1.1. If necessary, we'd also release additional betas or adjust the timeline in order to meet our quality standards. Both beta releases have a specific goal: FLOW3 1.1 beta 1 contains all improvements we want to see in the final version. The goal for this release is to get feedback on the compatibility and stability: does your project still work fine after following our upgrade instructions? What did we miss? Although the first beta contains most of the code of the new major features (HTTP, I18N, content security, more speed ...), those features are not fully documented yet. Which brings us to the goal for the second beta release: FLOW3 1.1 beta 2 will contain all features, including the big new ones. The objective for this release is to also get feedback on the HTTP foundation, the localization and translation framework and all the other gems we put into 1.1. We will provide documentation for all of the new features so you know how to test and use them in your own projects. Once we are confident that 1.1 works equally fine for you like it does for us, we are ready for a stable 1.1 release.

Share Your Insights

At this point we’d like to invite you to upgrade existing projects or start new ones based on 1.1. Don’t use it in production yet, but please do share your insights and possible problems you might face. Please refer to the upgrading instructions and add your own findings to the related discussion page. The prospective release date for FLOW3 1.1 beta 2 is May 29th. We hope you enjoy it.

After several months of development, we have now closed the lid of the feature box and are busy preparing the releases. In this post I'll give you a quick overview of what you can expect during the next few weeks. The first feature release after a 1.0 is a special one: with all the feedback we got and the real applications we've been working on ourselves, the ideas for new features and improvements are endless. Without surprise everybody wants to get his own pet tweak into 1.1 and it's hard to draw the line which patches need to be postponed for a later version. FLOW3 1.1 contains various new features but we also took the opportunity to adjust some important APIs, such as the Model View Controller mechanism. The upcoming FLOW3 version is not 100% backwards compatible and this is what we expected. But we found a nice way to ease the upgrade pain: a code migration tool can automatically adjust your code to fit the most important API changes. And for the few parts it can't refactor we'll provide detailed upgrade instructions. We plan to release two beta versions, followed by the stable release of FLOW3 1.1. If necessary, we'd also release additional betas or adjust the timeline in order to meet our quality standards. Each of the beta releases has a specific goal: FLOW3 1.1 beta 1 contains all improvements we want to see in the final version. The goal for this release is to get feedback on the compatibility and stability: does your project still work fine after following our upgrade instructions? What did we miss? Although the first beta contains most of the code of the new major features (HTTP, I18N, content security, ...), those features are not fully documented yet. This is the goal for the second beta release: FLOW3 1.1 beta 2 contains all features, including the big new ones. The goal for this release is to also get feedback on the HTTP foundation, the localization and translation and all the other gems we put into 1.1. We will provide documentation for all of the new features so you know how to test and use them in your own projects. Once we are confident that 1.1 works equally fine for you like it does for us, we are ready for a stable 1.1 release. We currently discuss a few ideas regarding the future release cycle and overall process of releasing new FLOW3 versions. In general we need to satisfy both needs: early access to new features (rather every two weeks than months) and plannable stable releases (rather every three months than every few weeks). What's your take on this, which rhythm fits you best?

We chose the code name "Back to the Future" for the TYPO3 6.0 release coming this fall for various reasons. First of all it's of course a fun and geeky reference to a movie. But it is also a reference to the history of TYPO3 v4 and the planned but not yet released complete rewrite of the CMS with the codename "Phoenix". With the version 4 branch now moving forward towards a new major version number, we can leave behind some self made limitations and get Back on track, embracing the Future. This in particular means that 6.0 will incorporate heavy code cleanups especially moving some modules to extbase, the modern and future proof framework which has been backported form the Phoenix code. Besides that we will improve and intense the collaboration with the Phoenix team when it comes to new features so that new concepts and APIs are the same or similar where it makes sense. This will make TYPO3 v6 more stable and maintainable and smoothes the transition path to Phoenix.

During the TYPO3 Core Team Meeting as well as during the TYPO3 Developer Days 2012 we brainstormed some ideas what changes or features could make it into 6.0. We want to give you a short overview of the different topics, roughly sorted by the visions we have for that version.

If you want to help with any of them, feel free to get in touch with us. Of course you can also work on something totally different, maybe you have some additional ideas or want to start a team on something else. Then also feel free to contact us, to get your project up and running.

This list is neither complete nor is it final. It might be the case that some of these projects will not make it into 6.0 and need to be postponed to later versions. But for sure others will. If you already have a project you want to see in 6.0, just add it in the comments section and we will add it to the list.

Enhance User Experience

Improve Usability

(Patrick Broens, Helmut Hummel, Jens Hoffmann, Benni Mack)

The overall usability of the TYPO3 backend should be improved, especially for the editors. There will also be a code sprint on this topic, to get some hands-on work done together. 

New way to manage extensions

The current extension manager is criticized quite often for being unusable, slow and not able to do all the stuff you want to do with it while being able to do stuff you don’t want to do it. In this project we want to rethink the whole extension manager based on which features do you really need, how should they be implemented and what can be done in a different place altogether. The plan is to have the UX concept first and then get started implementing it. 

http://forge.typo3.org/projects/extensionmanager

jQuery Integration

We plan to replace prototype/scriptaculous with jQuery in the backend. jQuery is a solid and widely used and actively maintained JavaScript Framework. Incorporating jQuery is an important building block to be more agile with enhancements to the backend and thus streamlining the user experience. 

Have a look at the projects page on forge for the status:

http://forge.typo3.org/projects/typo3v6-jquery

Support for Mobile Devices

(Steffen Ritter, Patrick Broens, Sven Wolfermann)

More and more of the overall internet users are using mobile devices. The TYPO3 frontend is already able to serve mobile and responsive web sites but the TYPO3 backend is at the moment pretty much unusable on mobile devices. To showcase the frontend capabilities of TYPO3 we want to rewrite the introduction package adhering the principles of responsive web design. For the backend we want to achieve at least a basic support of tablet computers (especially concerning resizing / scrolling issues). 

Deployment and Updates

(Tobias Liebig, Olly Hader, Michael Stucki)

TYPO3 updates for minor versions are easy enough to do. In fact they are so easy that they could probably be automated. We want to have an easy way ("push a button") to upgrade a TYPO3 extension. On the same subject we also want to have better console support for doing things in TYPO3 like installing or updating extensions making it possible to write shell scripts to automate these processes. 

http://forge.typo3.org/projects/show/extension-deployment

Improve and ensure code quality

Infrastructure to monitor code quality

(Helmut Hummel, Andy Grunwald, Christian Trabold)

We want to build and provide an infrastructure that makes it easy to execute unit and functional tests on development systems and have them automatically executed on every commit to our review system (Gerrit). The first steps for the latter are done already. We have a Jenkins server (ci.typo3.org) that does a syntax check for every commit and also checks for CGL violations. Additionally executing unit tests on each commit are basically working, using the travis ci infrastructure (travis-ci.org). The plan is to get this running at least for the end of the 6.0 development and ship a “green build” to the users with this release.

Move towards more simplicity

In the last few years the backend got more and more complex. More features and system extensions were included in the Core while at the same time due to backwards compatibility not much was removed, resulting in a bigger TYPO3 with every release. With a new major version we get the chance to remove old and outdated code as well as extensions that nobody uses anymore or that are not maintained. We aim to have a public discussion about features and extensions that just bloat the core and want to decide together with the community how to get a smaller TYPO3. 

Secure the building

(Georg Ringer, Helmut Hummel)

To improve security even more we want to provide an easy to use and easily understandable API for security features (for example "ecodeForHtmlAttribute", "ecodeForJavaScript" or "validateFilename").

Revamp the Logging

This project aims to:

• streamline them into on single logging API,
• optimize the user interface of the Log module,
• create and maintain suitable documentation for the different target groups
• cleanup logging configuration.

 If you want to help out in this topic, contact us or join the team directly on forge

http://forge.typo3.org/projects/typo3v4-logging

Encourage and strengthen Collaboration

Let's get into the FLOW

(Olly Hader , Patrick Broens, Georg Ringer, Christian Kuhn, Sebastian Kurfürst / Thomas Maroschik / Tolleiv Nietsch, Christian Müller)

As we have a really cool shiny PHP framework in our community now we want to take even more steps to make use of the benefits of this framework. That includes porting more backend modules to extbase and fluid, which will in the long term make restructuring the backend interface much easier. Have a look at the core mailing list in the thread “[TYPO3-core] Call for help: Migrate core extensions to extbase”.

Additionally we want to develop a common package repository for FLOW3 packages and TYPO3 extensions.

Miscellaneous

It's getting cloudy - or what file abstraction can do for you

(Benni Mack, Steffen Ritter)

External tool integration / REST API

(Thomas Maroschik, Helmut Hummel)

The way content is added to websites is changing. We can imagine that in the future you want to use voice input for editing content, mobile interfaces, your play station or something entirely new. To make that possible we need to implement an API for the basic actions you do (like: editing, adding, deleting or reading content). Basically the plan would be to implement a REST API for these actions.

TYPO3 Phoenix

The new new new TypoScript rendering has been merged last month, and the various sites in production have been updated as needed. History management and link handling have been tweaked, the rewritten page tree implementation was submitted to the codebase and some workspace publishing bugs were squashed. Christian worked on the concept for content types in Phoenix and prepared some documents.  Aske and Bastian continued to work on the setup tool for Phoenix (and other FLOW3 applications) and pushed the results to the review server. This brings us a lot closer to a smooth experience for first-time Phoenix users. As already mentioned, we had some very nice sessions around Phoenix and the technologies we are using during the TYPO3 Developer Days. The sessions on EmberJS and TYPO3 Phoenix key concepts, the workshops on building a Phoenix website and creating a Phoenix plugin, the introduction to the TypoScript rendering engine (using Fluid) - all were well received and often ended with lively discussions about open tasks, possible solutions and new concepts. The longest workshop was about developing the concept for the Phoenix backend, and enough people participated the full day to fill four separate working groups. At the end of the day we had collected names and contact details from a number of people that want to participate in the project and had quite some results in the areas setup, editing, user permission handling and general UI/UX that can be implemented or serve as a good base for further work. One part that was already started is the management view. Sebastian worked on it and already produced some impressive results. Bastian later met with Marc Neuhaus (author of the FLOW3 Admin package) and had a real nice discussion on how to join forces for the Phoenix Content Management module Another task ticked off in April was the launch of the call for papers for the T3CON12 Québec. During T3DD12 some of our team also spent some hours with Visay Keo who is maintaining the Phoenix-powered website for the T3CON12 Asia  to help him get things up and running.

FLOW3

Robert finalized the HTTP foundation changes and they were merged into the master codebase. A side effect is that unit and functional tests (not only) for the MVC stack have become a lot easier now, due to no longer needing to mock requests (simply create an instance) and a "virtual browser" that can be used in functional tests.  Another large change were the improvements and bug fixes for content security in FLOW3, that should now be fully working as expected. The same is true for file monitoring, which was given a thorough nudge and should now reliably detect all situations that make cache invalidation necessary. Bastian had a first go at reviewing the FLOW3 ruleset for PHP_CodeSniffer and Karsten changed the location of XLIFF files in FLOW3 packages to make the Pootle translation software happy. Those using FLOW3 on Windows probably are happiest about the removal of the .Shortcuts folder we introduced a while back to speed up class loading in FLOW3 - the use of symlinks is a real pain on Windows… Of course FLOW3 was also a topic for the TYPO3 Developer Days. Robert presented noteworthy changes that will be part of FLOW3 1.1 and the Form project was presented to interested developers by Bastian Waidelich. Connecting the worlds of FLOW3 and the TYPO3 CMS, the future TER project also was presented and Sebastian brushed up this whitepaper for that occasion.

The End

That's it for April. Now on with May… stay tuned!

We're pleased to announce the release manager for the next version TYPO3 6.0 which is planned to be released this fall. 

You probably already have heard that Helmut Hummel will take over this task. Helmut currently is the leader of the TYPO3 Security Team and an active member of the TYPO3 Core Development Team. Since the expectations for a new major version 6.0 are high and the time until the release is limited, doing the release management for this version will be a challenging task. This is why he is supported by Christian Kuhn and Susanne Moog. All three will join forces in helping to coordinate the community efforts to make the new TYPO3 version 6.0 shiny and outstanding.

Here is a short introduction of the people in that team:

Helmut Hummel

Christian Kuhn

Susanne Moog

Welcher Test ist der richtige?

In der Entwicklung mit FLOW3 spielen Tests eine große Rolle. Das Tests dabei wartbar und aussagekräftig sind, erfordert einiges an Erfahrung beim Test-Driven-Development. Wichtig ist zwischen den verschiedenen Arten von Tests zu unterscheiden und für den richtigen Einsatzzweck anzuwenden:

Unit-Tests sind ein wichtiger Bestandteil zur Steigerung der Qualität und für eine größere Sicherheit bei zukünftigen Änderungen. Dabei wird jeweils nur eine Code-Einheit (z.B. eine Klasse) ohne größere Abhängigkeiten getestet. Ein fehlgeschlagener Unit-Test kann die Frage nach dem genauen Ort eines Problems oder einer inkompatiblen Änderung beantworten. Auch sind Unit-Tests die eigentliche Grundlage für Test-Driven-Development mit einem Test-First-Ansatz (also zuerst einen Test schreiben der fehlschlägt, dann die Implementierung).

Aber: selbst wenn alle Unit-Tests laufen, heißt das noch nicht, dass das Gesamtsystem zuverlässig läuft. Ausserdem sind Unit-Tests aus meiner Erfahrung bei der ersten Implementierung von ganz neuen Features (z.B. ein neues Persistenz-Backend wie das CouchDB-Package) unzureichend und störend, da die Richtung der Entwicklung oftmals noch nicht klar ist und über viele Schichten des Systems hinweg gearbeitet wird.

Functional-Tests in FLOW3 sind ein noch recht neues Feature um das System mit (fast) allen Abhängigkeiten testen zu können. Dabei steht das komplette FLOW3 mit Dependency Injection, AOP etc. in einem speziellen Kontext Testing zur Verfügung. So kann z.B. einfach der Versand von E-Mails oder die Datenbankverbindung für Tests umkonfiguriert werden.

Gerade für das Implementieren neuer Features können am Anfang gut Functional-Tests für eine automatische Überprüfung der Ziele benutzt werden. Wer im Browser in einer Webanwendung immer dieselben Schritte macht bis der Code das richtige tut, sollte vielleicht überlegen, ob Functional-Tests nicht Zeit einsparen könnten.

Der wichtigste Punkt für Functional-Tests ist für mich aber die Sicherheit, dass ein Feature im kompletten System mit allen Packages und Abhängigkeiten funktioniert. Generell sollte für jedes Szenario einer User-Story, also jedes zentrale Feature einer Applikation ein Functional-Test hinterlegt werden. Dabei ist es nicht wichtig jeden Ausführungspfad zu testen, das können auch Unit-Tests erledigen.

Functional-Test Tricks

1. Partielles Mocken von Objekten

Dabei werden Abhängigkeiten eines Objekts zum Teil durch ein Mock ersetzt. Nützlich für schwierig zu konfigurierende und zu testende Abhängigkeiten, z.B. Mailversand, externe Webservices oder Simulation eines Requests (die Helper-Methode sendWebRequest der FunctionalTestCase-Klasse nutzt selber diesen Trick). Richtig angewendet kann man damit zwar viele Schichten des Systems testen, aber bestimmte Abhängkeiten ausschließen.

2. Fixture Factories für Testdaten

Natürlich brauchen Functional-Tests irgendwann auch ein fertig instanziiertes Model als Grundlage. Recht lästig wird es, wenn jedesmal bestimmte Eigenschaften gesetzt werden müssen und dieses dann in verschiedenen Tests wiederholt wird. Auch Tests sollten nicht zu viel Redundanz aufweisen. Änderungen am Model und Änderungen in der Validierung verursachen dann viel Arbeit.

Model. Bauen. Redundanz? Da gibt es doch dieses Factory-Pattern? Genau. Ein wunderbarer Anwendungsfall. Mit ein bisschen Flexibilität gepaart, können durch eine Fixture-Factory viele Zeilen Testcode vereinfacht werden.

Nehmen wir z.B. ein Customer-Model für Kundendaten. Eine solche Factory könnte eine Methode buildValidCustomer bereitstellen, die ein Objekt baut und gleich mit den richtigen Beispiel-Eigenschaften versieht. Wenn dann noch Eigenschaften in einem Array zum Überschreiben übergeben werden können, sind auch Tests mit Abhängigkeiten auf bestimmte Werte in Eigenschaften gut lesbar und unterschiedliche Varianten eines Objektes möglich.

Mit einer zusätzlichen Method createValidCustomerkönnte man dann auch das Repository im Functional-Test sparen und das Objekt direkt zum Repository hinzufügen.

class Customers {
    
	protected $validCustomerProperties = array(
    	'customerNumber' => '123456',
		'emailAddress' => 'john.doe@example.com',
		'firstname' => 'John',
		'lastname' => 'Doe'
	);
     
    public function buildValidCustomer(array $overrideProperties) {
    	$properties = array_merge($this->validCustomerProperties, $overrideProperties);
		$customer = new F3MyPackageDomainModelCustomer();
		foreach ($properties as $propertyName => $propertyValue) {
			if (F3FLOW3ReflectionObjectAccess::isPropertySettable($customer, $propertyName)) {
				F3FLOW3ReflectionObjectAccess::setProperty($customer, $propertyName, $propertyValue);
			}
		}
		return $customer;
    }
     
}

class CustomersTest extends F3FLOW3TestsFunctionalTestCase {
     
    static protected $testablePersistenceEnabled = TRUE;
     
    /**
      * @var F3MyPackageTestsFunctionFixturesDomainModelCustomers
      */
    protected $customers;
     
    public function setUp() {
    	parent::setUp();
    	$this->customers = $this->objectManager->get('F3MyPackageTestsFunctionFixturesDomainModelCustomers');
    }
     
    /**
      * @test
      * @expectedException F3FLOW3PersistenceGenericExceptionObjectValidationFailedException
      */
    public function customerEmailAddressHasToBeUnique() {
    	$customer1 = $this->customers->buildValidCustomer(array('emailAddress' => 'foo@bar.com'));
    	$customer2 = $this->customers->buildValidCustomer(array('emailAddress' => 'foo@bar.com'));
    	$this->customerRepository->add($customer1);
    	$this->customerRepository->add($customer2);
    	$this->persistenceManager->persistAll();
    }
     
}

Was uns direkt zum nächsten "Trick" bringt: dem effektiven Testen von Exceptions in Tests.

4. Test von Exceptions

PhpUnit bringt eine einfache Möglichkeit mit sich Exceptions zu erwarten. Ein mit @expectedException (wie im Beispiel oben) annotierter Test stellt sicher, dass eine Exception mit dem angegebenen Typ geworfen wurde.

Was aber, wenn die Eigenschaften einer Exception relevant sind? Nehmen wir z.B. eine Exception, die bei Validierungen geworfen wird, und die ein Validierungsergebnis (F3FLOW3ErrorResult) beinhaltet. Wenn ein Test sicherstellen soll, dass die richtige Eigenschaft als Fehlerhaft markiert wurde, macht es Sinn, die Exception abzufangen, die Testerwartung durch ein Assert anzugeben und die Exception wiederum zu werfen, damit ein @expectedExceptionfür uns den Rest erledigt und den Test gut lesbar dokumentiert.

class CustomersTest extends F3FLOW3TestsFunctionalTestCase {
     
    // ... Set up dependencies
     
    /**
      * @test
      * @expectedException F3MyPackageExceptionValidationException
      */
    public function createCustomerWithMissingEmailAddressThrowsValidationException() {
    	try {
    		$this->customerService->createCustomer($this->customers->buildValidCustomer('emailAddress' => ''));
    	} catch (F3MyPackageExceptionValidationException $exception) {
    		$this->assertTrue($exception->getResult()->forProperty('emailAddress')->hasErrors());
    		throw $exception;
    	}
    }
     
}

Testen testen testen ...

Es gibt noch viele weitere interessante Bereiche des Testings von Webanwendungen mit PHP und FLOW3. Dazu gehört sicherlich auch die richtige Anwendung von Mock-Objects und vor allem das Schreiben von aussagekräftigen und lesbaren Tests. Es bleibt also noch Platz für den einen oder anderen Folgeartikel...

FLOW3 zu installieren ist eigentlich relativ simple. Das ist wie beim Kochen, wenn man sich ans Rezept hält kann FLOW3 schnell serviert werden.

Hier erstmal unsere Zutaten, die zwingend notwendig sind:

• Ein Webserver (empfohlen wird ein Apache mit aktiviertem mod_rewrite [1])
• PHP 5.3.2 oder höher
• Eine PDO kompatible Datenbank wie z.B. MySQL [2]
• Zugriff auf die Kommandozeile

Als Webserver sollte auch ein IIS oder andere funktionieren, aber getestet hat es wohl noch keiner. Wichtig ist jedenfalls das mod_rewrite aktiviert ist [1]. Solltet Ihr PHP selbst kompiliert haben müsst Ihr checken ob Ihr die PHP Module "mbstring" und "pdo_sqlite" aktiviert habt. Da der Development Kontext recht viel Memory benötigt solltet Ihr noch das Memory Limit in der php.ini auf mind. 250MB stellen.

Wenn wir alle Zutaten zusammen haben fangen wir direkt mit den Vorbereitungen an.
Unser Hauptgericht, FLOW3, besorgen wir uns direkt aus dem GIT Repository. Alternativ könnten wir uns von der FLOW3 Seite das letzte veröffentlichte Release herunterladen. Aber in diesem Tutorial setzen wir auf ein frisches Hauptgericht und nicht auf etwas aus der Tiefkühltruhe.

FLOW3 herunterladen

Nehmen wir an FLOW3 soll später unter /www/projektX laufen. Führen wir den folgenden Befehl aus, wird die Distribution in /www/ in dem Ordner projectX abgelegt.

Solltet Ihr noch kein GIT installiert haben führt einfach folgenden Befehl aus

apt-get install git-core

Nachdem GIT installiert wurde könnt Ihr die GIT Befehle nun nutzen. Ziehen wir uns nun die Distribution

git clone --recursive git://git.typo3.org/FLOW3/Distributions/Base.git /www/projektX

Der Parameter --recursive ist wichtig, da die Packages in der Distribution nur als External eingebunden sind, ohne das --recursive würden uns diese Packages fehlen. Solltet Ihr eine ältere GIT Version haben in der --recursive noch nicht unterstützt wird müsst Ihr folgendes ausführen

git clone git://git.typo3.org/FLOW3/Distributions/Base.git projectX
git submodule init
git submodule update

Das ganze sollte danach in etwas so ausschauen

www/                       
  projectX/
    Build/
    Configuration/
      Settings.yaml.example
      ...
    Packages/
      Framework/
        TYPO3.FLOW3/
        ...
    Web/
      .htaccess
      index.php
    flow3
    flow3.bat

Berechtigungen setzen

Da FLOW3 vom Webbrowser verwendet wird und natürlich von uns von der CLI, müssen wir als nächstes die Berechtigungen setzen. Das brauchen wir idealerweise nicht selbst machen, hier bietet das FLOW3 CLI Interface ein entsprechendes Kommando. Dazu müssen wir uns auf der Kommandozeile nur im Ordner /www/projectX befinden, da dort das CLI Script liegt.

./flow3 core:setfilepermissions kj187 www-data www-data

"kj187" ist in dem Fall der eigene Benutzername, dieses solltet Ihr also mit euerem ersetzen. Der zweite Parameter ist der Benutzername des Webservers und der dritte der Name der Gruppe vom Webserver.

Check

An der Stelle können wir nun schon kurz checken ob FLOW3 funktioniert. Dafür führen wir im Hauptverzeichnis folgenden Befehl aus (Achtung: der erste Aufruf kann ein wenig dauern!)

./flow3 help

Folgendes Ergebnis sollten wir nun bekommen

Web Server Konfiguration

Damit der ganze Spass nun natürlich auch vom Browser aufgerufen werden kann müssen wir dem Kind nun einen Namen geben.

<VirtualHost *:80>
    DocumentRoot /www/projectX/Web/
    ServerName projectX.local
</VirtualHost>

 
Damit die Werte aus der .htaccess im Web Ordner auch greifen erlauben wir hier das überschreiben

<Directory /www/projectX/>
    AllowOverride FileInfo
</Directory>

Jetzt müssen wir noch festlegen unter welchem Kontext die FLOW3 Installation laufen soll. Per Default gibt es

• Development
• Staging
• Testing
• Production

Fürs Entwickeln nutzen wir also Development und um die spätere Liveumgebung zu simulieren richten wir uns direkt einen Produktion Kontext ein.

<VirtualHost *:80>
    DocumentRoot /www/projectX/Web/
    ServerName dev.projectX.local
    SetEnv FLOW3_CONTEXT Development
</VirtualHost>
<VirtualHost *:80>
    DocumentRoot /www/projectX/Web/
    ServerName projectX.local
    SetEnv FLOW3_CONTENT Production
</VirtualHost>

Die URLs tragen wir noch schnell in die /etc/hosts ein

127.0.0.1 dev.projectX.local
127.0.0.1 projectX.local

starten den Apache Server kurz neu und schon sollte unser FLOW3 Gericht servierbereit sein.

Das war es soweit, ich hoffe es hat euch geschmeckt! Fragen, Anregungen, Lob und Kritik sind per Kommentar sehr erwünscht!

[1] http://httpd.apache.org/docs/2.3/mod/mod_rewrite.html
[2] http://de2.php.net/manual/de/pdo.drivers.php

CeBIT

CeBIT is the world's largest and most international computer expo. CeBIT is held each year on the world's largest fairground in Hannover, Germany. This year from March 6 until march 10. TYPO3 has been present for the past few years in the Open Source Park and now was invited to join a sponsored booth together with Drupal, Joomla, Wordpress and Magento.

Hall 6, where the booth was located, also brought more interesting requests then during other years. The crew of three till eight persons was occupied almost all day with people interested in TYPO3. The team saw different visitor groups visiting the TYPO3 booth and it seems a lot of different-sized companies will use TYPO3 for their upcoming projects. The team at our booth provided all necessary assistance to make sure the reasons for using TYPO3 where clear and were also not shy to point visitors to one of the other open source systems as a better fit for their purposes.

News item: http://typo3.org/news/article/cebit-2012-a-review/

 

TYPO3 Association

From March 19 – March 20 the TYPO3 Association met with the Board and the newly elected Expert Advisory Board. The Board meets every three months to discuss issues on their agenda. Public items can be found on the issue tracker: http://forge.typo3.org/projects/t3a-board-public/issues/

The EAB has had it's first meeting and needs to find it's working mode. A next meeting is planned in May in Basel.

About the EAB: http://association.typo3.org/expert-advisory-board/

FLOW3 conference F3X

FLOW3 is a web application platform enabling developers creating excellent web solutions. It gives you fast results. It is a reliable foundation for complex applications and will be the basis of the TYPO3 community's new CMS of which a first version is expected in October of this year.

The FLOW3 Experience 2012 (F3X) is the first conference about FLOW3 in the world. F3X was held from March 30 until March 31. The conference brought 170 attendants to the Kesselhaus in Kolbermoor. The talks were of a high qualitative level and mainly presented by leaders and members of the FLOW3 core development team.

This year the conference was in German only, but plans for next year are to go global and have English as main language.

Website (german only): http://www.flow3experience.de/

typo3.org relaunch

The relaunch sprint weekend was held from March 31 – April 2. A team of around ten people worked to finalise this effort that had been going on for such a long time and made the relaunch of typo3.org come true.

The website is still in a Public Beta phase. There are still quite a number of bugs that need to be fixed. In easy to use feedback tool is present on typo3.org so users / visitors can give feedback about the new website.

The new website sports a fresh new design and has the news section, previously on a separate server, integrated. Among the new functionalities are a snippets library, professional services listing and a new extension repository.

In order to guarantee maintenance of this big website the relaunch team has identified Fields Of Responsibility that need to be taken care of by agencies. The involved agencies need to sign an SLA with the relaunch team to make sure we are guaranteed of support when we need it. The list of maintainers will be published on typo3.org. We already have quite a few companies that are willing to back this up, but we can always use your support as well.

News item: http://typo3.org/news/article/maintaining-typo3org/
News item: http://typo3.org/news/article/typo3org-relaunch-1/

TYPO3 version 4.7

The release team had two beta releases in the month of March, gearing towards the final release on April 24. Besides the well-known Introduction Package there is a Government Package for this release. The Government Package is targeted at authorities specifically but might also be of value for other interested parties. It is tailored to the specific needs of public authorities websites. Initially the Government Package will be available in German only, but an English version is planned.

Project page: http://forge.typo3.org/projects/typo3v47-projects

FLOW3 and Phoenix

The Phoenix team members could work very little on the project. Hands and brains were deep inside FLOW3. A major achievement concerning Phoenix was the merge of the re-factored TypoScript implementation. One of the main issued the FLOW3 team tackled in March was development speed in FLOW3. A code sprint dedicated to speed resulted in some impressive improvements. The highlight regarding FLOW3 was definitely the first FLOW3 conference ever, the FLOW3 Experience 2012.

News item: http://typo3.org/news/article/typo3-phoenix-and-flow3-march-2012/

News from overseas

The Khmer TYPO3 User Group (KTUG) lets us know it has relaunched its website as well: www.typo3cambodia.org. KTUG meetings still take place once a month. In April and May 2012, the group is invited to visit two universities and provide workshops and tutorials to students and professors.

T3CON12 ASIA

From August 17 to 19, 2012, the first TYPO3 Conference in Asia will take place in Phnom Penh. KTUG would like to meet you there.

Participation at BarCamp Siem Reap

For the first time, a BarCamp will be organised in Siem Reap end of March. Cambodian TYPO3 enthusiasts will present TYPO3/FLOW3.
More info on http://barcampsiemreap.org