In another of his series of posts about the upcoming version of the Laravel framework (v5.3) Matt Stauffer focuses in on some of the changes in routing that are coming down the line.

The last few versions of Laravel have showed the way routing works shifting around a bit. This is usually a sign that we're feeling some sort of pain—something feels off—but haven't found the perfect solution yet. In 5.3, we may have found it.

He starts by looking at some of the routing changes that happened when v5.2 was released including the change away from two groups ("web" and "api"). In v5.3 the major change is the location of the routes definitions containing all of the routes in your application. In the update, this relocation (into a directory) allows you to define multiple route configurations that can be individually changed based on features rather than one global place. He also includes an example of how you can set up your RouteServiceProvider to load in custom configurations as well.

On the TutsPlus.com site there's a new installment in their "How to Program With Yii2 Series" looking at implementing file uploads with some simple examples.

In this How to Program With Yii2 series, I'm guiding readers in use of the Yii2 Framework for PHP. In this tutorial, I'll guide you through the basics of uploading files and images in Yii2.

For these examples, we'll continue to imagine we're building a framework for posting simple status updates, e.g. our own mini-Twitter. The image above demonstrates writing a short update while uploading a picture I took of the Taj Mahal.

They start with a look at some of the file upload plugins that seemed like the best they found to use with Yii2: FileInput and the 2Amigos BlueImp File Uploader. They go with the first option for the rest of the tutorial, showing you how to get it installed (via Composer), updating your current database tables and changing the model to reflect these updates. Next they help you create the view with the image upload form and one to display the image result once the upload is successful (including the controller code needed).

In an interesting thread on the /r/php subreddit on Reddit.com, a user noticed that Google is indexing Composer files that are in the document root of PHP applications. These files, like "composer.json" and "composer.lock" can provide detailed information about which packages and libraries are in use in the application (information disclosure).

The problem is that these files are placed in the web root of the application and not in a folder one level up, a recommended practice. The post links to a Google search that shows an example of current sites with the issue.

Another comment in the same post also reminds users not to have things like their ".git" files in the document root either as they can provide valuable information to would be attackers about your application's code. Things can be done to prevent direct access to these files in the web server configuration but it's far better to restructure the application to have them in a parent directory of the actual web root.

NetTuts.com has posted the latest in their series about the Laravel framework with this new post, a look at creating filters, validators and working with files.

In this Nettuts+ mini-series, we’ll build a web application from scratch, while diving into a great new PHP framework that’s rapidly picking up steam, called Laravel. In this lesson, we’ll be learning about some very useful Laravel features: filters, and both the validation and files libraries.

They continue improving their sample application ("Instapics") and show you how to:

• Create a filter to run before or after the request is handled
• Apply a set of validation rules to a given dataset
• Handle custom error messaging
• Work with local files and uploads

They then take all of this and apply it to their application, creating an "auth" filter and login form, creating a form and doing some validation on its results and letting the user upload an image file.

In this new post to his blog, Joshua Thijssen looks at using the Augeas tool in a PHP application. Augeas is a configuration editing tool, making it easy to parse many different types of configs and transform them into a tree structure.

Even though I really like using sed and awk, sometimes its hard to change or add parameters in configuration files. Big sed statements that may or may not work, double checking if everything has been done correctly etc. Augeas is a really cool tool that lets you view / add / modify and delete all kind of data from configuration files. If you are using Puppet, you are probably aware of this tool, but I notice that a lot of PHP developers have never heard of it.. Let’s explore..

He shows an example of a configuration file and how the "augtool" command line script can be used to modify one of them. He then shows how to use the tool's library to set the server's "date.timezone" setting in the php.ini.

Andrew Martin has a new post to his blog looking at a technique that could be used to help minimize some of the performance issues you could see on AWS micro instances dealing with PHP session handling. His alternative is serving them from a RAM-based disk instead.

It’s rare to find a web server with slow disk I/O performance, but Amazon’s EC2 micro-instances are one such example. Their EBS disk subsystem access is rated "low", and this can have a detrimental effect on HTTP throughput. [...] This leaves sessions, which can be written to a redundant and fault tolerant storage system. [...] In order to speed up the disk access, a RAM-based disk can be mounted over the session directory. This has the disadvantage of being volatile – the data is lost in case of a server reboot, or the mount point being unmounted. However if tolerable, storing sessions in RAM insulates the application from poor filesystem performance.

He mentions the two types of kernels that can be used, ramfs and tmpfs, and the specifics of using a tmpfs filesystem to implement the technique (complete with command line calls to make it happen).

Juozas Kaziukenas has a new post to his blog today looking at using Phing to keep files in sync on a shared hosting, FTP only kind of environment.

Today I was trying to use [Phing] in shared hosting server, but as you will see, Phing can’t do a lot of it’s functionality without direct access to server (over shh for example). [...] Things get worse, when you try to sync files in shared hosting environment, where only FTP is available. [...] Code in the hole some months ago posted solution which uses Net_FTP (FTP functionality wrapper) package to upload files to server. I decided to try given solution, so I modified it to download source code from SVN first and then upload them.

His Phing configuration sets up the application, defining the source directory, the files to push, the FTP connection to make and pushes the files over out of an svn export. He has a slightly different solution (no code/config for this one) that would grab the last revision value from the remote server and only push out the files have have changed since then.

On the SitePoint PHP Blog today Troels Knak-Nielsen takes a deeper look at two of the superglobals a lot of PHP developers take for granted - $_GET and $_POST.

When a PHP script is invoked by a web server, it is as the result of a HTTP request. A HTTP request has a target URI and that URI consists of different parts. One of these parts is the query. As the PHP process starts up, the query gets parsed into an associative array. And for some reason, somebody decided on the unfortunate $_GET, because it's what you use for GET requests - right? Wrong!

He points out that all HTTP requests, regardless if they're GET or POST will have that GET information (not necessarily in $_GET, though). He also mentions another commonly used (and sometimes abused) superglobal - $_FILES. His biggest gripe, though, is that the naming of the variables confuses the developer as to the true content of the HTTP request.

And I won't even comment on the nastiness of $_REQUEST.

The PHPBuilder.com site has a quick new tutorial showing how to upload images to your server via a PHP script (including some error checking).

One of the most frequently asked questions about PHP is "how can I use PHP to upload an image". In this article we'll discuss the details of how you can do just that!

Their script is done in three steps - an HTML form to accept the input, the PHP script to handle the upload (working with the $_FILES superglobal) and another HTML page to let the user know their upload was a success. When the file is uploaded, they check for a few things: the internal error PHP could throw, ensuring that the uploaded file exists and checking to ensure that the file is an image. Only then is it moved over to the true uploads directory to be stored.

Tiffany Brown has a quick tutorial on a pagination method she's come up with for splitting out array contents over multiple pages.

While working on a recent project, I had to build a feature that displayed a list of files available in a directory. A simple way is just to use scandir() and a foreach loop to spit out a pretty list. There's a small problem though: long lists aren't all that user friendly. I decided instead to paginate the results. Here's one way to do it using PHP 5.

Her method reads in all of the (valid) files from the directory, assigns them to an array and uses the array_chunk function to split them up into groups on five. These groups can be easily looped through and displayed out as links easily.