On PHPBuilder.com there's a recent post looking at debugging Magento applications with some of the built-in tools the platform makes available.

Magento is the world's most popular open source e-commerce platform, relied upon by countless Fortune 500 and small business alike for selling goods and services of all types. [...] But with Magento's considerable power comes a great deal of complexity [but] it can be incredibly difficult to even identify the origin of an error let alone resolve it. You can however dramatically improve your productivity as a Magento developer by taking advantage of a few key debugging features.

They recommend using four tools built into the platform - the developer mode, logging, template path hints and viewing the raw SQL queries. They also recommend using a few other tools like FireBug and the features of Eclipse to help with code formatting and completion.

PHPMaster.com has a new post with ten helpful tips for you to consider using during your development. These tips can help to not only make your current development simpler but make for easier to maintain, stronger code in the future.

Good code is maintainable, reusable, and testable. The following tips address how you and/or your development team can handle various coding tasks and how to keep everything as neat as possible. I will introduce you to some "best practices" that will help you write better code and help make you and your team happy and efficient.

Among the suggestions on the list, there's things like:

• Use a Coding Standard
• Refactor
• Use Meaningful Names
• Use Automated Build Tools
• Use a Testing Framework

Links are provided in several of the tips to other resources/tools that can provide you with more information about how to use it in your development.

On the NetTuts.com site today there's a set of reminders about some software principles that all developers (PHP or otherwise) should keep in mind when doing their work:

he fundamental things will always apply. If you have an understanding of the underlying ideas of software development, you will quickly adjust to new techniques. In this tutorial, we will discuss three basic principles and mix them with many more. They provide a powerful way of managing the complexity of software. I'll share some of my personal opinions and thoughts, which, hopefully, will prove useful when it comes to applying them to code and real-world projects.

Their three ideas that should always be in mind during development are:

• DRY - Don't Repeat Yourself
• KISS - Keep It Simple Stupid
• "You Ain't Gonna Need It" (YAGNI?)

For each principle, there's a but of an example showing either some current project that follows the idea or a process that can be used to implement it.

In this new post to his blog Anthony Ferrara responds to some of the recent news about PHP standards being up for voting (PSR-1 and PSR-2). He has an issue with how they were created, though, and notes that the current PSR process doesn't encourage open standards.

There has been a lot of traction lately on the topic of the PSR "PHP Framework Interoperability Group". They are introducing two new proposed standards: PSR-1and PSR-2, both dealing with code formatting standards. [...] I have read both, and actually agree and think they are quite good. However, there's a deeper problem. Open Standards is something that the internet was built upon. From HTTP, E-Mail and HTML to ECMA Script (JavaScript), OAuth and JSON, open standards are everywhere. The problem with the entire PSR process is that it is not designed to produce open standards.

He describes an "open standard" and points to this RFC as an example of the open process they should result from. He talks about the importance of the process and how having more people reviewing and contributing their ideas could help find issues in the proposal. He issues a "call to the PSR team" to adopt this practice, allowing a more open flow to the ideas that are being proposed.

Note that I'm not asking to open the vote to anyone else. I'm not saying that standards should be approved by everyone in the community. There should still be a standards body that makes the final decision. But they should make that decision based on community input. They should actively look for and encourage open discussion prior to voting.

• Elated.com: Object-Oriented PHP: Working with Inheritance
• PHPBuilder.com: Tracking User Activity in PHP with Cookies and Sessions
• Shameer Chamal's Blog: Tutorial : Simple ajax validation for Kohana
• Box UK: Unboxing: Silex
• Michelangelo van Dam's Blog: Book Review: PHP Development in the Cloud
• Omar Abdallah's Blog: Installing LAMP with PHP 5.3.6 on Ubuntu 11.04 Natty Narwhal
• NetTuts.com: Easy Authentication with CodeIgniter
• Zend Developer Zone: Caching of Zend Framework application configuration file
• DZone.com: PHP Tool Integration (PHPsrc)
• Symfony Blog: Symfony2: Annotations gets better
• Justin Carmony's Blog: MySQL, Redis, and a Billion Rows - A Love Story
• Jani Hartikainen's Blog: You don't need a service layer: Fat controllers are okay
• Christian Weiske's Blog: How to integrate PHP_CodeSniffer with Git repositories?
• Slawek Lukasiewicz's Blog: Zend Framework: logging with Firebug and FirePHP
• Till Klampaeckel's Blog: Yahoo: oauth_problem=consumer_key_rejected

Paul Reinheimer has posted about his experiences with sending mail, specifically as it relates to using the Zend_Mail component from the Zend Framework to handle the details.

Like every product, Natural Load Testing needs to send some mail, having written and re-written a bunch of different blocks of mail code over the years, I wanted to come up with something that would work now, and continue to serve us well into the future.

He chose Zend_Mail to fulfill some of his requirements (multipart emails, sending custom emails, templates for automatic emails) and includes some sample code showing it at work. The result is an object that can be created and, by calling a "basic" method, can send an email based on an HTML template (using the HTML Email Boilerplate for the base styling).

Phil Sturgeon (a developer on the FuelPHP and CodeIgniter frameworks) has a new post to his blog today talking about the Laravel framework and how "it's awesome" .

You might not expect to hear that from a CodeIgniter and FuelPHP developer, but it's true. Taylor has done a brilliant job writing code that is clean, functional and has built a huge community of smart developers in less than a year of active development. People are flooding to Laravel from other frameworks and that's great for the PHP community. [...] Taylor has done a brilliant job of building up a framework that takes advantage of callbacks, IoC and event driven behaviour very well.

He talks about why he likes Laravel and the features it includes that appeal to him...and why he doesn't use it yet. He notes that it's a "snazzy new framework" that gives PHP developers tired of the usual framework methods something new to try out, noting that it can help to keep the "brain drain" of PHP developers away from the language just because they get bored.

In this recent post to her blog Lineke Kerckhoffs-Willems talks about some recent Symfony2 development she's been doing and some of the trials she's come across when trying to implement the SonataAdminBundle to build on their pre-existing Doctrine2 entities.

I have been doing a lot of Symfony2 development lately for our project ProTalk and one of the things we needed was a backend for our database. This should be a fairly simple backend to start with, just an easy way to get data into the database. So I thought I would use the SonataAdminBundle to easy generate this backend based on the doctrine2 entities that we already have. Eventually, I got it working, but it took me some time to find out exactly how, so I thought I'd share my experiences.

Based on some information she found in this other post, she was able to configure and connect it to a "tag" entity. To make it work, however, she needed an empty controller to move forward.

Michael Nitschinger has a new post focusing on one of the more commonly used, but maybe just as commonly misunderstood, part of PHP - exceptions and their handling. His latest post looks at what Exceptions in PHP have to offer and provides some "best practices" in their use.

Exceptions are and should be an integral part of any general purpose programming language. PHP introduced them long ago (with the release of PHP 5 or 5.1), but it still seems that many of the concepts are not fully understood or ignored by the community. This post aims to be a solid introduction to exception architecture, handling and testing. At the end of the post you should be able to know when to raise an exception and how it should look like.

He talks about situations when (and when not) to use exceptions, normalizing them for easier try/catch-ing and includes the exception class hierarchy, including the types pulled from the SPL. He shows examples (based on the Lithium framework's namespacing) how to create "namespaced exceptions" and how to use these in a bit of sample code. He also mentions the use of the custom error handling with the ErrorException as well as a quick look at testing these basic and custom exceptions correctly (PHPUnit-based tests).

On the 9Lessons blog there's a recent tutorial showing you how to log into Instagram via OAuth with the help of their Instagram class.

The very quick registration gives you many users to your web project, we already published login with Facebook, Twitter and Google Plus now time to think about very popular photo sharing portal Instagram. This post explains you how to login with instagram Oauth API and importing user data. Create an instagram account and take a quick look at this demo thanks!

The tutorial walks you through the process of setting up an application in the Instagram service, configuring the scripts with the API key/secret and callback as well as the code for a simple login page. They've also included code to grab the user's information and "popular media" from the web service and pull that information into a local MySQL database.