Evan Coury has a new Zend Framework 2 related blog post looking at how to use module specific layouts in your application (even though, technically, it's more related to the controller).

There's really no such thing as "module-specific" anything in ZF2, so what we're really talking about is the topmost namespace of the controller being dispatched. So in the case of MyModuleControllerSomeController, the topmost namespace would be MyModle. In most cases, this will be the name of a given module.

He gives a quick piece of sample code showing a "Module" class that attaches an event on the dispatch of its request. Inside this event, he grabs the controller (target) and updates the layout via a call to the "layout" method. This is all handled in the "init" method of the module, so it should "just work" when the module is used.

In this recent post on Reddit.com, there's some good discussion/feedback about the proposed redesign of PHP.net.

Opinions from commentors range widly:

• "The layout's nice. But those colors are downright disgusting."
• "To be honest, the new version is 100x better."
• "It's definitely way better than the old design but still not exactly great is it?.."
• "Much more profressional. Welcome to the 21st century PHP.net."

Have an opinion on the new layout? voice it here!

Joris de Wit has a (very) quick post about a handy tip he found about switching layouts easily with Twig in his Symfony2-based application - a handy ternary sort of switch that can detect when something's an Ajax request.

I just learned about the 'app' global variable in twig. It's very handy for loading a special layout for ajax requests.

The "app" variable allows you get get back at some of the settings of your application and check on special things like the isXMLHttpRequest in his example. For more information about Twig and how you can add it to your application, check out Twig-Project.org. Using it's as simple as adding a phar.

In a recent post to the 3 Engineers blog, they take the usual "Two Step" approach the Zend Framework takes to generating view data (Zend_View + Zend_Layout) and takes it up one more step by using Three Step Layouts with a simple wrapper.

While the Two Step View pattern creates a reasonable paradigm for seperating layout presentation from page presentation, enabling Three-level Inheritance allows for even better separation. In other words, using 3 Step Layouts is a possible and often necessary investment to make when implementing front-ends in Zend Framework projects; they allow fine grain re-usability that provides for a DRYer presentation layer.

They have a three step process you can follow (complete with code snippets) that'll have you working with their 3 layers easily. The wrapper is a sort of "boostrap" for the layout. The nested layout is then pulled into this wrapper (for example's sake, theirs is called "default") and then the view can be served as normal and placed into the content location. There's also a bit of code showing how to switch out the layout if there's ever a need - like different layouts for the admin, user and main parts of your application.

If you've ever wanted to have a form that stuck with every page of your Zend Framework application, Rob Allen might just have your solution in his latest blog post.

I recently received an email asking for my advice about how to handle a form that appears on every page. I want to add a newsletter sign up box to layout.phtml so it will appear on every page. The layout->content() comes from several different action controllers... So how do I handle the newsletter sign up? I thought that the answer is long-winded enough to be worth writing a blog post about. One way to do this is to use a action helper, so let's build a simple application to show this solution.

He walks you through the creation of the simplest part first - the form that will live inside of the view helper. He chose a signup type of form with a username, email and submit button. He helps you create an action helper and the view helpers to help inject the form into the layout of each page. Then, with a simple call to "$this->signupForm()" you can drop it in anywhere in the layout.

On PHPBuilder.com there's a new tutorial on layouts in Zend Framework applications. The tools the framework gives you makes things much simpler when it comes to changing layouts and updating the general structure of your site.

Gone is the need to devise strategies for important tasks such as maintaining page headers and footers, separating the bulk of a page's logic from its interface, and managing the code repeatedly used throughout the site to carry out special formatting actions. Instead, you can just embrace the framework's conventions and move on to the next battle. This article introduces you to some of the fundamental concepts behind managing layouts within your Zend Framework-driven applications.

He shows how to enable the layout management tools and how to create a sample layout to ensure it's working. You can also switch layouts, disable them and use a few of the helpers that come with the tool to make it simpler for you and make your development time faster.

The NETTUTS blog has another WordPress-related post today that looks at "context includes" - changing the look and feel of the postings based on the content type they're tagged with.

The great thing about WordPress is that it doesn't limit how content is displayed, but provides a 'framework' of ways to do so. Even better, it's possible to change the display according to the content. When writing this tutorial it was hard to explain what's going on... But the best way is this: the post will be displayed within the loop according to its content - or contextual differences. Either way, it's including specific files that match up to the category of the post.

There's plenty of code to go around introducing you to the parts of the typical WodPress install you'll be working with and some CSS to help you style the resulting changes. You can download the source and check out a live demo of the end result.

With the recent stir caused by the new iPhone, it's only natural that developers are looking for easy ways to make their sites as compatible as possible with the mobile platform. The Symfony project has posted a guide to helping you make your apps optimized for mobile use.

symfony 1.1 introduces native support for different formats and mime-types. This means that the same model and controller can have different templates based on the requested format. The default format is still HTML but symfony supports several other formats out of the box as defined in the factories.yml file.

Using this system, it's easy to add new output formats by adding to the default layouts the framework comes equipped with. The Content-Type can be changed and layouts can be disabled as needed. This lets you make a custom definition just for use with the iPhone without a lot of hassle.

They also include an example of how to make one of these optimized layouts, including some iPhone "screenshots" of the resulting pages.

The Developer Tutorials blog has posted a series they've worked up to show bloggers out there running WordPress how to create a custom theme from scratch:

In this multi-part series I'll detail how to create and design a Wordpress theme from nothing more than your imagination using Photoshop, CSS, XHTML and PHP.

Here's the list so far:

• Part 1 - getting the tools and an overall layout idea
• Part 2 - splitting it up to make the layout parts
• Part 3 - converting the Photoshop template to XHTML
• Part 4 - cleaning up the XHTML and doing some styling with CSS
• Part 5 - how to preload some images with Javascript to make the page load faster
• Part 6 - creating the WordPress-specific markup
• Part 7 - working up the PHP functionality
• Part 8 - integrating PHP into the template
• Part 9 - marking up the "framework" of the site (header/footer/sidebar)
• Part 10 - adding additional files like a links page and changing the posting template
• Part 11 (?) - deploying the theme out to the public view

Helgi has posted about the updates that have recently been made to the PEAR website (pear.php.net) to help correct some issues and bring in some new features.

I just did a new release of pear.php.net which has a bunch of new features and bug fixes, most of which you can see here.

Some of the updates include:

• One column design instead of the 2 column design
• Usage of the YUI CSS reset + fonts
• The package list on http://pear.php.net/packages.php doesn't highlight deprecated packages anymore
• Now developers can see bug reports by unconfirmed accounts
• The RSS feeds now contain new line breaks!
• Patch uploading during ticket creation now works

He also specifically mentions some of the feedback he's gotten on certain things (like the new layout, the CSS of the site and the DES passwords) and explains some of the rationale behind their update/use.