Pre-Christmas Roof Window Rally [Updated]

My three kids
Update: Nothing came out of this, not really surprising. Anyway, we bought two more windows by now. :)
I have nothing to complain about: I have a beautiful wife, three cool kids, I like my job and live in a nice house we bought last year. Still, with the winter coming and no winter tires yet, the front door being in need of repair and having three hungry kids, money can be a little short.


Looking back at the GSoC 2010 Mentor Summit

In 2010 I was again a mentor in the Google Summer of Code program for the TYPO3 Association. A week ago I attended the Mentor Summit of this year's program. It was the culmination of GSoC 2010 and as expected a very cool event. :)

Everyone who has been at Google will probably agree that it is a hell of a place to be. From a beach volleyball field and free-to-use bikes over a cafeteria equipped with lighting and sound equiment worth thousands of dollars to cool offices with micro-kitchens and Lego-equipped relaxation areas, it has a lot to offer. But, location aside, this has also been...


Tips on the FLOW3 build system

For the FLOW3 distributions a new build system is on the horizon (under review to be exact), which will be used for the TYPO3 Phoenix distribution (and others) as well. This post shall explain how to use it for some common tasks, like unit and functional testing.


How to use MySQL with FLOW3

If you download FLOW3 and set the file permissions as needed after unpacking, it runs out of the box, using SQLite for the persistence layer. FLOW3 can use other databases for which a PDO driver exists though (YMMV), and in the last weeks I have seen question on using MySQL with FLOW3 appear ever more often.


FrOSCamp 2010 in Zürich

FLOW3, Symfony CMF, JCR, Doctrine and CouchDB

A while ago Lukas Smith from Liip AG in Switzerland invited me to FrOSCamp in Zürich. He was gathering a group of people to talk about potentially using the JCR specification for the upcoming Symfony CMF. Added bonus: drive Jackalope and CouchDB for Doctrine further in two hackfests.

Among the attendees were not only Symfony developers but also Benjamin Eberlei (Doctrine Project), Nils Nadermann (phpBB), David Nuescheler (Day Software) and a lone FLOW3 developer - me.

On the first day David Nuescheler (the JCR specification lead) gave an introduction to JCR and talked about the plans for JSR-333 (the next version of the specification). Since the basics were known to me, I was more curious about what will be the scope of JSR-333.


TYPO3 4.2 E-Commerce

Although I am working full time on TYPO3 Phoenix and FLOW3, this book on TYPO3 4.2 E-Commerce caught my interest anyway.

First of all, because I maintain an e-commerce website for a relative of mine and second because the author's names – Edgars Karlsons and Inese Liberte – seemed to sound... latvian. Latvia, that's where my wife comes from and where I have friends and family. So during this year's vacation in Latvia I read the TYPO3 4.2 E-Commerce book.

The book is a good one, although it repeats some of the mistakes most technical books make. When I buy a book on building an e-commerce website and the book says knowledge of TYPO3, PHP and TypoScript is required - why do I get instructions on how to install and set up TYPO3 and extensions to get a basic website running? That is basic knowledge I would simply expect the reader to have and use the pages for more relevant information instead. Hiding update instructions in the templating chapter also is a rather awkward choice.

After the already mentioned 50 pages on setup and templating, the book covers various e-commerce extensions available in very short form before explaining how to import and maintain products. PayPal is discussed as payment platform, but sadly other payment forms are discussed only very briefly. A chapter on using frontend users and groups to bind customers and enable special pricing and promotions follows. Like in other places, you will need to read the relevant extension documentation in addition to what the book provides.

The information on navigation and search inside the shop is sadly not deep enough at all. Building menus with TypoScript needs far more explanation and is in my opinion required knowledge before reading the book, while hints on setting up sitemaps for search engines and providing search options for the shop should have gotten far more attention. Order processing and payment (yes, again) are discussed next and deal specifically with tt_shop requirements.

The next chapter deals with the TYPO3 backend and is not only misplaced (should have followed after the setup instructions at the beginning) but again rather a waste of pages - if knowledge of TYPO3 is required anyway... The last two chapters give a glimpse of what the book could have been. They deal with the topics of SEO and marketing your shop in general and show that the authors know a great deal besides the purely technical stuff.

All in all the authors know what they are talking about, and the book covers more than just how to set up one extension, but has a more general approach. That makes it useful also for those who do not use tt_shop (used as example in the book) but another extension. If I wanted to hire someone in Latvia to build an online shop, the authors would be among the ones to consider, and that shines through in the book.

Sadly the editorial process failed to deliver what the content would have deserved. Information that belongs together is partly scattered throughout the book, some things should have been scrapped in favor of more depth on other topics and the english is sometimes funny sometimes awkward to read. It seems the publisher doesn't do any editing in that regard - really sad. The content would have deserved better...


Phoenix starts to rise!

When we started the first Scrum-style sprint for TYPO3 Phoenix some weeks ago we all were optimistic. In the end it took us a little longer (that's what you get when all those involved forget about holidays and conferences overseas) but we had quite some success.

Now we are already near the end of the second sprint, and TYPO3 Phoenix already looks like a CMS. It can have pages and text content, uses TypoScript for rendering and Fluid templates care for rendering of the page as well as the individual TypoScript objects. Menu rendering for hierarchical and breadcrumb menus is implemented and can be configured with TypoScript. Phoenix can import sites from XML and the editor interface provides ways to change page titles.

Talking about editing: We have some great plans in the pipeline that will blow away everything you ever knew about frontend editing. We hope to have some first steps towards that done during the TYPO3 Developer Days 2010 currently taking place in Elmshorn.


Namespaced out of nothing...

I am currently trying to debug a very strange error I am seeing.

The Stage

FLOW3 in it's current SVN version, PHP 5.3.2 (MacPorts) on OSX 10.6.2, SwiftMailer 4.0.6

The Setup

I created a SwiftMailer package, in that exists a class that extends SwiftMailer's Message class. Now I ask the object manager in FLOW3 for an instance of that class. That all works fine when the static object container for FLOW3 has not yet been written. If the static object container is used, I get:

The Problem

But the problem is cause by something inside PHP, it seems, which is triggered somehow when FLOW3 is involved. Does it push PHP over it's edge? Here is the error I get:
Fatal error: Interface 'F3\Party\Domain\Model\Swift_Mime_HeaderSet' not found in /.../Swift/Mime/SimpleHeaderSet.php on line 23
Line 23 of SimpleHeaderSet.php looks like this:
class Swift_Mime_SimpleHeaderSet implements Swift_Mime_HeaderSet
Now, there is no namespace declaration in that file, so why on earth does PHP want to use F3\Party\Domain\Model\Swift_Mime_HeaderSet? I could not believe what I was seeing, and added some lines echoing __NAMESPACE__ to some files involved. This is the result:
namespace in SwiftMailer\Message constructor: F3\SwiftMailer
namespace in Swift_Message constructor:
namespace in SimpleHeaderSet file: F3\Party\Domain\Model
Message, check; Swift_Message, check; SimpleHeaderSet, .... WTF? Here is the backtrace to see what happens:
F3\FLOW3\Object\Container\StaticObjectContainer->c0294( ??? ) ../AbstractObjectContainer.php:0
F3\SwiftMailer\Message->__construct( ) ../StaticObjectContainer.php:4747
Swift_Message->__construct( ???, ???, ???, ??? ) ../Message.php:44
Swift_DependencyContainer->createDependenciesFor( ??? ) ../Message.php:38
Swift_DependencyContainer->_resolveArgs( ??? ) ../DependencyContainer.php:121
Swift_DependencyContainer->_lookupRecursive( ??? ) ../DependencyContainer.php:321
Swift_DependencyContainer->lookup( ??? ) ../DependencyContainer.php:345
Swift_DependencyContainer->_createNewInstance( ??? ) ../DependencyContainer.php:105
ReflectionClass->__construct( ??? ) ../DependencyContainer.php:277
Swift::autoload( ??? ) ../Swift.php:0
require_once( '/.../Swift/Mime/SimpleHeaderSet.php' ) ../Swift.php:44
As you can see, the namespace in Message is fine, as is the case in Swift_Message. Now the Swift_DependencyContainer comes into play and when ReflectionClass' constructor fires an autoloading request for Swift_Mime_SimpleHeaderSet the namespace magically changes to F3\Party\Domain\Model (the namespace is output in the first LoC of that file!).

I wrote a small script consisting of 5 require() statements and two lines of code to instantiate a Message using the static object container, but of course that works like a charm.

Any Hints

on how to debug this further are highly welcome. But I am rather certain that not anyone else on our planet ever had a similar problem. Do they use PHP and FLOW3 on the ISS?