The NetTuts.com site has posted a tutorial (the third and last in their series) showing how to override controller handling in Magento. In the previous posts they showed how to override functionality related to the models and blocks (frontend layout elements).

In Magento, the controller is responsible for handling incoming requests, and it's a backbone of the Magento routing implementation. [...] As I said in the previous tutorial, it's never recommended to change core files directly, as it makes upgrading Magento really difficult. To avoid this, we should follow the standard way of making desired changes to core files: we should either use event observers or override core files with our custom module files. We'll discuss the overriding feature today.

You'll need to be familiar with custom module creation to be able to follow along (see here if not) but other than that they provide everything you'll need. They start by creating the files and folders needed for the custom module including:

Module XML definition (Envato_All.xml)

Module XML configuration

the Envato_Catalog_ProductController controller file (PHP)

The controller extends the pre-existing Product controller but the configuration definitions tell it ti use the "Envato" version instead.

Mattias Noback has posted a three part series of tutorial articles around the refactoring of a "CatApi" class. These articles take the class from a jumbled mess of functionality with both direct file access and remote requests mixed in into something much more maintainable and flexible.

t turned out, creating a video tutorial isn't working well for me. I really like writing, and speaking in public, but I'm not very happy about recording videos. I almost never watch videos myself as well, so... the video tutorial I was talking about won't be there. Sorry! To make it up with you, what follows is a series of blog posts, covering the same material as I intended to cover in the first episodes of the tutorial.

In part one he introduces the current state of the "CapApi" class and some of the problems with it, both in testing and in structure. He does some basic refactoring to split out some of the logic here and moves on to part two. In the second part of the series he focuses on refactoring the HTTP request and the local file system functionality into abstract, injectable objects. Finally in part three he adds in some verification around the data being passed back and forth between objects including both simple checking and the use of value objects.

In a new post to the ServerGrove blog they look at linting tools for various circumstances including standard PHP, Twig templates and Composer configuration.

Today’s projects are built up from dozens of different components, configuration files, third-party libraries, tests, build scripts, etc. And even if you have the greatest test suite, bad things can happen sometimes. It’s important to catch bugs as early as possible, and syntax validators can be a great (and easy) addition to your continuous integration system. You would be surprised at how many problems are caused by syntax errors. At ServerGrove, we see these kind of problems with our clients almost every day.

Their list shows you how to lint (syntax check) several different types of content:

standard PHP code

Twig templates

Composer configuration

XML files

Bash scripts

JSON files

YAML files

Some of them use tools that already come built-in (like PHP's "-l" or Twig's "twig:lint") but others require the use of external software such as xmllint or melody. Command examples are also included for each.

On the This Programming Thing blog there's a recent post showing you how to define your own "sniff" settings for the popular PHP_CodeSniffer tool. The codesniffer lets you define standards that need to be in place for all code in your application and notifies you of violations.

At Zimco, we’ve started working on standardizing our coding but we ran into a little problem while we tried to automate the process of making sure our code adhered to that standard. [...] I think we get into our own way of doing things and everything else is wrong. This code makes me feel irrationally angry (so angry I’m having a hard time not fixing it…). Ultimately, the best way to fix these kinds of formatting problems is to sit down and discuss what’s best and have everyone stick to the same set of standards.

They talk some about the place for PSR in coding standards (specifically PSR-2) and the fact that there's already "sniffs" provided to check against those rules. However, they point out that running this against a non-PSR-2 codebase can be a mess and show you how to customize your own standard to more match your current state. They use an XML configuration file to update the tab width setting to four spaces and then apply the PSR-2 standards. They also show how to exclude certain rules and mention a handy plugin you can use in Sublime Text to keep your code within standards.

If you are writing or consuming API's in PHP, chances are that you need to work with XML. In some cases you may even prefer it. You may have started with SimpleXML and after a while switched to using the DOM after realizing SimpleXML is really not that simple if you strictly use xml namespaces everywhere.

For writing XML, you may have found that using the DOM requires far too much code, or you may simply generate your XML by echoing strings, knowing that it may not be the best idea. sabre/xml hopes to solve your issues, by wrapping XMLReader and XMLWriter, and providing standard design patterns.

He includes some example code showing how it works, extending the XMLReader/Writer functionality with a simplified interface. He includes examples of both writing a new XML file or reading in and working with the contents of a given one. He does point out one issue, though - the library cannot really read in XML contents, modify it and send it back out (it's a "single pass" system). He wraps up the post talking about the various interfaces and elements in the library and some of the overall benefits it provides.

The Web Mozarts blog has an interesting new post today that talks about using annotations in your PHP code to define the attributes in resulting XML that could be generated dynamically from your objects.

Annotations have become a popular mechanism in PHP to add metadata to your source code in a simple fashion. Their benefits are clear: They are easy to write and simple to understand. Editors offer increasing support for auto-completing and auto-importing annotations. But there are also various counter-arguments: Annotations are written in documentation blocks, which may be removed from packaged code. Also, they are coupled to the source code. Whenever an annotation is changed, the project needs to be rebuilt. This is desirable in some, but not in other cases.

They focus in on Symfony-based applications as a good base to work from (as they've pushed to have annotations work in the code for things like routing and data type definition). He starts with an example Doctrine class - a "best buddy" for Symfony as far as annotations go - and how the annotations define the different properties. He also includes an example of the XML output of the same definition generated through an "AnnotationReader" instance. He talks about having multiple XML documents representing one object with different annotations put in each, including the XML output. The post finishes with some advantages including the ease of validation by XML-friendly tools looking to interface with the application.

In this new post to his site Thomas Weinert shows how to use the FluentDOM library (a PHP implementation of a Javascript library by the same name) when XML namespaces are involved.

FluentDOM 5 allows to register namespaces on the DOM document class. These are not the namespaces of a loaded document, but a definition of namespaces for your programming logic.

He compares it to both a PHP example, using the DOMXpath handling and a Javascript sample using its own xmlDocument functionality. Finally he compares these examples to the few lines of FluentDOM code to handle the same kind of evaluation. He wraps up the post with a brief mention of the "appendElement" function that wraps serveral operations in one for easy element additions.

On PHPBuilder.com today they have a new post showing different configuration patterns for getting localized settings into your applications. They show the use of INI files, PHP scripts, text files, XML data and a database call.

PHP is a cross platform language. It is a server based application so we must think about the configuration settings of the PHP software. There are various ways of creating configurable PHP applications. The configuration flexibility comes as a built in feature in PHP. But we must understand the requirement clearly before making an application configurable. This article explores different PHP configuration patterns and their implementation.

For each of the options mentioned, there's a brief description of what the method is, some of the common uses and a code example showing a basic implementation. The database pattern is the only one without a code example as the database interface varies widely from application to application.

On the tech.pro site there's a recent tutorial posted showing you a basic way to create an RSS feed using data coming from a database accessed via PDO.

Using an RSS feed on your website is a great way of letting your visitors, search engines or directories get a hand on your content. RSS feeds are common practice on most blog and CMS platforms including Wordpress, Joomla and evenly the newly released Ghost. If you're using a CMS or similar platform, the likelihood is that you don't need to implement an RSS feed yourself. [...] Below you've got the step-by-step process to create anything from the simple, standard-compliant RSS feed - up to the more advanced.

The tutorial shows you how to pull the data from a simple database table (SQL not provided, but pretty easy to figure out(, including example PDO connections for several database types. This data is then manually appended into an XML string to build out the RSS feed correctly. They also talk about implementing the Dublin Core metadata as a way for providing more information about the feed and its contents (including an image and category details).

I was pleasantly surprised to see the Navigation component of Zend Framework 2 includes a bunch of view helpers, including a Sitemap helper. So now I have an xml sitemap created by Zend Framework 2 that works hand in hand with the site navigation. However, the documentation was not complete as of this writing and caused me to do a bit of trial and error debugging to get it working. Below I will post how I got it working, in hopes it will help others.

The code to get it working is relatively simple - set it up in the module configuration, specify the navigation structure and add a route for the sitemap output. The view then accesses the navigation handling and calls a "sitemap" method to push the XML result out to the user.