On his site Matthew Weier O'Phinney has a new post sharing a method he's worked up for creating a Docker image for PHP from an Alpine image that included the "tidy" PHP extension.

I've been working on building PHP Docker images for the purposes of testing, as well as to potentially provide images containing the Swoole extension. [...] This week, I decided to see if I could build Alpine-based images, as they can greatly reduce the final image size. And I ran into a problem.

One of the test-beds I use builds RSS and Atom feeds using zend-feed. When I tried one of these images, I started getting failures. [...] During an initial search, this appeared to be a problem due to libxml2 versions. [...] I realized [after debugging] that the problem was the content — which was being massaged via the tidy extension before being passed to DOMDocument::loadXML(). For some reason, the content generated was not valid XML!

In order to solve this issue (after spending a good deal of time debugging it) he went on a hunt to figure out the previous version. Once he found that it was just a few simple lines in his Dockerfile to include the right version and install it using the apk package manager (example of this is included).

In a post to the bitExpert.de site Stephan Hochdörfer explains why he thinks that using code over configuration in a DI container is a better approach than static configuration definitions.

In my recent talk on introducing Disco - the DI container with the damn coolest name(tm) - I talk about why I believe that using XML or any other non-code configuration (YAML, JSON, ...) is not a good idea. This stirred some twitter discussion recently which led to this blog post.

Just for the record, for a very long time I was part of the XML camp - just browse my collection of old talks to see for yourself. I praised XML a lot as being the only true DI configuration format.

He then goes through some of the main issues he sees with using something like XML for the dependency container's configuration:

• An XML editor won't give you code-completion for PHP classes or methods.
• Refactoring won't work properly in an XML configuration file.
• An XML editor is not capable of doing proper type checks.
• XML is just too verbose.

For each item he provides a brief explanation and an example of XML where it helps to illustrate the point.

The Zend Framework blog has posted another tutorial focusing on the use of one of the components that makes up the framework. In this latest tutorial Matthew Weier O'Phinney focuses on the zend-dom component and how to use it for scraping content from remote sources.

Even in this day-and-age of readily available APIs and RSS/Atom feeds, many sites offer none of them. How do you get at the data in those cases? Through the ancient internet art of screen scraping.

The problem then becomes: how do you get at the data you need in a pile of HTML soup? You could use regular expressions or any of the various string functions in PHP. All of these are easily subject to error, though, and often require some convoluted code to get at the data of interest.

[...] zend-dom provides CSS selector capabilities for PHP, via the ZendDomQuery class. [...] While it does not implement the full spectrum of CSS selectors, it does provide enough to generally allow you to get at the information you need within a page.

He gives an example of it in use, showing how to grab a navigation list from the Zend Framework documentation site (a list of items in a <ul> tag). He also suggests some other uses of the tool including use in testing of your application, checking content in the page without having to hard-code specific strings.

In a new post to his site Rob Allen shows you how he adapted a package of his own to work with a Slim framework based API to render "ApiProblem" types correctly (according to this specification).

In the API I'm currently building, I'm rendering errors using RFC 7807: Problem Details for HTTP APIs. As this is a Slim Framework project, it uses PSR-7, so I updated rka-content-type-renderer to support problem.

RFC 7807 defines a standard for sending details of an error in an HTTP response message. It supports both XML and JSON formats.

He starts with an example of the "Problem" response format that includes data for the type of error, details and links to other related objects. He points out this package from Larry Garfield that handles the actual output of the respose format but Rob needed a way to shift between JSON and XML formats too. This is where his updates to his package came in, changing it to include a ApiProblemRenderer that reads the "Accept" header of the incoming request and correctly formats the results accordingly.

On the Laravel News site today there's a post showing you how to create a basic sitemap for your Laravel-based application. This method uses straight up Laravel functionality (not the method previously mentioned in another post).

A few years ago search engines recommended submitted sitemaps to help with indexing your website and now the importance of this is debatable.

I’m of the mindset creating and submitting can’t hurt, so I spent a little time putting one together and wanted to share how easy this is in Laravel. [...] A sitemap is a file where you can list the web pages of your site to tell Google and other search engines about the organization of your site content. Search engine web crawlers like Googlebot read this file to more intelligently crawl your site. [...] On the official Sitemaps website it outlines all the information you will need for building your own sitemap.

He outlines some reasons why your site might need a sitemap before getting into examples and the code to create them. He starts with the controller and moves into making the index (with matching XML view) and the endpoints for the URLs referenced in the main sitemap. Finally a few routes are added for each endpoint and links to extending the contents and structure are included.

In this new tutorial Zsolt Szende talks about dependency injection and how to handle objects and related needs at runtime rather than the pre-configured method that some injection containers/systems have defined.

In this short article I would like to demonstrate a way to inject dependencies that are not known until runtime. There are many use cases for this and in essence it is about choosing between concrete implementations of some common interface. In object oriented design this is known at the Strategy pattern. The choice itself can be made in various ways, for example via a configuration option or a command line parameter in case of a console command, and I think the dynamic nature of the choice is the most interesting part of the pattern.

The article provides a practical example of an XML/JSON reader pulling information from an external source. A simple interface is defined and two implementation classes put it to use. Then the "command" pattern is used to apply it to an executable script and how injecting a reader type directly overrides the one from the provided option. This is taken a step further and refactored into a "resolver" to determine the best logic to apply based on the input argument.

The Paragon Initiative site has a new tutorial posted aiming to help you more securely use the serialize and unserialize handling in PHP to prevent security issues. In this tutorial they offer some advice - mainly don't unserialize unless you're on PHP7 - and some other solutions you could use.

A frequent problem that developers encounter when building web applications in PHP is, "How should I represent this data structure as a string?" Two common examples include:

• Caching a complex data structure (to reduce database load)
• Communicating API requests and responses between HTTP-aware applications

This seems like the sort of problem that you could expect would have pre-existing, straightforward solutions built into every major programming language that aren't accompanied by significant security risk. Sadly, this isn't the case.

He starts with a look at the serialization handling and how it could allow remote code execution if an attacker were to modify the serialized data. He includes an example of using the new "allowed classes" parameter in PHP 7 too, though, preventing the issue. He also walks through two other ways you could replace serialized data: JSON structure and XML handling. Each of these have their own issues too but they're very different than the code execution with serialization.

Rob Allen has a quick post to his site talking about some of the improved error handling that's been updated in the latest version of the Slim microframework to help make reporting issues easier in multiple contexts.

From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page [...] However, if you're writing an API that sends and expects JSON, then it still sends back HTML. [...] At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client has asked for JSON. Until RC1, the only way to do this was to register your own error handler.

With Slim 3 the framework handles things more correctly based on the value of the "Accept" header sent along with the request. This value is checked and, if it references JSON or XML, the error message is translated either giving the default output or reporting back for the "notFound" and "notAllowed" error types.

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.