On the TutsPlus.com site they've posted a tutorial for those new to PHP and MySQL out there sharing the basics of CRUD operations using the built-in language functionality ("CRUD" stands for "Create, Read, Update, Delete").

In this article, we're going to explore how you could use a MySQL database to perform CRUD (create, read, update, and delete) operations with PHP. If you want to get your hands dirty with database connectivity in PHP, this article is a great starting point.

If you are just getting started with PHP, you probably realize that database connectivity is an essential feature that you'll need to get familiar with sooner or later. In most cases, a database is the backbone of any web application and holds the data of the application. So, as a PHP developer, you'll need to know how to deal with database operations.

In this article, we'll keep things simple and explore how to use the core mysqli functions. In upcoming articles of this series, we'll explore a couple of other ways to handle database connectivity.

They then walk you through some of the basics of:

• creating the connection to the database
• selecting information from the database
• inserting and updating records
• how to pull the record information
• deleting records from the database tables

Each item on the list comes with plenty of explanation and example code to get you on the right path to learn these basic concepts.

On the Laravel Daily site they've posted a tutorial showing the Laravel users out there how to create and catch custom exceptions in your application. Exceptions are a useful tool to handle "exceptional situations" where something fails badly enough where the application cannot proceed.

Quite often web-developers don’t care enough about errors. If something goes wrong, you often see default Laravel texts like “Whoops, something went wrong” or, even worse, the exception code, which is not helpful at all to the visitor. So I decided to write a step-by-step article of how to handle errors in elegant way and present proper error information to the visitor.

He uses a "user search" task to help illustrate the methods for creating custom exceptions, catch exceptions and showing the error to the user. Code is included as well as screenshots of the output. With the basics of exception handling out of the way, they move the handling off into a service and take it one step further to create a custom "user not found" exception and its use in the search method.

For those Phar users out there Théo Fidry has written up a guide to help you create and deploy them securely with the help of a few tools and OpenSSL to sign the release to ensure integrity.

For those who are not familiar with it, PHAR (Php Archive) is analogous to the JAR file concept but for PHP. It allows you to package an application into a single file making it convenient to deploy or distribute.

[...] So what are PHARs useful for then? Well still the same thing: packaging applications. Although not many people may want to use this technique for web applications, it is still extremely useful for console applications.

The tutorial starts off by showing a few different methods for installing Phars and how to build them from your code. While they can be built manually, he suggests using the box project to help make it simpler. It also covers self-updating phars and shows how to update the box.json configuration to use a generated key to sign the release. Finally it covers a method for using Travis-CI to auto-build the phar and how to keep the OpenSSL key safe and out of the checked in code.

In a previous post to the Zend Framework blog Matthew Weier O'Phinney talked about parsing feeds with Zend Framework components. In this latest post they cover the other half of the equation - creating RSS and Atom feeds using some of the same components.

In our previous article on zend-feed, we detailed RSS and Atom feed discovery and parsing. Today, we're going to cover its complement: feed creation!

zend-feed provides the ability to create both Atom 1.0 and RSS 2.0 feeds, and even supports custom extensions during feed generation. [...] You can also provide your own custom extensions if desired; these are just what we ship out of the box! In many cases, you don't even need to know about the extensions, as zend-feed will take care of adding in those that are required, based on the data you provide in the feed and entries.

He then shows how to pull in the zendframework/zend-feed component and how to use it to create a simple RSS feed with a title, link, description and "feed link". He then shows how to add new items to the feed (with details for each item) and how to render the resulting feed.

Rob Allen has posted a tutorial to his site making some updates to his previous work with the Doctrine migrations handling as a standalone component. In this new tutorial he talks about the newer way to use it in your projects.

Since, I last wrote about using the Doctrine project's Migrations tool independently of Doctrine's ORM, it's now stable and much easier to get going with.

He starts with the basic installation and configuration of the migrations tool, making use of a SQLite database as an example. He then shows the use of the basics of using it to make database changes:

• creating a new migration
• running the migrations

Each step comes with code, the commands you'll need to execute and an example of the resulting console output.

The Scotch.io site has posted a tutorial that aims to help you understand middleware in Laravel applications - how they work and how to create ones based on your custom needs.

HTTP Middlewares provide a convenient mechanism for filtering HTTP requests entering your application. Laravel, for example, has a middleware for verifying a user's authentication.

These are some cases where I have had to resort to using middleware. There are many more cases where you would like to use a middleware. [...] By the end of this article, you should be able to create a middleware, registers it and use it in your projects. We will be illustrating the creation till usage of middlewares by creating one of our own. Our middleware will enable maintenance either site-wide or on some routes.

They start by creating a middleware (theirs is DownForMaintenance) and how to register it with Laravel as a valid middleware option. By default they will execute with every request but you can narrow them down to only happening on certain routes (examples included). There's also mentions of middleware parameters, grouping middleware and deferring the response return until after other code is executed.

Jeff Madsen has a quick post to his site with the "untold story" behind Eloquent's save and create in the Laravel framework.

Over on Laravel Quick Tips we've been looking at a few of these functions and their uses, and I thought it might be helpful to collect all of them together in a single (I hope) coherent post.

Without further preamble, let's get to it. I'm going to use the basic User object and table that ships with a default installation of Laravel so you can follow along if you like.

He starts with the difference between "new" and "create", pointing out the one fundamental difference: one saves, one does not. He then looks at some of the other new/create functions (like findOrNew, firstOrCreate, updateOrCreate), what each of them does in the background and a quick snippet of code showing.

Paul Jones has posted his thoughts about factory behavior in PHP applications (well, really any kind of application as it's a pan-language concept). He suggests that factories should only create the objects requested and not persist them.

In a recent Reddit conversation, some of us went off on a tangent about factories. I maintained then, and do now, that a “factory” always-and-only returns a new instance. If you have a “factory” that returns anything other than a new instance, it’s not a factory alone. In the case of factory methods, it is a factory + accessor; in the case of factory objects, it is a factory + registry. A “factory” (whether a factory method or factory object) is one way to separate object creation from object use.

He gives an example of a case where an object needs to be created for a "doSomething" method. His first example shows the creation of the "Item" inline, mixing the creation and use of the object into the same place. He replaces this with a "factory" class/method that only returns the new "Item" requested. He points out that a factory method that retains the object (like as a class property) has the same problem as the first example - retention. Instead he suggests an intermediate "collaborator" that splits out the creation and retention once again.

Matt Stauffer has posted the latest in his "What's New in Laravel 5" series today with a look at the changes in creating Artisan commands with a newer, simpler syntax.

If you're not familiar with Artisan commands, they're command-line functions that you can run to interact with your Laravel application. If you run php artisan from the command line in any Laravel application directory, you'll see a list of all of the Artisan commands available for each app. As you can see, Laravel comes with quite a few enabled out of the box.

He starts with a look at the old way of creating the commands using the "artisan make:console" command to build the class and an example of its contents. This version requires a good bit of extra code to reference things like arguments and define required parameters. He then compares this with the new way with a much simpler syntax and reduced about of code overall. One of the main differences he mentions is the concept of a "signature" for the command - a specially formatted string that defines configuration such as required and optional parameters. He finishes the post with a few examples of these signatures.

Remi Collet has a new post today showing you how to get PHP-FPM up and running with Docker using a few simple lines in the Dockerfile. Docker is a toolset that lets you easily create and provision containers with scripted configurations (and link them together).

[The] use case [for this is] running php 5.3.3 on a Fedora 20 / 21 development workstation, for production deployment on RHEL-6 (as no php 5.3 SCL exists). This example can be easily adapted for all available PHP versions available as RPM (5.3.3 in RHEL-6, 5.4.16 in RHEL-7, 5.4.16 and 5.5.6 in RHSCL 1.2 or using a third party repository).

The contents of the Dockerfile are included, making a call to yum to install all the needed packages, make a few replacements in the www.conf configuration file and create the default "www" directory. Finally, it fires up the PHP-FPM server with the IP given in the startup. The commands to create the container and launch it are also included in the post.