The SitePoint PHP blog has a recently posted tutorial showing you how to send event messages from PHP to a remote Logstash server running your PHP on a system with Windows installed. Logstash's goal is to centralize the logging in your environment, allowing you to input log information from a wide range of sources and stored in an Elasticsearch database.

By opening this article you’ve endeavored yourself to expanding your knowledge of PHP applications as part of event-based distributed systems. You’ll be given a quick intro into what we are referring to when we say event messages, what Logstash is, and why it is so cool.

If you’ve already heard of Beats or understand you can run Logstash locally to ship logs to another Logstash instance or directly to a datastore such as Elasticsearch, this article is still for you and will show you an easy-to-configure-and-run, hopefully more effective and certainly fun-to-use alternative.

They start with the quick introduction to Logstash and how the event handling they'll add in later will relay messages over to the waiting server. A code example is included showing how to manually write to rsyslog, pointing out that it and Logstash use a similar protocol to receive messages. The tutorial then shows how to view the messages in the log to ensure they're making it correctly and how to use this agent to stream messages over to the waiting server.

The SitePoint PHP blog has a new tutorial posted hoping to demystify some of the confusion around HTTP and PSR-7, a standard from the PHP-FIG group around the handling of request and response messages in PHP applications.

The PHP Framework Interoperability Group (PHP-FIG) has relatively recently approved another proposal, the PSR-7: HTTP Messages Interface. The document crystallizes HTTP messages into 7 interfaces which a PHP library should implement if they subscribe to the specification. In PSR-7 By Example, Matthew Weier O’Phinney, editor of the PSR, gives an interesting overview of the specification. So what is it?

They start with the HTTP side of things, briefly covering what HTTP messages are and the format they're transmitted in. Using some example curl requests they show requests and responses involving normal responses, redirects and how they're broken down into objects implementing the MessageInterface, RequestInterface and ResponseInterface. They outline the PSR-7 specification in a UML diagram and talk about some of the challenges associated with PSR-7's handling (including the use of immutable objects and how it fits in with middleware handling).

The post ends with a listing of a few of the frameworks/libraries that already make use of the PSR-7 structure including Symfony, Slim, Guzzle and the HTTPlug client.

In this new tutorial to the NetTuts.com site author Jeff Reifman shows you how to use the Google Translate API to translate the content in your application/website to the language of your choosing. In his examples, he shows how to integrate it with a Yii framework application.

In this tutorial, I'll walk you through my extensions to the Yii I18n extract script which do exactly this. And I'll demonstrate translating my startup application, Meeting Planner, into a handful of languages. Keep in mind, Google Translate isn't perfect and it doesn't address issues related to time and date formats and currencies. But for a quick and affordable (free) way to build default translations for your web application into 50+ languages, this is an ideal solution.

He starts with a brief introduction to the Google Translate API, the languages it supports and how to install the library he's chosen to make the connection. He then gets into the internationalization (i18n) functionality that Yii has (an introduction to that is here) and how to define the "messages" files with the different content strings. These files are defined to there's no need to call out to the API for every piece of content that loads. He shows how to extend the message extraction handling to add in the API request and parsing the result. This information is then added to the current message information files, making it simpler to add in new strings. He then integrates this into the Meeting Planner application and shows how to run the script to call the Google API and switch the language with image results in several different languages of the finished output.

Rob Allen has been working with the Zend_Filter component of the Zend Framework and has discovered a few things:

The basic usage of Zend_Filter_Input is [a simple call to Zend_Filter_Input with the filter types and data to filter]. The problem is that the message you get out isn't always written as you would like. Consider the output if the body record is empty. The text isn't exactly what I would want to display to a user. To change it you pass in a messages parameter to the $validators array.

There's a long list of these "messages parameters" and Rob includes them in the post - things like NOT_ALNUM, CHECKSUM, QUOTED_STRING, INVALID_DASH and UNDECIPHERABLE_TLD (37 of them in all).

Rob Allen has been working with the Zend_Filter component of the Zend Framework and has discovered a few things:

The basic usage of Zend_Filter_Input is [a simple call to Zend_Filter_Input with the filter types and data to filter]. The problem is that the message you get out isn't always written as you would like. Consider the output if the body record is empty. The text isn't exactly what I would want to display to a user. To change it you pass in a messages parameter to the $validators array.

There's a long list of these "messages parameters" and Rob includes them in the post - things like NOT_ALNUM, CHECKSUM, QUOTED_STRING, INVALID_DASH and UNDECIPHERABLE_TLD (37 of them in all).

DevShed is continuing their look at the creation of an email application with the third part of the series. It looks at building the main index page of the application as well as some of the sub-pages that it links to for other features.

The index page displays the newly downloaded messages in a table with five columns. These columns list (among other things) the date, subject and from field of the messages.

They break out the actions the page takes when someone logs in/views email - grab user info, grab messages, and display the navigation panels. Since they've already looked at the first of the list in a previous tutorial, they cover the last two, showing how to create the navigation (and some sub-pages) and how to grab all of the messages for the currently logged in user.

DevShed is continuing their look at the creation of an email application with the third part of the series. It looks at building the main index page of the application as well as some of the sub-pages that it links to for other features.

The index page displays the newly downloaded messages in a table with five columns. These columns list (among other things) the date, subject and from field of the messages.

They break out the actions the page takes when someone logs in/views email - grab user info, grab messages, and display the navigation panels. Since they've already looked at the first of the list in a previous tutorial, they cover the last two, showing how to create the navigation (and some sub-pages) and how to grab all of the messages for the currently logged in user.

DevShed continues their look at the creation of a simple blogging script with part three of the series (part 1, part 2) - the creation of an admin utility to work with the contents of the blog.

The idea is to give the owner of the blog the ability to manage the blog by being able to remove users and articles as required, or to alter the status of users by upgrading them to admin status or banning them. It is also a place where the administrator can start new topics that will then garner their own replies.

They go through the creation of the main admin script (functionality managed with a switch statement, including other external PHP files) and the functions that go in each of those individual files to make things work - managing messages, managing users, and managing categories.

DevShed continues their look at the creation of a simple blogging script with part three of the series (part 1, part 2) - the creation of an admin utility to work with the contents of the blog.

The idea is to give the owner of the blog the ability to manage the blog by being able to remove users and articles as required, or to alter the status of users by upgrading them to admin status or banning them. It is also a place where the administrator can start new topics that will then garner their own replies.

They go through the creation of the main admin script (functionality managed with a switch statement, including other external PHP files) and the functions that go in each of those individual files to make things work - managing messages, managing users, and managing categories.

The Adobe Developer Source has posted a new tutorial showing how to, with the combination of PHP and Flex, to browse the contents of a MySQL database.

One critical element to remember about programming with Flex is that it cannot connect to a database directly - it requires some form of middleware in order to access data. You'll be using PHP in order to generate the XML files that Flex will use to manipulate the data from the database.

PHP plays the middle-man in this lengthy tutorial, passing XML messages back and forth between the Flex application and interpreting it into MySQL queries and results. They take the PHP script through, step by step, to ensre you know exactly how it works. Next up is the Flex, complete with the code listing to create the simple database browsing application.

There's explainations, screenshots, and even a little ActionScript here and there, but in the end, you'll have a light, simple database browser to view the contents of your table.