Today we're going to learn how to setup a TYPO3.Surf installation.

You can use one TYPO3.Surf setup to deploy as many different sites or applications as you want. So you don't need a TYPO3.Surf for each project, but one for them all. TYPO3.Surf does not need a webserver. Actually it does not provide any web interface but is completely CLI based. For the moment we will trigger/execute TYPO3.Surf manually by hand. Later we could have an Jenkins to do that for us.

First, we need a blank FLOW3 installation:

git clone --recursive git://git.typo3.org/FLOW3/Distributions/Base.git SurfNTurf
cd SurfNTurf
./flow3 cache:warmup

Next, we install TYPO3.Surf:

./flow3 package:import TYPO3.Surf

./flow3 package:activate TYPO3.Surf
# find out which new commands are provided by the package "TYPO3.Surf"
./flow3 help

# the package itself is available here:
ls -l Packages/Application/TYPO3.Surf/

Basically thats it. To actually use TYPO3.Surf you need to write a Surf configuration. They are pretty simple PHP-Files, placed in Build/Surf/. Later you will have one configuration for each installation/website (project/customer) and node (staging, production/live) on which you are going to deploy to. Currently TYPO3.Surf provides everything you need for deploying a FLOW3 application. However we need to cover some special needs for TYPO3v4/v6. Some TYPO3.Surf changes for that are already pending in Gerrit for review and some more are in the pipeline.

How to write your own Surf configuration, what you will need to deploy a TYPO3v4/v6 installation, what a "Workflow", "Application" and a "Node" is, will be covered in the next blog post.

For the time being you will find the recent TYPO3.Surf documentation here.

While sitting together at the Core Team Meeting in prior to the T3DD12 in Munich, someone raised the topic "Deployment" for TYPO3v4/6. Many agencies already have their own solution for deploying a TYPO3 site/setup. They based on e.g. phing or even a bunch of plain shell scripts. During the lasts months being a freelancer for several agencies and while talking about deployment with others I noticed most of the people have the same issues again and again. It's always like "how to get some content/pages from this to another installation" or the need for a scriptable way (CLI) to do "TYPO3 things" like clear the cache or run the "database compare tool". There are a bunch of "problems" everybody seems to have, if he tries to automatically deploy an Enterprise TYPO3 Installation.

We really want to tackle this issue, so I setup a forge project (http://forge.typo3.org/projects/extension-deployment/wiki) to collect all ideas and use cases and to actually solve the issues and missing features.

The goal of this project is to setup a "best practice" for deploying a TYPO3 (v4/v6) installation. Also i'm going to develop some tools/extensions or cleanup/extend existing things for how i think a deployment chain might look like.

In the next weeks i will do a series of blog posts here. I'm going to cover "TYPO3.Surf" (which is the "deployment tool" we are join to use), best practice for Git versioning (releasing/branching/...), deployment-friendly TYPO3 setup (where and how to store configurations) as well as "Content migration" (this is real tricky one; more on that later).

If you have any suggestions, ideas, want to contribute to this project or like to sponsor me please do not hesitate to contact me!

The first post will be about "How to setup TYPO3.Surf".

If you have any questions, drop ma a mail at tobias.liebig(at)typo3.org

We are really looking forward to your awesome projects!

The Google Summer of Code 2012 is coming up.

The last two years I participate the GSoC as a mentor and last year I had the great opportunity to join the mentor summit in SF. I really got into the idea of GSoC. You might have read my article about what can be improved this year. Maybe thats why I have been asked recently to join the this years TYPO3-GSoC-Admin-Team to organize TYPO3's Summer of Code.

One of the main issues of the last year was the lack of inner and outer communication. Ingo and I already started to discuss how to improve that. However, beside of the regular "official reports" on news.typo3.org, I'm going to blog about my personal point of view during the summer. At least I'm trying to do so.

We need you!

On last monday the organization application phase did start. The deadline is the next friday the 9.3. Which means we have like one week from now.

Now it's our turn to apply and to do so and to get the best out of this summer, we urgently need your help!

For the moment we need a) possible Mentors and b) ideas for projects.

Could you imagine beeing a mentor?

The mentor is like the project manager for a student and his project. You going to decide, together with the other mentors, which students proposals will be accepted and you will guide one of these projects over the summer. You should already be involved in the TYPO3-Community and really feel the spirit of TYPO3. You are not going to actualy 'work' or even code on your students project. That's really the students part. The mentors task is more about involving the student into our community, getting and keeping the student on track and beeing available for your students questions. Expect like 3-5 hours of work per week. You will need to do hand in a midterm and a final evaluation to google, which actualy is a short questionaire. You going to do regular status meetings with your student (e.g. by skype), reviewing the students work, joining our regular mentor meetings in BigBlueButton e.g. to report about the project status. Never done something like this before? No problem: You won't be alone. We will have some experienced mentors from the last years again, which gladly will help to solve all questions. This is one of the reasons why we will do regular mentor meetings this year. What you will get? First of all a great summer with a cool project and a cool student. Also there is a small(!) compensation. Two of our mentors will join the mentor summit in San Francisco at the Google HQ. But most important: you will do something good for the student, for the OpenSource spirit and for TYPO3! And hey: There will be T-Shirts for everyone!

As I was a mentor for two years now, I can tell you it's a really nice and fun job and worthful experience.

Any questions about beeing a mentor? Like to be one? Get in touch with me!

Ideas for possible projects

When the students apply in the next phase of GSoC, they will hand in project proposals. As most of the students are not that deep into TYPO3 and about our current projects, we need to provide some possible ideas. In the last years we had an 'ideas' page (actualy Google requires us to have one), which we need to update for this years application.

We need any project idea related to the TYPO3 core, FLOW3 or 'Phoenix'. Any rough idea will do! No need for fully concepted/drafted projects, just ideas. I'm going to collect all of these ideas and discuss them with the mentors. These ideas, which we think are doable by a student during the summer, will be presented on the ideas page.

For example: completely rewriting the v4 list module might not be doable for someone never have seen TYPO3 before. A FLOW3 package to browse model data is.

If you are a core team member, core project team member (/leader), a experienced TYPO3 developer or just someone actualy heavily using TYPO3 or FLOW3 and have an idea? Drop me a line!

Make it our "summer of code"

I'm really looking forward to this summer.

Do not hesitate to contact me if you like to participate or if you have any questions or ideas:

• tobias.liebig(at)typo3.org
• Twitter: @etobi or @typo3_gsoc
• Jabber: etobi@jabber.ccc.de
• Skype: tobias7031
• or just leave a comment here

Like I promised this is the second part of the "Summer of Code" article. If you have no idea what this is about, read My Summer of Code here.

This blog post is almost only about what I think needs to be improved. It's not about how to actually solve these issues (in some cases I actually don't have any idea how). Consider this being an invitaion for discussion. I'd love to get your feedback, thoughts, ideas on this article and GSoC in general.

Do not hesitate to drop me a mail, nudge me on twitter, jabber, skype or leave a comment below.

"You're are doing it wrong"

As I already wrote in the last article:

We, the mentors, the students nor the org-admins of TYPO3 did not do it (completely) wrong. But - hey - it's a budget of 27.000 US$ for TYPO3. We definitly should get something out of it, right?

While chatting and listening to other people at the Mentor Summit talking about their projects, their students, and their summer, I realized that we (TYPO3) didn't take advantage of the possibilities. And it's not just us. Many organizations had problems finding qualified students, filtering the proposals, projects worth doing, actually merge/use the code the students produced, and maybe most importantly keeping the students contributing after the summer.

The issues (from my point of view)

Here is what i think are the major issues:

• What's our goal participating in GSoC?
• Improve communication.
• Choosing qualified students, choosing the right proposal.
• Define the tasks and guides for the student and the mentors.

In more detail:

What's our goal participating in GSoC?

The major question while reading this article and for all mentors participating: "What's our goal participating in GSoC?".

• Is it to get (a little) buzz about TYPO3 in the Open Source world? Is it just to be part of the summer? GSoC is a great opportunity. We should get more out of it.
• Do we want to get new contributers? Students, who do their project and stick to it (and the TYPO3 project in general) after the summer, becoming an active contributor?
• Do we want to get things done (maybe things no one else cares about)? We have a bunch of tasks we could let a student do. But on the other hand not all tasks are suitable for a student, especially for first time contributors like most of the students are.
• What's going to happen with the code the student contributes? I think it's important that the student's code should find its way into the core or at least should be used in a real project afterwards. This definitly has an impact on what could be a GSoC project and what's not suitable.

When we - the mentors - are reading and voting on the students' proposals, no one told us what the "goal" is. To be honest I didn't even think about it in the first step myself. Actually it just poped up in my mind while writing these lines. If you are a mentor or going to be a mentor, you should ask yourself why you are participating: what's your personal goal? What's your student's goal? And what the organization's goal is about.

TYPO3 should have a defined goal for participating. At least a general goal, why participating at all. And maybe we can have a goal for the upcomming summer, too. E.g. if the summer's goal might be something like "improving usability" (although it's not a perfect example), one can look for a task, which will help to reach that goal. This does not mean a student can't propose anything else as a project. The goal should be a guide, an idea where to go in the big picture.

However, the goal needs to be discused before the studends apply and all possible mentors should participate in the discussion or - at least - should aggree on it.

And maybe someone already thought about it and defined a goal for TYPO3 in GSoC in general. I did not ask anybody about it. But if someone did, it's a lack of communication.

Improve Communication

This is a very general issue. We (including me!) definitly need to improve communication on all levels. Between the mentors, between the students and especially to not-GSoC-participating people.

To give an example: I - as one of the mentors - had no idea what the status of the five other projects was! To be honest and in retrospect: i didn't ask anyone about it. I'm pretty sure most of the others had no idea how our (Pascal and mine) project is going. At least I (as one of the inner circle) knew the subjects of the single projects, but most people from the outside have no idea what the projects are about, what the project's goals are and what the status is.

During the summer (correct me if i'm wrong) we had like two posts about GSoC on http://typo3.org (1, 2). At the end of the summer no final post/summary was posted yet. I know it's prepared and almost finished, but it's not published however.

Reminder: this is not to offend someone. I know we all are busy and writing blog/news articles has a pretty low priority. Hey - it took me more then 5 weeks for this article, right. Just saying people are curious about what's going on and have no chance to get any information if no one communicates about it.

Oh yes, we have a mailinglist and two IRC-channels for the students and the mentors. I had started a little indroduction thread (i think Karsten suggested it) in the mailinglist back in May. Not even that was answered by all students. Even worth: not one other mentor replied! After that half introduction thread only two other threads appeared on the list: one student asking for feedback (Yay! \o/ wish to read more like that one) and one thread someone asking for the results of the summer (reasonable question, see above - no real answers in that thread).

We also have http://buzz.typo3.org, which lacks of buzz at all (in general, totally). So it's not a problem of missing infrastructure or plattform or tools, it's just no one using it (including me)!

What do you think? Can/should we "enforce" more communication by e.g. requiring each student and each mentor to write at least one public status report per month/week? One paragraph should be fine and it's more than nothing. Can/should the org-admins be more consequent and strict when asking for (short) paragraphs about the project untill a certain date?

Remember: students and mentors are getting payed for working on the project. I think it's okay to expect some writing as a result of the project.

Choosing qualified students, choosing the right proposals

A really hard task for the mentors prior to the actual summer is choosing, and voting on the students proposals and the students itself.

Really: Some of the proposals are really crap. Copy and paste from the ideas page. Others don't make sense at all for TYPO3. Again others are way to ambitious for someone who has never worked and/or contributed to TYPO3 before. It's not too hard to filter these.

However the other proposals may not be final or perfect when the student hands them in either. We as the possible mentors should take care and help the students to improve their proposals. A little guide how a proposal should look like will definitely help.

Further having a goal for the summer could help to improve the quality of the proposals. If the students know what the goal is, they can focus on it and/or get inspiration how to reach that goal. I think this could increase the number of proposals as well as the quality of them.

When you have a well written and well thought-out proposal paper you still do not know, whether the student is a good student and if he can reach his goal. I heard from serveral projects who let the prospective students contribute a simple no-brainer patch to the project.

I really like the idea. Its an easy way to prove the student gets your workflow how to contribute. He learns about the infrastucture and the tools. And after all: if he took this hassle and got through it, he has proven that he is really willing to participate and contribute.

And if the student gets stuck, did not know how to start or how things work, it might be a problem with our documentation which really should be tackled. If the student can't figure out how to contribute, how are others supposed to do!

Define the tasks and guides for the student and the mentors.

It really would help if we define what the general tasks are during the summer for the student (beside of doing and finishing his project) and the mentor.

This might be f.e.:

• setting up a forge project.
• regularly blog/write about the current status of the project (e.g. on http://buzz.typo3.org) and not only on mid-term and after the final evaluation.
• having status meetings each week or maybe even twice a week (and stick to it).
• as a mentor first reviewing the proposals and later reviewing the students code and his articles.
• targeting on getting the code merged into the core (this could be an additional motivation).

These are only some rough ideas. The important thing is that we need to define these tasks and rules and even more importantly to write them down. For example ""The Perl Foundation"" has written down guidelines for mentors and students. We definitly should have something like that too.

Even more ideas...

What if we ask the students to come to the next T3CON or T3DeveloperDays to talk about their projects. Kind of a little TYPO3 GSoC summit with the students and the mentors. I know this might be hard to archive due to students being distributed all over the world and some not being able to afford coming to such an event. It's just an idea. Maybe we could apply for a little budget at the Assoc (may be too late for 2012 though).

Two mentors for each project. I heard from serveral projects that they assign a second co-mentor for each student. Actually that's a good idea. The co-mentor could help out if the first one is not available. He could write the article, reviewing the student's code (two +1s from both mentors are enough to merge a change into the core). As the main work will still remain on the main-mentor, the co-mentor could be a co-mentor in multible projects at the same time.

Bonus: Mentor summit

One last thing: if you're being a mentor during the summer: do anything to get the chance to go to the Mentor Summit. It's really worth it! And we really should send two mentors to the summit, not one going alone (at least one is way better then no one going).

So what do you think about the summer of code?
You are a student or a mentor? Tell me about the issues you had.
You did not participate in Google Summer of Code? Tell me how you have heard/read about the project and it's outcome.

This article consists of two parts (i already wrote both, really!). This (the first part) is about GSoC and the mentor summit in general. The second part will be published on Wednesday and is about my thoughts how a organisation could improve participating the GSoC.

GSoC!? What's it and Why?

Some of you may already know about GSoC, but some of you may have no idea why Google invited me to San Francisco. This is how the "summer" works and why I went to SF:

Every year Google invites students to participate and contribute to Open Source projects. The basic idea: Google is giving stipends to students to work (write code) for three month on a task for an Open Source project. Google calls it the "Google Summer of Code". Many small and some really large open source projects (Mozilla, Apache, Kernel.org, MediaWiki, Git, TYPO3, Drupal, ...) apply to the programm. Actually every Open Source project can apply. Once the organizations are "accepted" by Google, students from all over the world can apply with the organizations by handing in proposals and ideas on what they want to work on during the summer. The organization (in my case the TYPO3 Association) provides a bunch of mentors which decide and vote on the proposals. Depending on the number of student proposals and available mentors of the organisation, Google decides how many students are going to work on their suggested projects. For TYPO3 this year we got six "slots", which means six projects/students.

Each student has at least on mentor assigned. There can be a co-mentor too. The mentor should guide the student in his project, bring him into the community and also evaluates the student's work. Only if the student passes the mentor's evaluation (there is a mid-term and a final evaluation), Google pays the student for his work.

This year 1115 students and 175 organizations took part. Doing a little math: 1100 Students; 5000US$ each; plus 500US$ for each mentor; plus uncounted T-Shirts; plus the Mentor Summit (which is free for all participating mentors). In sum that's a lot of money! Just the students stipends are worth 5.500.000 US$. By what I heared it's the largest single budget spent on supporting Open Source projects by one company.

The Mentor Summit

At the end of the summer, Google invites two mentors from each organization to meet up in Mountain View near San Francisco to exchange experiences. That's the GSoC Mentor Summit. It takes place at the Google Campus - also known as Googleplex - for two days, organized as a "unconference" (kind of like a BarCamp). 350 mentors were invited this year.

As I was mentoring Pascal Jungblut on his FLOW3 Browser project this year, and it happens that no other of us six mentors for TYPO3 had time to go, it was just lucky me who got the chance to go to the summit.

Beside San Francisco being a great city to visit, it was summerly in mid of October and I had far too little time to visit the city (see my photos), I had a great mentor summit.

As it was an "unconference", the event started with a planning session. People suggested sessions and topics to discuss for the next two days. On these two days more then 60 sessions took place. Up to 15 in parallel. Unfortunately there is no way to join every session you're intrested in.

The sessions, the discussions, the talks in between outside in the sun, during the meals, in the chocolate room or at the pool party in the evening, meeting so many different people... It was a really inspiring event! It was a little bit like the TYPO3 developer days back in 2009 in Elmshorn, just not focused on one specific topic (like TYPO3 development), but more general, more widely.

When I said "inspiring" I mean I had the chance to reflect on how we did this summer, realizing that others had the same issues and getting ideas how to improve it in the next year.

"You're are doing it wrong"

Actually TYPO3 did not do it wrong the way we participated in the Summer of Code. But i think we can improve here and there. But that's the second part of the story.

Seit ein paar Tagen bin ich in San Francisco. Das erste mal auf der anderen Seite vom "großen Teich". Der Flug war sehr lang und anstrengend, wobei die Reise in einem A380 ehrlich schon sehr angenehm ist.

Kaum in SFO angekommen habe ich es schon direkt bei der Autovermietung das erste mal gehört: der Satz, der mir in den nächsten Tage noch öfter begegnen soll. "Hey! How are you?", als ob der Gegenüber einen schon länger kennt und mich jetzt - nach langer Zeit - endlich mal wieder sieht und deshalb ernsthaft daran interessiert ist, wie es mir so geht. Oder wie mein Tag bisher so war. Ich bin mir noch nicht ganz sicher, wie und ob man auf diese "Frage" reagiert. Ein "Fine. Thanks." tut's bisher ganz gut. Überall liegt man sehr viel Wert auf Freundlichkeit und guten Service. Grundsätzlich bekommt man - ohne danach fragen zu müssen - alles so dargeboten/genau erklärt, dass keine Fragen mehr offen bleiben. Das war z.B. beim Mietwagen, im Supermarkt, im Hostel im Diner und beim Fahrradverleih so.

Gestern habe ich mir ein Fahrrad geliehen, bin über die Golden Gate Bridge nach Sausalitos geradelt, mit der Fähre wieder zurück und dann Kreuz und Quer durch SF gefahren. Das kann ich wirklich empfehlen. SF hat viele schöne Ecken, die man sehr gut mit dem Rad erreichen und abklappern kann. Was ich NICHT empfehlen kann, zu versuchen die Hügel mit dem Rad zu überwinden. Dass an einigen Straßen die Autos 90° zur Fahrrichtung parken müssen oder keine normale Straßenbahn, sondern einer der berühmten Cablecars fahren, hat schon einen bestimmten Grund. Selbst das bergauf schieben ist sehr anstrengend. Nichtsdestotrotz eine gute Erfahrung. Bei meiner Tour durch SF habe ich die Büros von Dropbox und Github gesucht und gefunden. Übrigens nicht sehr spektakulär. Es fehlt in SF noch ein Nerd-Souvenier-Shop, wo man T-Shirts und all die Merchandise-Artikel der ansässigen Firmen kaufen kann.

Aber warum bin ich überhaupt in SF? Google unterstützt jedes Jahr Open-Source-Projekte, wie z.B. TYPO3, und Studenten die sich in diesen engagieren möchten. Jeder Student wird dabei von einem Mentor der Projekt Organisation begleitet. Dieser "management" ein Projekt, dass der Student im Laufe des Sommers umsetzt. "Google Summer Of Code" heißt das dann.

Am Ende des Sommers werden von jeder teilnehmenden Organisation 1-2 Mentoren zum GooglePlex nach MountainView eingeladen, damit sich dort alle miteinander auszutauschen können. Und in diesem Jahr bin ich der glückliche, der als "Delegate" zu diesem "Mentor summit" geschickt wurde.

Also hab ich heute das (sehr einfache) Hostel, in dem ich die letzten zwei Nächte verbracht habe, verlassen und bin in den Süden gefahren. Der Besuch einiger bekannter Adressen durfte natürlich nicht fehlen. Heute standen u.a. die "Standfort University" und Apple in Cupertino und "Fry's" auf dem Plan. T-Shirts: √. Eingecheckt in das "Domain"-Hotel für die nächsten zwei Nächte, erlebte ich das komplette Gegenteil zum Hostel. Alles sehr großzügig bemessen. Ich kann sogar die Härte der Matratze mit einer Fernbedienung verstellen. Selbstverständlich für linke und rechte Seite des Bettes getrennt.

Heute Abend gab es am Pool ein kleines Warmup und Abendessen. Morgen um 8:30 gibt es dann auf dem GoogleCampus Frühstück und anschließend die eigentliche Veranstaltung, den "Google Summer Of Code Mentor Summit". Ich bin mal gespannt, werde berichten.

Today i thought it would be cool to have an even more magic magic finder. Wouldn't it be great to match multiple properties in one finder? What about getting all "red" objects in size "XL"?

TxExtbasePersistence_Repository already provides some magic finder. Without any additional code, you can find all objects matching a property on a given value. E.g. if you have a model with a string property named color, you can easily find all objects by calling $repository->findByColor('red'). Even if you didn't explicit implement a findByColor method. It's implemented by a magic method called "__call", which parses the called method name and builds a certain query. However. If you're used to extbase you already know that.

Now back to our "problem", how to match multiple proptery in on finder.

One (obvious) solution would be implementing an explicit findByColorAndSize method in your repository. Creating a QueryObject, add two property constraints linked by logicalAnd, execute, return. As usual.

Another solution is two override the "__call" method by this:

/**
 * Dispatches magic methods (findBy[Property]())
 *
 * @param string $methodName The name of the magic method
 * @param string $arguments The arguments of the magic method
 * @throws Tx_Extbase_Persistence_Exception_UnsupportedMethod
 * @return void
 * @api
 */
public function __call($methodName, $arguments) {
	if (substr($methodName, 0, 6) === 'findBy'
	  && strlen($methodName) > 7) {
		$query = $this->createQueryFromConstraintString(
			substr($methodName, 6), $arguments
		);
		return $query->execute();
 
	} elseif (substr($methodName, 0, 9) === 'findOneBy'
	  && strlen($methodName) > 10) {
		$query = $this->createQueryFromConstraintString(
			substr($methodName, 9),
			$arguments
		);
		$object = $query->setLimit(1)->execute()->getFirst();
		return $object;
 
	} elseif (substr($methodName, 0, 7) === 'countBy'
	  && strlen($methodName) > 8) {
		$query = $this->createQueryFromConstraintString(
			substr($methodName, 7),
			$arguments
		);
		$result = $query->execute()->count();
		return $result;
	}
	throw new Tx_Extbase_Persistence_Exception_UnsupportedMethod(
		'The method "' . $methodName . '" is not supported by the repository.',
		1233180480);
}
/**
 * @param string $constrainString
 * @param array $arguments
 * @return Tx_Extbase_Persistence_QueryInterface
 */
protected function createQueryFromConstraintString($constraintString, $arguments) {
	$query = $this->createQuery();
	$constraints = array();
	$argumentPointer = 0;
	if (strstr($constraintString, 'And')) {
		foreach (explode('And', $constraintString) as $propertyName) {
			$propertyName = strtolower(substr($propertyName, 0, 1) ) .
				substr($propertyName, 1);
			$constraints[] = $query->equals(
				$propertyName,
				$arguments[$argumentPointer]
			);
			$argumentPointer++;
		}
		$query->matching($query->logicalAnd($constraints));
	} elseif (strstr($constraintString, 'Or')) {
		foreach (explode('Or', $constraintString) as $propertyName) {
			$propertyName = strtolower(substr($propertyName, 0, 1) ) .
				substr($propertyName, 1);
			$constraints[] = $query->equals(
				$propertyName,
				$arguments[$argumentPointer]
			);
			$argumentPointer++;
		}
		$query->matching($query->logicalOr($constraints));
	} else {
		$propertyName = strtolower(substr($constraintString, 0, 1) ) .
			substr($constraintString, 1);
		$query->matching($query->equals($propertyName, $arguments[0]));
	}
	return $query;
}

I've cleaned up the __call method a little. The called method name (e.g. findByColorAndSize) is chopped and the second part (ColorAndSize) passed to createQueryFromConstraintString. This parses the string for "And" or "Or", gets all property names an builds a certain query object.

Using this new magic __call method, it's possible to use finder like:

$repository->findByColorAndSize('red', 'XL');
$repository->findByColorAndSizeAndPrice('red', 'XL', 10.99);
$repository->findByFooOrBar('foo', 'bar');
$repository->findOneByFooOrBar('foo', 'bar');
$repository->countByFooOrBar('foo', 'bar');
// ...

I think you get the point.

Aber: Neuer "Job" - Neue Motivation - Neuer Versuch.

Ich möchte hier ein bisschen Know-how teilen. Und sei es, dass ich für mich selber hier Snippets, Workarounds, Bugfixes, Tipps hier ablege um sie später wiederzufinden ("ich hab doch schonmal...").