Sebastian De Deyne has a new post to his site showing the Laravel users out there a method for theme-based views in their applications using vendor namespacing in a multi-tenant environment.

I'm building a multi-tenant Laravel application. One of the requirements of the project is that every client can have their own theme based on their corporate guidelines. By default a few css adjustments will suffice, but some clients request a completely different template.

Conditionally loading a different stylesheet per client is pretty trivial, but in order to use a completely different view per theme you quickly end up typing the same thing over and over across various parts of your application.

[...] There aren't any huge issues here, but all together it feels like we should be able to do better. There are a few strategies to clean this up, but I just want to talk about vendor namespaces today.

He gives an example of a view setup that makes use of the current client/customer's namespace to define the path to the template. He found this leading to a lot of redundancy and figured out a better way: using namespaces. Namespacing is mainly made for package development but can be use here to create a "theme" namespace. This namespace can then be defined once and reused across the application without the need to manually build the template location string every time.

On the Stovepipe Systems Dev blog today Iltar van der Berg has shared a post about bundles, one of the key concepts in the Symfony ecosystem - what they are and some of the common features they all share.

People often refer to bundles as modules or re-usable code for Symfony applications. When a developer has experience with Symfony1 or another framework with the module concept, it might seem logical that this is what a bundle represents in Symfony.

So what is a bundle? When do you need one and what can it do? What's the difference between an AppBundle and a vendor Bundle?

He starts with the release of Symfony 2, including bundle support, and how common practices created hard dependencies between bundles. This created issues in the applications and reusability of the bundles (their whole purpose) so a solution was created: the AppBundle. This bundle shifted the emphasis away from the file structure of the bundles and more towards the domain they occupied, handling some "magic" references automatically for you.

As mentioned, the bundle provides an extension point. Other bundles for example, can hook in on your bundle because it contains some logic to expose information such as the directory of the bundle.

[...] The main purpose of a bundle however, is to provide an extension point for the Dependency Injection Container. When talking about this extension point, it revolves around adding, changing or removing service definitions.

In her latest post Lorna Mitchell looks at a method, when using Composer and git, to fix an issue around subdirectories that are git repositories and git thinking they should be submodules instead.

Recent additions to the joind.in API have introduced some new dependencies so we decided we'd start using Composer to manage these - but we don't want to run composer unsupervised. I'm sure this will bring the rain of "just run composer install, it's probably mostly almost safe" criticism, but actually it's quite tricky to run Composer without excluding vendor/ from source control so I thought I'd share how we did it so that anyone who wants to do so can learn from my experience!

She starts by describing the usual use of Composer - making the "composer.json", running the install and see the "vendor" directory being added. When she tried to check in the dependencies, git gave her an error about wanting them to be submodules. Instead, she figured out a way to add a line to the .gitignore to have it disregard the "vendor/.git" directory, making it work as expected.

Ericka Heidi has a new post to her site today continuing on her theme of useful Vagrant advice with a look at optimizing Symfony applications on your Vagrant-managed instances.

A few months after I started playing around with Vagrant and Puppet, with smaller applications, I had the task to create a box for a Symfony app for the first time. I thought “all right, no problema! this will be a piece of cake, I already know the process, I just need to put it on puppet”. And of course I was wrong.

Most of her problem revolved around performance - the Symfony applications were taking between 6 to 8 seconds to load. After trying several options (hardware and software), she narrowed it down to the overall I/O as the application was trying to access an NFS mounted directory for the "vendors" folder. She changed around the locations of some of the directories and was able to drop the page load times by quite a bit. She's posted the results of her work as a Vagrant file for easy download and use too.

Phil Sturgeon has a new post today that looks at the relationship between the PSR-0 standard (autoloading structure) and Composer - noting that they're friends, not relatives.

As a huge proponent of Composer, a happy user of PSR-0 and a voting member on the PHP-FIG I get into plenty of conversations about all of them and it worries me how much confusion there is in the community about these things not actually being related. [...] It seems that a lot of folks discover Composer and PSR-0 at the same time and seem to assume they are the same thing - especially since both Composer and PSR-0 have the idea of a "vendor" and a "package", but those two things are not related to each other either. These are a few points that I have wanted to clarify during some strange conversations over the last few weeks.

He goes on, trying to clear up some of the confusion around the idea of "vendors" and vendor names. He talks about naming schemes and how they may or may not be related to the vendor name on the package. He looks at the PSR-0 loading methods and how the structure of the library/repository effects that (noting that Composer can be made to accommodate something not PSR-0 by default). He suggests that PSR-0 needs to remain "implementation agnostic" and that Composer, at the same time, should remain "specification agnostic" .

Time are getting tough out there - a recession is coming around and companies all over are feeling the impact. People are looking for places to save money without having to compromise on functionality and quality. Larger numbers are turning to Open Source communities to provide solutions to fill that gap. Stefan Koopmanschap looks at this trend in his most recent blog post.

As we all know by now, we're living in times of crisis. A recession is hitting us, and it's hitting us hard. Even here in The Netherlands, where at first it seemed we'd be avoiding the biggest hit, we're now getting reports that the recession is the biggest since WWII. The crisis seems to be hitting bigtime in many places. So how does it affect open source and PHP?

Stefan talks about Enterprise resources and their shift in needs away from the "vanity projects" and more into the day-to-day, stable clients. Open Source is giving them a bit of that "fun" back in and allowing them to do more with less - little to no licensing, no vendor lockdown, etc.

A little while back on his PHP Kitchen blog Demian Turner asked the question, "Is vendor sponsored software certification the way to go?". An easy example? The Zend Certified Engineer tests.

Currently Zend certification is one of the only options available to PHP devs who want to get accredited, however. But judging by general feedback from the community it would appear that, despite the current certification choices, quality discrepancies between PHP devs on the market can still be pretty...impressive.

He points to another post from Darren Hague (on Derren's SAP blog) that has three elements that any good certification needs to really be considered successful:

• Quality - it must be professional and independent
• Portability - it must be independent of the company you work for at the time
• Customer Demand - without demand for certified people in that area, there's no reason to have the certification

Be sure and check out some of the comments to Demian's post form some other opinions.

Paul Jones has a quick note on his blog today mentioning the updates recently made to the "Getting Started" documentation for the Solar PHP framework. There's five new sections as a result of the overhaul:

• A howto on download and installation
• Creating a workspace
• Making an application inside it
• Working with your first model
• Combining the model and app.

You can find out more about this PHP MVC framework on its site - SolarPHP.com.

On the SaniSoft blog today, Tarique Sani has a quick hack for CakePHP users needing to transition over from the deprecated vendor() call - import().

Use of vendor() function to load third party libs in CakePHP has been deprecated for some time now... It has been replaced with the more generic App::import() the usage is simple.

There's also a little trick you'll need to know for files with underscores (drop it and replace with an uppercase) and how to get it to be a bit more flexible and recognize vendor files in subdirectories or ones differently named.

Felix Geisendorfer has a new post today showing off an example of his screencasting abilities. Specifically, the video looks at using vendor branching to keep your CakePHP installation up to date.

So here I go with my very first screencast to be published. The topic is how to use vendor branching with CakePHP which is one of many ways to keep your CakePHP version up to date.

The video is 15(ish) minutes long and covers, from start to finish, the process of grabbing the latest CakePHP build from the subversion repository and install it automatically to your system.

As a plus, Felix also includes links to the software he used to make the screencast for those that are curious.